Media framework

Proposals

Canonical Google Docs hybrid spec: `contexts/google-docs-system.html`.

Canonical Google Docs hybrid spec: contexts/google-docs-system.html. Foundation source: contexts/design-foundations-system.html.

System Waterfall

Apply in order: update ledger, foundation context, tokens and brand systems, media framework, channel data, this proposal sheet, Google Docs hybrid spec, proposal template, PDF/export checks. Document units may use inches and points, but source rhythm, hierarchy, reading path, and image/text policy come first.

Media

Format: US Letter portrait PDF by default. A4 allowed for international recipients.
Surface: Warm Light.
Export: PDF, accessible text preserved, links active.

Margins

Outer document margin: 56px / 0.78in.
Dense commercial tables: keep page margin, reduce internal cell padding to 12-16px.
Print safe area: no content closer than 0.5in to trim.

Typography Scaling

Cover title: Newsreader 44-56px.
Section title: Newsreader 28-36px.
Body: Lexend 10.5-11.5pt.
Caption/spec: IBM Plex Mono 8.5-9.5pt.
Commercial numerals: Newsreader or IBM Plex Mono, depending on whether the number is a headline or a table cell.

Spacing

Source rhythm follows the 0.25rem micro baseline and 0.5rem structural baseline before it is translated into Google Docs paragraph and table spacing.
Page sections: 2rem, 3rem, 4rem source equivalents.
Paragraph gap: 0.5-0.75rem source equivalent.
Exhibit gap: 1-1.5rem source equivalent.
Major section break: 3.5-5rem source equivalent.
Do not invent one-off gaps to make a page fit. Split the section or reduce content before breaking the rhythm.

Grid

Default: 6 columns.
Gap: 16px.
Rows: baseline rhythm of 8px.
Sidebar notes: 2 columns.
Main narrative: 4 columns.
Full-width exhibits may span 6 columns but must keep captions aligned to the grid.

Line Length

Google Docs final pages are the exception to the cross-media column rule. Preserve page rhythm with margins, headings, side notes, and tables rather than forcing body prose into columns. Use columns only for exhibits or side-note structures that improve review.

Layout System

Use this order unless the engagement demands otherwise:

Cover: client, project, date, INTO wordmark.
One-page recommendation: bottleneck, proposed workflow, expected value.
Current-state evidence: what is slow, where time leaks, what risk exists.
Proposed system: diagram first, prose second.
Scope and phases: Discovery, Define, Build, Optimize.
Commercials: fee, timeline, assumptions, exclusions.
Governance: security, data handling, handoff, ownership.
Acceptance: signature block and next action.

Reading path:

Proposals use vertical/layer-cake scanning by default: conclusion, evidence, proposed system, commercials, governance, acceptance.
Use Z-pattern only for sparse cover or one-page recommendation moments.
Treat F-pattern behavior as a warning that the page is too dense or poorly structured.
Bento layouts are allowed only for a small set of comparable proof modules, never for the full proposal architecture.

Medium Constraints

The reader may print it. Avoid dark full-page backgrounds.
Legal/commercial details need scannable tables.
Never bury price in prose.
Use diagrams to reduce explanation, not to decorate.
Images and screenshots act as evidence. Text belongs beside them, on a quiet third, or on verified overlay space; never over the focal subject. Captions stay attached.

Multi-Party Review And Approval Workflow

This workflow is canonical for every INTO Google Docs document type. It lives here because Proposals and SOWs are the highest-risk review cases, but Status Reports, Working Agreements, Discovery Summaries, Risk Registers, Case Studies, and One-Sheets inherit the same review states and access rules.

Review States

State	Title / Header Label	Editing Rule	What Locks
Draft	`v0.1 draft`	INTO authors may edit directly. Use comments for unresolved facts.	Nothing locks except identity, page setup, and document type.
Internal review	`v0.2 internal review`	Reviewers use Suggesting mode for substantive text and direct edits only for typos, dates, and broken links.	Structure, section order, pricing table shape, and evidence captions lock unless the owner approves a change.
Client review	`v0.3 client review`	Client reviewers use Suggesting mode or comments. INTO resolves threads with a decision note before accepting text.	Recommendation, scope boundary, commercial table totals, and review history remain visible.
Legal review	`v0.4 legal review`	Counsel-owned comments and suggested edits are preserved as a separate pass. INTO does not create new legal document types in this system.	Commercial language, acceptance path, signatures, IP/copyright notes, and SOW precedence text lock pending counsel.
Ready for signature	`v1.0 ready for signature`	Only owner-approved final corrections are allowed. Comments must be resolved or explicitly deferred.	Scope, fees, dates, parties, acceptance criteria, and signature blocks lock.
Executed / archived	`v1.0 executed`	No edits to the executed artifact. Create a new operational copy for tracking changes.	Full PDF snapshot, signature page, source Doc link, and export checksum/archive location lock.

Change And Comment Conventions

