Stage 4 — The Technical Specification

Why this stage matters more than the analysis itself

Two ideas stack here:

1. Spec-driven design. The ability to specify analytical work precisely is more valuable than the ability to execute it. Execution scales — through teams, tools, and AI. Specification requires domain expertise that can't be delegated. This is what senior finance roles actually do: define the work, then judge the output.
2. LLM as drafter, you as editor. You don't write the spec from a blank page; you condition an LLM on the project materials and your workbook, then evaluate and revise until it's a document you'd sign.

The spec's anatomy

Part A — Model specification items 1–7

Enough detail to reconstruct your template and populated model from the document alone:

1. Scope & objective — company, fiscal period, reporting standard, currency, audience
2. Model architecture — tabs, color coding, input/calc/output separation
3. Data inputs — every data point with its numeric value from your Stage 3 workbook
4. Named range conventions — the full map of BAL_*, INC_*, CASH_*, RATIO_* to values
5. Derived inputs — averages, start-of-year figures, after-tax operating income, with explicit formulas
6. Ratio definitions — all 25+ ratios across the six categories, each with formula in named-range notation, expected unit, and a one-line interpretation guide
7. Validation rules — internal consistency checks: balance sheet balances, Du Pont ROE = direct ROE, etc.

Part B — Analysis specification items 8–11

8. Analysis requirements — per category: what to interpret, against what benchmarks, which cross-category connections to examine
9. Du Pont decomposition — specific ROE-breakdown instructions
10. Strategic recommendations — how many (3–5), what evidence standard, how actionable
11. Output format — exact section order, length targets, tone, audience

Cite numerically. "Total assets" is not a spec. BAL_assets_total_2025 = 394,328 (VND billions) is.

The human-in-the-loop (HIL) requirement

A single-shot LLM dump is below standard. You must show at least one documented iteration: you found a gap in the draft, understood why your prompt or spec caused it, and fixed it. Pick one form of evidence:

Specificity is the standard. "I asked it to expand the section" earns nothing. "Part A.4 listed BAL_assets_total without a year suffix, so the Stage 5 LLM wouldn't know which year to pull — I added the year-suffix convention and re-ran" earns full credit.

How to run the drafting session

1. Give the LLM: the Stage 4 brief (raw GitHub URL), the spec template (raw URL), your Stage 1 template (.xlsx upload), and your Stage 3 populated workbook (.xlsx upload).
2. Ask it to populate every section, keep the YAML frontmatter, use named-range notation throughout, and pull real numbers from your workbook into the Data Inputs table.
3. Good opening move: have it list the 3–4 assumptions it needs from you before drafting (standard, fiscal year, audience).
4. Iterate: expand sparse sections, tighten verbose ones, verify formulas tie to your template.
5. If a section keeps coming out weak — fix the prompt, not the output. Hand-editing hides the problem; re-prompting fixes the system that produces the document.

Submission checklist

• Spec at docs/specs/YYYY-MM-DD-{lastname}-{company-slug}-spec.md, YAML frontmatter intact
• Part A items 1–7 complete — every input value present numerically
• All 25+ ratios specified in named-range notation with units and interpretation guides
• Part B items 8–11 complete — benchmarks, Du Pont instructions, recommendation criteria, output format
• Validation rules included (balance check, Du Pont vs direct ROE)
• Prompt log updated with the drafting sessions
• HIL evidence committed — before/after note, round-2 prompt, or annotated diff
• Self-test passed: a fresh LLM given only the spec produces something substantially correct

Rubric

Check yourself