Default Contract
Use Google Docs in Pages format, US Letter portrait, 0.75in margins, restrained Warm Light styling, and a print-safe white variant when legal or procurement readers are likely to print.
INTO Consulting / Google Docs / SOW + Proposals
Google Docs System
A reader-first specification for Statements of Work and proposals authored in Google Docs, exported as PDFs, and read by clients as working documents.
Client Documents, Not Brochures
INTO Google Docs should feel like editorial working documents: airy, structured, commercially precise, and easy to review in a browser or exported PDF.
The default use cases are Statements of Work and proposals. Both should be readable without a presenter, printable without losing legal clarity, and structured enough for AI agents to generate sections without inventing layout decisions.
Foundation Route
Use contexts/design-foundations-system.html before changing baseline rhythm, type roles, reading path, bento usage, buttons, or image/text composition in proposals and SOWs. Then apply media framework, channel data, the target media sheet, and the document template before export.
What Google Docs Allows
Google Docs can control paper size, orientation, margins, and page color in Pages format. Those features do not behave the same way in Pageless.
Pages
Use for SOWs, proposals, signatures, page numbers, headers, footers, and PDF export.
Pageless
Use only for internal drafts or wide collaborative notes. Do not use for final SOW or proposal templates.
Mixed Orientation
Allowed for wide tables, charts, and graphics. Use sparingly as exhibit sections.
Tabs
Useful for internal organization, but final downloads/printing require attention to current tab versus all tabs.
Platform Risk
Do not design a final SOW around Pageless features. Headers, footers, page numbers, page margins, and print layout matter for client-final documents.
Two Document Contracts
Statements of Work and proposals share a visual system but differ in rhythm. SOWs prioritize acceptance clarity. Proposals prioritize the recommendation and evidence path.
Statement Of Work
- Lead with parties, project, date, and commercial summary.
- Keep scope, assumptions, dependencies, and acceptance criteria explicit.
- Use tables for phases, deliverables, responsibility, fees, and decision gates.
- End with signature and next action.
Proposal
- Lead with recommendation, bottleneck, proposed workflow, and expected value.
- Use one strong exhibit before scope.
- Make price and timeline scannable.
- Use governance as reassurance, not a hidden appendix.
Templates Are Commercial Controls
Proposal and SOW templates protect the client reading path, legal clarity, and export quality. They are not decorative page styles.
SOW Template
Cover, commercial summary, scope, phases, responsibilities, governance, acceptance, and signature blocks.
Proposal Template
Recommendation, bottleneck, proposed workflow, current-state evidence, scope, commercials, governance, and next action.
Print-Safe Variant
White page surface, 0.75in margins, headers/footers, page numbers, and PDF inspection before sending.
Exhibit Variant
Landscape section only for wide pricing matrices, charts, implementation plans, or procurement appendices.
| Template Control | Required Decision | Export Check |
|---|---|---|
| Page Setup | US Letter default; A4 only as separate template. | PDF page count and margin integrity. |
| Paragraph Styles | Newsreader headings, Lexend body, mono captions/meta. | Document outline and heading hierarchy. |
| Headers/Footers | Client, project, section, page number, discreet identity. | No orphaned footer or clipped mark. |
| Table Styles | Header row, row header, alternating shading, totals, notes. | Readable prices and totals after export. |
| Proposal/SOW Skeleton | Conclusion first; commercials and acceptance visible. | Reader understands next action from page one. |
Agent Rule
Choose SOW or proposal, then use the canonical template skeleton. Add sections only when they support commercial clarity or procurement review.
Margins Create The Brand
Use page geometry before decoration. Google Docs does not have a true layout grid, so the brand grid is conceptual and enforced through margins, tables, and recurring section structure.
INTO Consulting
SOW / Client
Statement Of Work
Size
US Letter portrait, 8.5 x 11in. A4 may be created as a separate template when required.
Margin
0.75in on all sides. Do not reduce page edges to fit more copy.
Grid
6 conceptual columns. Narrative spans 4 columns; side notes use 2 columns; exhibits span 6.
Line Length
Google Docs final pages are the exception to the cross-media column rule. Use page margins, headings, side notes, and tables before forcing columns.
Editorial Rhythm
Use label, pause, display, argument, evidence, and recovery space. Tables, pricing blocks, and exhibits need visible after-space before the next paragraph.
Landscape
Use a landscape section only for wide exhibits, pricing matrices, or implementation plans.
Readable At Arm's Length
Google Docs typography should preserve INTO's hierarchy while accepting that Docs has less typographic precision than HTML or desktop publishing.
| Role | Spec | Use |
|---|---|---|
| Cover title | Newsreader 40-48pt | Proposal cover, major document title. |
| Section title | Newsreader 24-30pt | Major sections and chapter openers. |
| Subsection | Newsreader 16-18pt | Scope, fees, assumptions, governance. |
| Body | Lexend 10.5-11.5pt | Default prose and table narrative. |
| Caption/meta | IBM Plex Mono 8.5-9.5pt | Figure labels, page meta, table labels. |
Spacing should be generous: 12pt after paragraphs, 18-24pt before subsections, 36-48pt before major sections, and 8-10pt table cell padding where Docs allows it.
Statement Of Work Pattern
The SOW is a commercial control document. It should be clean, narrow, and unambiguous.
| Order | Section | Purpose |
|---|---|---|
| 01 | Cover | Client, project, date, INTO wordmark. |
| 02 | Commercial Summary | Fee, timeline, decision gate, acceptance path. |
| 03 | Scope | What INTO will deliver and what is excluded. |
| 04 | Phases | Discovery, Define, Build, Optimize with outputs. |
| 05 | Responsibilities | Client dependencies, access, owners, review cadence. |
| 06 | Governance | Security, data access, handoff, ownership. |
| 07 | Acceptance | Signatures and next action. |
Proposal Pattern
The proposal should read as a short, evidence-led recommendation. It is not a sales brochure.
- Page 1 states the recommendation, bottleneck, workflow, and expected value.
- Page 2 shows current-state evidence and the proposed system diagram.
- Page 3 explains scope and phases.
- Page 4 makes commercials, assumptions, exclusions, and governance scannable.
- Appendices carry detail only when the client needs procurement support.
First Page Rule
A client should understand the recommended system, why it matters, what it costs directionally, and what happens next from the first page.
Tables Are For Commercial Clarity
Tables should carry pricing, scope, responsibilities, assumptions, and timelines. Avoid using tables as decorative layout scaffolds for prose.
Use Tables For
Fees, phase plans, RACI-style responsibilities, assumptions, exclusions, and deliverable matrices.
Avoid Tables For
Faux columns, decorative cards, empty comparison theatre, or long paragraphs.
Wide Tables
Move to a landscape section or appendix. Do not crush body type below 9.5pt.
Figures
Use one figure number and one caption. Captions use IBM Plex Mono.
Draft In Docs, Finalize For PDF
Google Docs is for collaboration and comments. The client-final artifact should still be checked as a PDF before sending.
- Use Suggesting mode for client or internal redlines.
- Use the document outline and headings for navigation.
- Do not rely on tabbed Docs for final client export unless all tabs are intentionally exported.
- Export and inspect the PDF before sending any SOW or proposal.
- Verify headers, footers, page numbers, signature blocks, and wide tables after export.
Review State Is A Document Control
Every client-facing Google Doc uses the same review workflow: draft, internal review, client review, legal review when required, ready for signature, executed, and archived. Status color is only a signal when paired with text.
Change Mode
Use direct edit in Draft for author-owned copy. Use Suggesting mode for meaning, scope, pricing, timeline, evidence, governance, or client-visible claims.
Comment Threads
Resolve only after the owner, reviewer, affected section, and decision are clear. Final comments use Decision: accepted, Decision: rejected, or Decision: follow-up required.
Access
Authors edit, reviewers suggest or comment, clients comment or suggest during client review, and executed copies become view-only archived artifacts.
Archive
At v1.0 executed, preserve the signed PDF and executed source Doc. Continue operational tracking in a new linked copy.
Project Atlas Proposal
Project Atlas Proposal
Project Atlas SOW
- Document job
- Make review state, owner, version, and access posture visible before the reader edits.
- Identity
- Wordmark only in the document header band; no square mark lockup.
- Signal rule
- Saffron and positive states pair with text labels. Draft remains neutral.
- Print fallback
- State, version, owner, and action are readable in black and white without color.
Exhibits Must Carry Decisions
Use in-document tables and exhibits when the reader needs to compare options, assign responsibility, understand timing, inspect workflow, judge risk, see metrics, or act on follow-up work. Color can reinforce signal only when the text still carries the meaning.
Exhibit Job
Each exhibit answers one review question. If it does not change a decision, shorten it into prose or move it to the appendix.
Caption Rule
Every table or figure keeps a numbered caption and source note directly attached to the exhibit. Captions state the point the reader should notice.
Wide Content
Move wide matrices, timelines, and workflow maps to a landscape section or appendix. Do not shrink table or axis text below the Google Docs floor.
Print Rule
Every priority, status, risk, ownership, metric, and action state must remain readable in a black-and-white PDF without color.
Comparison Matrix
| Option | Speed | Dependency Risk | Recommendation |
|---|---|---|---|
| Stabilize current flow | 2 weeks | Low | Use now |
| Replace workflow | 8 weeks | High | Defer |
Table 1. Options compare delivery speed against client-side dependency risk.
RACI Grid
| Decision | Responsible: INTO lead | Accountable: client owner |
|---|---|---|
| Evidence | Consulted: operations | Informed: finance |
Table 2. Responsibility labels remain readable when color and initials are removed.
Timeline Plan
- May 28Discovery readout / owner: Avery
- Jun 11Workflow pilot / owner: Orion
- Jun 25Client review gate / status: milestone
Figure 1. Each milestone carries date, owner, and state as text.
Workflow Diagram
1. Intake
2. Triage
3. Owner decision
4. Archive
Figure 2. Numbered steps preserve meaning if connector color disappears.
Risk / Decision Matrix
| Scope drift | Warning: medium impact |
|---|---|
| Data access | Blocked: owner required |
Table 3. Status words carry the risk before Saffron or critical treatment appears.
KPI Snapshot
Baseline4.8 days
Target1.5 days
Current2.1 days
Table 4. Metric name, unit, target, and date remain text-first.
Action-Item Table
| Next action | Approve pilot brief |
|---|---|
| Owner | Client sponsor |
| Status | Ready: due May 30 |
Table 5. Owner, due date, status, and next action are explicit text.
- Governance
- Every exhibit type has a defined job, caption, source note, and review question.
- Color
- Petrol, Saffron, positive, and critical treatments are semantic only and always paired with labels.
- Layout
- Wide matrices and workflow maps move to landscape sections or appendices instead of compressing type.
- Print fallback
- Tables, timelines, diagrams, KPIs, and action states remain explainable in black and white.
Living Docs Are Working Copies
Use living Google Docs for active operations, discovery synthesis, delivery tracking, and risk review. They can carry unresolved comments and action items, but every snapshot sent outside the team must freeze state, resolve or defer threads, and pass PDF print review.
Header Metadata
Document type, project, owner, version, status, last updated date, access posture, and next review date appear before the working body.
Change Log
Record date, owner, changed section, decision, and follow-up near the front. Google Docs revision history is not enough for client review.
Snapshot Moment
When a living document is distributed, freeze page numbering, resolve or defer comments, export a PDF, and keep the working copy separate.
Boundary
Executed SOWs, signed proposals, invoices, legal documents, and personnel documents are not living-document types in this system.
Status Report / Project Atlas
v0.4 client review
Owner: Avery
Access: Suggest / Next review: Jun 03
Change Log
| May 20 | Scope section updated. Decision: accepted by client sponsor. |
|---|---|
| May 21 | Risk table added. Follow-up: confirm data owner before pilot. |
| May 22 | Snapshot queued. Comments: two deferred to appendix review. |
- Identity
- Wordmark-only header keeps INTO Consulting exclusive without square-mark duplication.
- State
- Version, status, owner, access, and next review date are explicit text.
- Control
- Change log records reader-facing decisions instead of relying only on revision history.
- Print fallback
- Snapshot state and change history are readable in black and white.
Appendices Support Claims In Place
Appendix material extends evidence depth without breaking the main reading path. Every appendix item needs a stable label, source owner, date, review job, and a main-document cross-reference that still works in printed PDFs.
Stable Labels
Use Appendix A/B/C and Table A1/Figure B2 labels. Do not renumber main-document exhibits when appendix evidence changes.
Source Attachment
Attach source notes to the appendix item and cite the appendix at the sentence, table, or figure that depends on it.
Wide Evidence
Landscape appendix sections are allowed for wide extracts, matrices, and screenshots when captions and page numbers remain visible.
Scope Boundary
Appendices support the current document only. Do not add legal templates, personnel records, or unrelated INTO brand material.
Proposal Appendix / Project Atlas
Appendix table of contents
Snapshot: v1.0 ready for signature
Print: labels and page numbers required
- Appendix AResearch evidence / owner: Avery / supports Section 2 and Table 1
- Appendix BWorkflow detail / owner: Orion / supports Figure 2
- Appendix CCommercial assumptions / owner: engagement lead / supports Section 6
Main section citation: See Appendix B, Figure B2 for the operating model detail.
- Cross-reference
- Readable appendix labels remain useful when links are removed in print.
- Evidence
- Each item names source owner, support target, and review job.
- Layout
- Landscape appendix pages are allowed only when captions and page numbers survive export.
- Scope
- No legal templates, personnel records, or unrelated brand material enter the appendix.
Tier 1 Documents Control Active Engagements
Status Reports, Working Agreements, and Proposal Variants are frequent, multi-stakeholder documents. They carry decisions, access posture, and review state without replacing the existing SOW or Proposal masters.
Status Report
v0.3 client review / owner: engagement lead / access: Comment| Job | Show progress, decisions, risks, metrics, and next actions. |
|---|---|
| Cadence | Weekly or milestone-based. |
| Signal | Warning: data owner needed |
Template: templates/documents/status-report.md. Print fallback keeps owner, status, risk, and next action as text.
Working Agreement
v0.2 internal review / owner: engagement lead / access: Suggest| Job | Define roles, meeting rhythm, decision rules, access, and escalation. |
|---|---|
| Boundary | Operational agreement only; not a legal document. |
| Fallback | Role labels remain readable without color or initials. |
Template: templates/documents/working-agreement.md. Responsibility labels print in black and white.
Proposal Variant
v0.1 draft / master source: Proposal v1.0 / access: Edit| Job | Review an alternate package, scope, fee, or reader view. |
|---|---|
| Master rule | Do not rewrite the master proposal unless the variant is approved. |
| Decision | Ready: approve, reject, or fold into master |
Template: templates/documents/proposal-variant.md. Changes are tabled and tied to the master version.
- Production use
- Tier 1 docs support active delivery control, client review, and decision tracking.
- Identity
- Every header uses the INTO Consulting wordmark only.
- Master safety
- The proposal variant adds controlled alternatives without rewriting the proposal master.
- Print fallback
- Status, owner, review state, and action remain readable in black and white.
Tier 2 Documents Turn Evidence Into Operating Design
Discovery Summaries, Delivery Frameworks, and Risk Registers translate research, delivery structure, and material risk into reviewable client documents. They inherit the same header, review, exhibit, appendix, and print rules as Tier 1.
Discovery Summary
v0.3 client review / owner: discovery lead / access: Comment| Job | Convert discovery signals into findings, implications, opportunities, and next steps. |
|---|---|
| Evidence | Observation, interpretation, recommendation, and source note remain separate. |
| Appendix | Source map links to Appendix A and local citations beside claims. |
Template: templates/documents/discovery-summary.md. Findings stay source-attached and printable.
Delivery Framework
v0.2 internal review / owner: delivery lead / access: Suggest| Job | Define operating model, workstreams, cadence, decision gates, QA, and handoff. |
|---|---|
| Exhibits | Workflow and RACI grids are allowed only when they clarify ownership. |
| Signal | Ready: gate criteria defined |
Template: templates/documents/delivery-framework.md. Gates and ownership remain text-first.
Risk Register
v0.5 internal review / owner: engagement lead / access: Edit| Job | Track material risks, mitigations, owners, due dates, decisions, and status. |
|---|---|
| State | Blocked: data access owner missing |
| Fallback | Status word, impact, owner, and due date survive without color. |
Template: templates/documents/risk-register.md. Critical treatment is reserved for material blocked risk.
- Evidence
- Tier 2 docs keep source notes attached to findings, gates, risks, and appendix items.
- Operations
- Frameworks and registers convert evidence into owners, cadence, decisions, and controls.
- Signal
- Positive and critical states are token-bound and paired with explicit text.
- Print fallback
- Findings, gates, risks, owners, and due dates remain readable in black and white.
Tier 3 Documents Package Proof And Learning
Case Studies, Lessons Learned, and One-Sheets package evidence, learning, or a single offer for reuse. They still need approval state, source notes, review control, and black-and-white PDF fidelity before distribution.
Case Study
v0.2 internal review / sharing: private client-share / access: Suggest| Job | Turn a completed engagement or proof point into a source-backed client story. |
|---|---|
| Approval | Sharing status is explicit before external use. |
| Proof | Outcome claims require source notes and approval owner. |
Template: templates/documents/case-study.md. Claims and sharing boundaries remain text-first.
Lessons Learned
v0.1 draft / owner: engagement lead / access: Edit| Job | Capture what changed, worked, failed, and should change next time. |
|---|---|
| Boundary | Operational learning only; not personnel assessment. |
| Action | Warning: follow-up owner needed |
Template: templates/documents/lessons-learned.md. Actions keep owner, due date, and status text.
One-Sheet
v1.0 ready / owner: offer owner / access: View| Job | Package one offer, service, or capability for outreach or proposal follow-up. |
|---|---|
| Structure | Problem, outcome, proof, process, timing, commercial note, next action. |
| Signal | Ready: single offer and source notes verified |
Template: templates/documents/one-sheet.md. One strong exhibit or table is enough.
- Reuse
- Tier 3 docs make proof, learning, and offers reusable without becoming broad collateral systems.
- Approval
- Case studies name sharing status before external use.
- Boundary
- Lessons learned stays operational and avoids personnel assessment.
- Print fallback
- Claims, status, proof, owner, and next action remain readable in black and white.
Research Basis
These platform constraints come from official Google help sources and are recorded in the channel database.