Use Suggesting mode for meaning changes, client-visible claims, scope, price, timeline, acceptance, governance, source notes, and any sentence a reviewer may reasonably contest.
Use direct edit only for spelling, formatting, broken internal links, page numbers, and non-substantive punctuation.
Accepted suggestions should not remove decision context from comment threads. When a thread changes direction, leave a final comment: Decision: accepted, Decision: rejected, or Decision: follow-up required.
Resolve comments only after the owner, reviewer, and affected section are clear. If the thread records a decision, summarize the decision before resolving it.
Conflicting reviewer comments are escalated to the document owner. If the owner cannot break the tie, the engagement lead decides and records the rationale in the thread before resolution.

Status Color And Header Treatment

The document header band may use status color only for review state and only when paired with a text label. Draft and internal review use neutral hairlines. Client or legal review may use Saffron warning treatment. Ready and executed may use positive state treatment. Critical treatment is reserved for blocked, expired, or materially disputed documents.
Status color uses canonical tokens only: Petrol/action, Saffron/warning, positive, and critical. Do not use decorative color bands, gradients, or unlabelled chips.
Black-and-white print fallback is mandatory: every status band includes the state name, version, owner, date, and a text instruction such as Client comments open or Executed copy: do not edit.

Access And Sign-Off

Authors and document owners may edit in Draft and Internal review. Reviewers comment or suggest. Client stakeholders comment or suggest only during Client review. Procurement or counsel gets comment/suggest access only for the sections they own.
Header metadata names the owner, version, status, last modified date, and access posture: Edit, Suggest, Comment, or View.
Sign-off gates move in this order: draft -> internal review -> client review -> legal review when required -> ready for signature -> executed/archive. A state cannot advance while required comments remain unresolved.
At v1.0 executed, export the signed PDF, preserve the executed source Doc, remove normal edit access, and start any living operational tracker in a new copy that links back to the executed artifact.

In-Document Table And Exhibit Governance

Tables and exhibits are evidence, not decoration. Use them when they make a decision, responsibility, cost, risk, schedule, workflow, or metric easier to review than prose would.

Exhibit Types

Exhibit	Use For	Required Fallback
Comparison matrix	Options, packages, current/future state, vendor or workflow choices.	Text label in every cell; no meaning carried by fill color alone.
RACI / responsibility grid	Decision ownership, review ownership, delivery roles, and escalation paths.	Role labels remain readable in black and white; initials never stand alone.
Timeline / milestone plan	Phase sequencing, review gates, dependency dates, and handoff moments.	Date, owner, and state appear as text on each milestone.
Workflow diagram	Process, approval path, operating model, or automation handoff.	Numbered steps and arrows survive if color disappears.
Risk / decision matrix	Risk severity, decision urgency, mitigation owner, and action.	Status word plus impact/likelihood text; Saffron and critical tokens only when semantically required.
KPI snapshot	Baseline, target, current value, confidence, and date.	Metric name, unit, and delta are text; Petrol is action/signal, not decoration.
Action-item table	Owner, next action, due date, blocker, and resolution.	Status word, due date, and owner are text; overdue does not rely on red alone.

Caption And Source Rules

Every table or figure gets a caption directly attached to it. Use one figure or table number per exhibit and do not reuse numbers after edits.
Captions say what the reader should notice, not just what the exhibit is. Example: Table 2. Scope options show the trade between delivery speed and client-side dependency risk.
Source notes sit under the exhibit, not in the appendix alone. If the exhibit rolls up appendix evidence, cite the appendix line and the source file.
Wide exhibits move to a landscape section or appendix. Do not shrink body, table, or axis text below the Google Docs minimums in this system.

Black-And-White Exhibit Rules

Do not use color as the only differentiator for status, priority, risk, ownership, metric movement, or next action.
Use row labels, column labels, visible rules, prefixes, symbols from the authoring tool, and short text states before adding fill color.
Status and signal color remains token-bound: Petrol for action or selected signal, Saffron for warning/milestone/comparison, positive for completed or favorable, critical for blocked or material risk.
Print-check every exhibit after PDF export. If a reader cannot explain the exhibit from the black-and-white PDF, the exhibit fails.

Appendix And Cross-Reference Standards

Appendices are for evidence depth, not for hiding decisions. Use appendices when the proposal, SOW, status report, or discovery summary needs source detail that would interrupt the main reading path.

Appendix Structure

Start every appendix with an appendix table of contents. Each item includes appendix letter, title, source owner, date, and whether it supports a claim, table, figure, assumption, or decision.
Use stable labels: Appendix A, Appendix B, Table A1, Figure B2. Do not renumber main-document exhibits when appendix evidence changes.
Keep source evidence grouped by review job: research evidence, commercial assumptions, implementation evidence, operating model detail, data extracts, and export/archive proof.

Cross-Reference Rules

Main sections cite appendix evidence at the sentence, table, or figure that depends on it. Do not cite only at the end of the document.
Cross-references use readable text in final PDFs: See Appendix B, Figure B2. Links may be added, but the text must survive print.
If a source changes after client review starts, update the appendix item, the main-section citation, and the change log in the same pass.

Print And Export Rules

Appendix pages use the same margins, type system, header identity rule, and black-and-white fidelity rules as the main document.
Landscape appendix sections are allowed for wide evidence. Keep captions, source notes, and page numbers visible after export.
Do not add legal templates, personnel records, or unrelated INTO brand material to appendices. The appendix only supports the current document.