Engagement Documents

Use with contexts/google-docs-system.html, contexts/design-foundations-system.html, media/proposals.md, and media/documents-invoices.md.

This file governs operational Google Docs for INTO Consulting engagements. It does not create legal documents, personnel documents, or sibling-brand document systems.

System Waterfall

Apply in order: update ledger, design foundations, tokens and brand systems, media framework, channel database, media/proposals.md for review/exhibit governance, media/documents-invoices.md for document/invoice constraints, this engagement-document sheet, target template, PDF export, and black-and-white print checks.

Shared Controls

• Identity: document headers use the INTO Consulting wordmark only.
• Surface: Warm Light for final Google Docs and PDFs.
• Typography: Newsreader, Lexend, and IBM Plex Mono only.
• Status: use text labels first. Petrol/action, Saffron/warning, positive, and critical tokens may reinforce state only when paired with text.
• Review: inherit the multi-party review workflow from media/proposals.md.
• Exhibits: inherit table, caption, source, appendix, and black-and-white fallback rules from media/proposals.md.
• Living documents: inherit header metadata, change-log, snapshot, and source note rules from media/documents-invoices.md.

Tier 1 Document Types

Tier 1 documents carry active engagement control. They are frequent, reviewed by multiple stakeholders, and likely to become source evidence for a proposal, SOW, delivery plan, or retrospective.

Document Type	Job	Cadence	Owner	Primary Review State
Status Report	Show progress, risks, decisions, metrics, and next actions.	Weekly or milestone-based.	Engagement lead.	Internal review -> client review.
Working Agreement	Define operating rhythm, roles, access, decisions, escalation, and communication norms.	Created at kickoff; updated when the operating model changes.	Engagement lead with client owner.	Internal review -> client review -> ready.
Proposal Variant	Create a controlled alternate proposal package without rewriting the master proposal.	As needed for scope, audience, or package changes.	Proposal owner.	Draft -> internal review -> client review.

Status Report Rules

• Keep it short enough for a weekly decision meeting: one page for status, one optional appendix for evidence.
• Required sections: header metadata, executive status, metric snapshot, decisions needed, risks/blockers, completed work, next actions, appendix links.
• Use positive only for completed/favorable state, Saffron for warning or milestone state, and critical only for blocked or material risk.
• Every status color has a text label and black-and-white fallback.

Working Agreement Rules

• Required sections: operating principles, roles and ownership, meeting rhythm, decision rules, communication channels, access/data handling, escalation, change log.
• Use responsibility labels, not personal shorthand, when the doc may be reused or printed.
• The agreement is a working operational contract. It is not a legal document.

Proposal Variant Rules

• Use only when the base proposal remains intact and an alternate reader, scope, fee structure, or package needs controlled review.
• Required sections: variant reason, unchanged master references, changes, impact on scope, impact on fees/timeline, decision requested, review notes.
• Always link back to the master proposal and name the source version.
• Do not duplicate the full master proposal unless the variant is approved to become the new master.

Tier 2 Document Types

Tier 2 documents translate evidence and operating design into reusable engagement artifacts. They are less frequent than Tier 1 controls, but they often become source evidence for proposals, status reports, and delivery reviews.

Document Type	Job	Cadence	Owner	Primary Review State
Discovery Summary	Convert discovery signals into findings, implications, opportunities, and recommended next steps.	End of discovery or after a major research wave.	Discovery lead.	Internal review -> client review.
Delivery Framework	Define the delivery operating model, workstreams, governance, artifacts, and decision gates.	At define/build kickoff and when delivery model changes.	Delivery lead.	Internal review -> client review -> ready.
Risk Register	Track material risks, decisions, mitigations, owners, dates, and status across the engagement.	Weekly or before each decision gate.	Engagement lead with workstream owners.	Draft -> internal review -> client review when shared.

Discovery Summary Rules

• Required sections: executive readout, research scope, evidence map, findings, implications, opportunity areas, recommendation, open questions, appendix links.
• Use direct source notes under each finding. Do not move all evidence to the appendix without local citation.
• Findings must separate observation, interpretation, and recommendation.

Delivery Framework Rules

• Required sections: operating model, workstreams, roles, artifacts, cadence, decision gates, dependencies, QA checks, handoff and archive plan.
• Use workflow diagrams and responsibility grids only when they clarify decisions or ownership.
• Keep framework language actionable. Avoid turning it into a slide-deck narrative inside a document.

Risk Register Rules

• Required sections: risk summary, register table, decisions needed, mitigations, owner review log, appendix/source links.
• Status labels are mandatory: Open, Monitoring, Mitigating, Blocked, Resolved, or another approved text state.
• Saffron and critical treatments are allowed only for warning or material risk and must be paired with impact, likelihood, owner, and due date.

Tier 3 Document Types

Tier 3 documents package evidence, learning, or a single offer for reuse. They are less operational than Tier 1 and Tier 2, but they still need source control, approval state, identity discipline, and black-and-white export quality.

Document Type	Job	Cadence	Owner	Primary Review State
Case Study	Turn a completed engagement or proof point into a source-backed client story.	After approval to publish or share privately.	Story owner with engagement lead.	Draft -> internal review -> client review when required -> approved.
Lessons Learned	Capture what changed, what worked, what failed, and what should change next time.	At milestone close or engagement close.	Engagement lead.	Draft -> internal review -> archived.
One-Sheet	Package one offer, capability, service, or engagement model into a concise sales document.	As needed for outreach, events, proposals, or follow-up.	Offer owner.	Internal review -> ready.

Case Study Rules

• Required sections: client/context, challenge, approach, evidence, outcome, quote or proof point when approved, reusable lesson, source/approval notes.
• Do not imply public permission. Mark whether the study is internal, private client-share, anonymized, or public-approved.
• Claims require source notes and approval state before external use.

Lessons Learned Rules

• Required sections: context, intended outcome, what happened, what worked, what failed, root causes, decisions for next time, action items, archive link.
• Keep the tone operational. Do not turn lessons learned into personnel assessment or blame documentation.
• Actions need owner, due date, and status text.

One-Sheet Rules

• Required sections: offer name, audience, problem, outcome, proof, process, timeline, commercial range or qualification note, next action, source notes.
• One-sheets are concise documents, not landing pages. Use one strong exhibit or table, not a page of decorative modules.
• Every claim must be supportable by source, proof, or appendix note.