⚠️ NEEDS REVIEW — Imported from ~/advisory-os/ on Feb 19, 2026. Content is from Feb 10-12 and may not align with current vault framework files (Feb 15-18). Review and merge before using.
Advisory OS Document System — Input Manifest
Overview
Three input types feed the document system. Each has different fields, sources, and processing rules (see 01-process.md).
- Required — Must have to process. Document update cannot proceed without these.
- Recommended — Significantly improves output quality and cross-referencing.
- Optional — Enhances depth when available.
Document Types
| Document | Scope | Who sees it | What it does |
|---|---|---|---|
| Client Master Plan | Whole client, forever | Advisor only | Full relationship picture. GPS, themes, constraints, conversation history, team roster. One per client, evolves over time. |
| Project Plan: [Initiative] | One initiative, beginning to end | Advisor only | Execution document for a specific constraint solve. Deployment plan + session tracking + build status + coaching notes. One per initiative. |
| Client Blueprint: [Initiative] | One initiative | Client + Advisor | What the client sees and approves. Builds, timeline, expected outcomes. One per initiative, paired to its Project Plan. |
| Client Roadmap | Whole engagement arc | Client + Advisor | Big-picture view across all initiatives. What's completed, in progress, and next. Created when client has multiple initiatives. |
Step 1 — Collect Client Reference Data (Required First Run Only)
Before generating any document for a new client, the advisor must provide a Client Reference Data file with correct spellings for:
- Company legal name
- All team members (name + role)
- Software/tools the client uses
- Any proper nouns with unusual spellings
This data populates the Reference section at the top of the Client Master Plan before GPS. All documents pull proper nouns from Reference — NEVER from transcripts, JSONs, or matrix outputs. On update runs, the Master Plan already carries the Reference block — don't re-ask. Advisor can update via manual input if team changes.
Step 2 — Collect Client Profile Data
| Field | Priority | Source |
|---|---|---|
| Client first name | Required | First session / intake |
| Client last name | Required | First session / intake |
| Company name | Required | Reference Data file |
| Revenue | Recommended | Session / client disclosure |
| Team size | Recommended | Session / client disclosure |
| Relationship start date | Required | Advisor records |
| Entry point / referral source | Recommended | Advisor records |
| Engagement name | Required | Advisor records |
| Engagement value (LTV / annual) | Recommended | Advisor records |
| Meeting cadence | Recommended | First session |
| Communication style notes | Optional | Advisor observation |
| Team roster (names, roles) | Recommended | Reference Data file |
Advisor Defaults (System-Level)
Apply to all documents unless overridden by a Client Reference Data file:
| Field | Default Value |
|---|---|
| Advisor name | Kathryn Brown |
| Brand | Advisory OS |
Input 1: Session JSON Extraction (from Relay)
Produced after each client session. Source: Relay agent processing session transcript.
| Field | Priority | Description | Example |
|---|---|---|---|
| conversation.date | Required | Session date | "2026-02-02" |
| conversation.type | Required | Meeting type | "Weekly advisory session" |
| conversation.summary | Required | Brief session summary | "Discussed month-end close bottleneck and Pooja's role transition" |
| conversation.outcomes | Required | Key outcomes/decisions | ["Agreed to redesign month-end SOP", "Ruben to provide current checklists"] |
| conversation.fullRecap | Recommended | Full narrative recap | Extended paragraph covering session flow |
| wins[] | Optional | Client wins surfaced in session | { title, detail, date } |
| actions[] | Required | Action items with ownership | { task, owner: mine/client/team, sourceDate, dueDate } |
| quotes[] | Recommended | Exact client quotes | { text, context, speaker, date } |
| gpsSignals | Recommended | Position, direction, speed signals | { position, direction, speed } — any field may be null |
| seeds[] | Optional | Products/services discussed | { name, status, nextSteps } |
| constraintMentions[] | Optional | Constraint breadcrumbs (NOT source of truth) | { constraint, context, frequency } |
| recommendations[] | Recommended | Advisor recommendations | { text, status, linkedConstraint, incongruenceFlag, incongruenceNote } |
Validation Rules
- conversation.date, type, summary, outcomes — all four required or reject the extraction
- actions must have owner field (mine/client/team) — flag if missing
- quotes must be verbatim — never paraphrase, even if they seem incomplete
- gpsSignals may have null fields — process what's present, ignore nulls
- constraintMentions are breadcrumbs ONLY — do not add to Constraints Diagnosed
Input 2: Constraint Priority Matrix (advisor-generated)
Produced from the client's weekly constraint brief. Source: Advisor analysis via the Constraint Priority Matrix project.
| Field | Priority | Description | Example |
|---|---|---|---|
| constraints[] | Required | Prioritized constraint list | Array of constraint objects |
| constraint.name | Required | Constraint name | "Accounting Manager Operating System Undefined" |
| constraint.description | Required | What the constraint is and why it matters | Extended description |
| constraint.type | Required | Upstream or downstream | "upstream" or "downstream" |
| constraint.upstreamOf | Required (if upstream) | Which constraints this causes | ["#2", "#3", "#4", "#5"] |
| constraint.downstreamOf | Required (if downstream) | Which constraint causes this | "#1" |
| constraint.category | Required | Capability category | "Operational Systems" |
| constraint.tier | Required | Priority tier | "Tier 1 — Maximum Priority" |
| constraint.status | Required | Current status | "Open" / "In Progress" / "Solved" / "Resurfaced" |
| constraint.patternFlags | Recommended | Recurring/compounding/cluster flags | ["recurring", "compounding", "cluster"] |
| constraint.blocks | Recommended | Which GPS Direction goal this blocks | "40 new clients / 100% retention" |
| constraint.occurrenceCount | Optional | How many times this pattern has appeared | 3 |
| gpsConfirmation | Recommended | Whether matrix confirms or changes GPS signals | Narrative comparison |
| sessionPrepBrief | Optional | Key questions/angles for next session | Bullet list |
Validation Rules
- Every constraint needs name, description, type, category, tier, status — flag if any missing
- Upstream constraints must list what they're upstream of
- Downstream constraints must reference their upstream cause
- Pattern flags should cross-reference with existing Client Master Plan themes — flag connections
Input 3: Manual Input
Direct text from the advisor. No fixed format. May contain:
| Content Type | Priority | Description |
|---|---|---|
| Corrections | High | Name spellings, date fixes, misattributed quotes |
| Context additions | Medium | Background info, relationship history, team details |
| Status updates | Medium | Action completions, seed status changes, engagement updates |
| Coaching notes | Low | Observations for advisor's reference only |
| Initiative updates | Medium | Build completion, deployment status, pre-work received |
Processing Rule
Advisor corrections override all other data sources. If manual input conflicts with JSON extraction or matrix output, manual input wins.
Data for Project Plans
When creating a Project Plan, pull from the Client Master Plan:
| Field | Source | Required |
|---|---|---|
| Client name + company | Client Master Plan header | Yes |
| Relevant constraints (subset) | Client Master Plan constraints section | Yes |
| Related GPS signals | Client Master Plan GPS | Yes |
| Supporting quotes | Client Master Plan quotes section | Recommended |
| Related themes | Client Master Plan themes section | Recommended |
| Stakeholders (team roster subset) | Client Master Plan team roster | Yes |
| Related recommendations | Client Master Plan recommendations | Recommended |
| Related seeds | Client Master Plan seeds | Yes |
Additionally required from advisor or Build Design Agent:
| Field | Source | Required |
|---|---|---|
| Initiative name | Advisor | Yes |
| Deployment plan (builds, sequence) | Build Design Agent output | Yes |
| Pre-work questions | Build Design Agent output | Recommended |
| Tool access requirements | Advisor | Recommended |
| Deployment methodology notes | Advisor | Recommended |
Project Plan → Client Blueprint Rule
The Project Plan and its paired Client Blueprint MUST pull all proper nouns from the Client Reference Data file. Never pull from transcript or JSON. If a name appears differently in a transcript than in Reference Data, Reference Data wins.