1. The Question — Could a Single Project Carry the Work?
A Claude Project carries four first-class artifacts:
- System instructions — the durable spec loaded at every conversation start.
- Reference files — the curated material the Project quotes from.
- Governance config — data tier, restricted topics, escalation path, audit cadence.
- Workflow doc — how the team uses it.
The financial_modeling work has all four of those things. The question is whether they hold together inside one Project that one user operates, or whether the work demands the eleven-agent dispatch architecture that Stage 4 supplies.
2. What Fits — The Stage 3 Compression of financial_modeling
Most of financial_modeling's surface compresses into a Project cleanly. The instructions, the references, the governance, and the workflow doc all already exist in the repo.
CLAUDE.md as-is
The real CLAUDE.md in the financial_modeling repo already reads as Project instructions. Mission, audience map, scope rule §12.1, writing standards, self-audit checklist. Lift straight in.
references/expertise/ (13 files)
Damodaran, Tufte, Knaflic, Hyndman, McKinsey, Bridgespan, Few, NACUBO NCSE, AFP (Tier 1) plus BoardSource, CFA IPS, NFF, NACUBO Spending Policy (Tier 2). Load them at conversation start.
From the audience map
Tier 3 working surface; Tier 2 for committee-facing outputs. Restricted topics from scope §12.1 (Finance team owns GL/990/ASC 958 — Project routes away). Escalation paths named to real people.
HOW_IT_WORKS.html-style page
How an analyst uses the Project: paste the latest workbook output, ask for a scenario read, get the diligence trace, edit, send. The page that explains the moves for any teammate.
That compression carries most of what financial_modeling does. An analyst with this Project could ask plain-English questions about FY27 raise targets, the implied draw curve, the operating-gap surface — and get answers grounded in the curated references.
Hypothetical Project — system-instructions opener# Role You are the financial_modeling assistant for DC CAP. Help Preston, the Investment Committee, the Finance Committee, and the Board reason about DC CAP's financial position now and projected through FY35. Strategic and analytic only; the Finance team owns GL accounting, Form 990, and ASC 958 disclosures (scope §12.1). # Three views the work supports 1. Costs that exist (current spend by program and category) 2. What we are committed to (multi-year obligations, lease, pledges) 3. What we can control or cut (discretionary; what SLT and Board face) That three-way visibility feeds Development (how much do we need to raise), Finance (how much will the draw be), Operating (what can we hold back or defer). # Reference files loaded at conversation start - references/expertise/*.md (13 canonical sources) - The latest fpa-data-engineer JSON output (workbook intake) - The board memo precedent - The named-donor schedule (Tier 2; restricted topics apply) # Skills loaded inside this Project - preston-writing (voice) - dc-cap-org-intelligence (verified facts) - executive-summary-formatter (board memo structure) - funder-framing (funder-type voice when needed) - data-interpreter (audience adaptation) # What you do not do - No GL accounting answers (route to Finance team). - No Form 990 line-item answers (route to Finance + auditor). - No invented numbers. Every value traces to a loaded source. - No em-dashes, no forbidden constructions, no equity language. # Verification cadence Standard gate for analyst-facing surfaces; full gate (Preston reviews) before anything reaches an audience tagged in the audience map.
3. What Belongs as Skills the Project Loads
Voice patterns, framing rules, and audience-adaptation logic all belong as Skills — chained inside the Project. financial_modeling already loads these BRAIN skills at Stage 4; the Stage 3 Project would load the same set, the same way.
| Skill | Why it stays a Skill |
|---|---|
| preston-writing | Voice discipline travels across many surfaces. Loaded by the Project for narrative output, by other Projects elsewhere in BRAIN, by other agents. Trigger-on-demand is the right shape. |
| funder-framing | Four named funder types (Gates-style major foundation, corporate, government, individual). Loaded when the Project is preparing funder-bound output. Skill makes sense across many hosts. |
| dccap-brand | Color tokens, typography, logo usage. Loaded by frontend-class work in the Project; same skill loads in deck-class work elsewhere. |
| dc-cap-org-intelligence | Verified facts and framing rules — partner list, outcomes, the narrative arc. Loaded by every Project that touches a DC CAP claim. |
| executive-summary-formatter | Board memo structure. Loaded by the Project when producing committee artifacts; loaded elsewhere in BRAIN for strategic-memo work. |
| data-interpreter | Metric framing and audience adaptation. Loaded when the Project is translating quant output for a specific committee audience. |
| program-budget-intake | The 29-sheet workbook structure, parser anchors, intake runbook. Loaded when the Project (or any data-engineer-class work) ingests a new workbook. |
Each skill is one expertise pattern. Each one stays in its lane. The Project chains them by declaring which ones load at session start. The same chain that runs inside the financial_modeling agents at Stage 4 runs inside the hypothetical Stage 3 Project.
4. What Belongs as Agents — Why the Compression Has a Ceiling
Some pieces of financial_modeling cannot live inside a Project. They need to live as named agents with distinct roles and explicit handoffs — and that is what Stage 4 supplies.
| Function | Why it stays an agent |
|---|---|
| fpa-data-engineer | Parser intake with per-cell provenance and L1+L2 hard-gate enforcement. Runs scripts. Writes JSON state files other agents read. The Project's reference-loading model cannot run scripts with verification semantics. |
| fpa-quant | Math layer with Hyndman prediction intervals, L3 cross-foot enforcement. Executes computations. Halts lanes on mismatch. A Project's chat surface cannot enforce a hard-gate halt across roles. |
| fpa-insight-hunter | Pareto + Damodaran bias diagnostic + the "three numbers that matter" extraction. Pattern detection across the cleaned data — a distinct cognitive lane that needs its own scope. |
| fpa-analyst | Drift classification, Bridgespan PWIT, cost-per-outcome. Reads insight-hunter output; produces interpretation. Distinct role with explicit handoff state. |
| fpa-strategist | Damodaran 3P story-test, McKinsey ROIC matrix, Big Idea drafting. Reads analyst output; produces strategic recommendation. The 3P verdict is a gate the storyteller cannot paper over. |
| fpa-modeler | AFP driver-based budgeting, rolling forecasts, variance bridges. Distinct numerical discipline from fpa-quant — projection logic vs. computed scenarios. |
| fpa-viz | Tufte / Knaflic / Few applied to chart specs. Distinct from frontend implementation. Specifies what to show before fpa-frontend renders it. |
| fpa-storyteller | Knaflic Big Idea, Preston voice, audience-first. Reads strategist + insight-hunter + analyst output; writes the narrative. This is the lane where all the chained Skills come together — the Project version above is essentially a hand-run version of this single role. |
| fpa-frontend | React + Recharts + TypeScript + WCAG 2.2 AA. Implements viz specs. Code execution, brand tokens, accessibility checks. |
| fpa-architect | Methodology decisions, ADRs, scope-rule enforcement. Cross-cutting governance role. |
| fpa-lead | Orchestrator. Dispatches lanes. Verifies gates. Assembles Preston's review package. The Lead exists because the other ten agents need a router that does not do domain work. |
None of those can collapse into a single chat surface without losing something. They are distinct cognitive lanes with distinct expertise, distinct tool surfaces, and explicit handoff state. This is the difference between Stage 3 and Stage 4. Stage 3 carries one workflow surface; Stage 4 carries many roles that hand off to each other with verification gates in between.
5. The Real-Question Test — What Stage 3 Can Do
An analyst inside the hypothetical financial_modeling Project asks: "What is the implied draw curve from FY27 through FY35 under the latest Pathstone Base scenario, and which two assumptions move it most?"
The Project version of that conversation:
- Project instructions load. References load (Damodaran, Hyndman, NACUBO NCSE for base rates).
- The latest fpa-data-engineer JSON output is in the reference files (pasted in or attached).
- Claude reads the JSON. Pulls the draw rates by year. Names the assumptions.
- data-interpreter skill loads. Translates the numbers into Investment Committee voice.
- preston-writing skill loads. Writes the Big Idea sentence.
- Output: the curve summary + the two-assumption sensitivity + a diligence block.
That works. The analyst gets a usable answer. The voice is right. The numbers trace to the loaded JSON. For most strategic questions Preston might ask, this Stage 3 version delivers — and the workflow doc explains the moves for any teammate to replicate.
What it cannot do is reproduce the answer next month after the workbook restructures, the Pathstone scenarios refresh, and the parser anchors shift. The L2 parser hard-gate would catch the structural drift at Stage 4. The Stage 3 Project has no equivalent — the analyst would feed in the new JSON and the Project would do its best with whatever was passed.
6. What Gets Lost If You Stop at Stage 3
Most of the work, most of the time
- Plain-English questions about scenarios, draw curves, raise gaps.
- Narrative output in Preston voice via chained Skills.
- Audience-adapted framing (analyst vs. committee).
- Reference-grounded answers when the references are loaded.
- Iteration cadence (refresh references and instructions on a known schedule).
The audit trail across roles
- Per-cell provenance — no L1 enforcement on intake.
- Parser hard-gate — no L2 halt on structural drift.
- Runtime cross-foots — no L3 enforcement between computed and source totals.
- Defaults alignment — no L4 reconciliation against IC-approved set.
- Explicit handoff state — agents writing state files the next agent reads.
- Lead routing without domain work — verification stays separate from production.
- Reproducibility — same workbook in, same surfaces out, automatically.
The Stage 3 compression keeps the strategic content. It loses the audit-trail discipline that survives KPMG, Investment Committee scrutiny, and Board defense across multiple meeting cycles. For an internal working surface, that loss is tolerable. For the canonical financial picture the Board votes on, it is not.
7. The Decision — When Stage 3 Is Enough, When Stage 4 Earns Its Cost
The thought experiment produces a real decision tree the cohort can apply to their own work.
Stage 3 (a Project) is enough when:
- One person or one team owns the workflow end to end.
- The verification cadence is the operator's own read of the diligence block.
- The output does not need to survive a third-party audit (committee, regulator, external auditor).
- The workflow is multi-step but does not need explicit handoff state between distinct cognitive lanes.
- Five different teammates running the Project on the same input would produce equivalent output (the workflow is consistent because the Project is consistent).
Stage 4 (an Orchestration) earns its cost when:
- The audit trail itself is the deliverable — any value must trace to a source cell.
- Three or more cognitive lanes need to run with verification gates between them.
- The work crosses three or more refresh cadences (in financial_modeling: weekly Development, per-cycle Finance, quarterly Pathstone).
- An external party — KPMG, the Investment Committee, a regulator — would ask "where did this number come from" and expect a per-cell answer.
- One agent's wrong output must halt the lane before the next agent reads it.
Most pilot builds will not need Stage 4. financial_modeling does. Knowing which is the discipline this artifact teaches.