INTO Consulting INTO Consulting
Start typing to search.
↑ ↓ navigate Enter open Esc close Full-page search →

Media framework

Documents And Invoices

Foundation source: use `contexts/design-foundations-system.html` before

Foundation source: use contexts/design-foundations-system.html before setting page rhythm, type roles, table spacing, and status behavior. Canonical source template: templates/documents/invoice-outline.md.

System Waterfall

Apply in order: foundation context, tokens and brand systems, media framework, channel data, this documents/invoices sheet, document or invoice template, PDF and print checks. Page tools may translate rhythm to points or table settings, but they cannot bypass baseline, status, reading-path, or accessibility rules.

Media

  • Format: US Letter portrait PDF by default.
  • Surface: Warm Light only.
  • Export: PDF with selectable text.

Margins

  • Document margin: 56px.
  • Invoice tables: page margin stays 56px; table cell padding 10-14px.
  • Footer legal notes stay inside the margin.

Typography Scaling

  • Document title: Newsreader 32-44px.
  • Section title: Newsreader 22-28px.
  • Body: Lexend 10.5-11.5pt.
  • Table/header/meta: IBM Plex Mono 8.5-10pt.
  • Invoice totals: IBM Plex Mono tabular, 11-14pt.

Spacing

  • Browser-facing or generated HTML previews use rem spacing from the foundation scale. Final PDFs may translate that rhythm to points or page coordinates.
  • Section gap: 2.5-3.5rem source equivalent.
  • Table row height: 2-2.5rem source equivalent.
  • Line item padding: 0.625-0.875rem source equivalent.
  • Signature block gap: 3rem source equivalent.
  • Snap headings, tables, and signature blocks to the structural baseline where the authoring tool allows it.

Grid

  • Documents: 6 columns, 16px gap.
  • Invoices: 12 columns for line-item tables.
  • Totals block: right 4 columns.

Layout System

  • Documentation: title, context, ordered sections, figures/tables.
  • Invoice: identity, billing parties, invoice meta, line items, totals, payment terms, footer.

Review Workflow Cross-Reference

All Google Docs document types inherit the multi-party review and approval workflow in media/proposals.md. Use its version labels, Suggesting/comment conventions, sign-off gates, access posture, conflict resolution, executed archive moment, and token-bound status colors before authoring Status Reports, Working Agreements, Discovery Summaries, Risk Registers, Case Studies, One-Sheets, or invoices. Invoices may use a simpler owner/client review path, but status remains text plus color and must print clearly in black and white.

Exhibit Governance Cross-Reference

All Google Docs document types inherit the in-document table and exhibit governance in media/proposals.md. Use its exhibit types, caption/source rules, landscape/appendix rule for wide exhibits, and black-and-white fallback before adding comparison matrices, RACI grids, timelines, workflow diagrams, risk/decision matrices, KPI snapshots, or action-item tables. Invoices keep their own line-item and totals structure, but overdue, paid, disputed, or blocked states still require text labels in addition to any token-bound color.

Living-Document Conventions

Living Google Docs are operational working documents, not executed artifacts. Use them for status tracking, discovery synthesis, working agreements, delivery plans, risk tracking, retrospectives, and appendix evidence that is still being updated.

Header Contract

  • Header identity uses the INTO Consulting wordmark only. Do not combine the wordmark with the square mark in document headers.
  • Header metadata names the document type, client/project, owner, version, status, last updated date, access posture, and next review date.
  • Living documents use v0.x while actively changing. Use v1.0 only when a snapshot is approved for distribution or archived.
  • Status labels must be text-first: Draft, Internal review, Client review, Ready, Blocked, Archived, or a specific project-approved state. Color may reinforce only with canonical tokens.

Change Log And Source Notes

  • Keep a compact change log near the front of living documents after the executive note or context section.
  • Each log entry records date, owner, changed section, decision, and open follow-up. Do not rely on Google Docs revision history as the only reader artifact.
  • Source notes stay attached to the claim, table, figure, or appendix item they support. Appendix-only source dumps are not enough for client review.

Working Copy Versus Snapshot

  • A living copy may keep unresolved comments and active action items.
  • A distribution snapshot must resolve or explicitly defer comments, freeze page numbering, and export a PDF for black-and-white print review.
  • Executed SOWs, signed proposals, invoices, legal documents, and personnel documents are not living-document types in this system.

Medium Constraints

  • Must print cleanly in black and white.
  • Do not use dark backgrounds.
  • Do not use color alone to communicate overdue, paid, warning, or critical state. Pair status with text.
  • Use vertical/layer-cake scanning: header, parties, line items, totals, terms, and footer. Do not create side-by-side bento modules for invoice essentials.
  • Keep captions, source notes, and legal notes attached to the table or exhibit they qualify.