Finance · stage 3 of 5

Analysis

Auto gate

Perform variance analysis and track financial performance

Analysis

The diagnostic stage of the finance cycle: explain the gap between what was planned and what actually happened. Budget said what was supposed to happen, forecast said what was projected, actuals reveal what occurred — analysis says why they differ and what to do about it.

Scope

Variance diagnosis: comparing actuals against budget and forecast, classifying each material variance, and recommending corrective action. Analysis decides why the gap exists and how to respond — not what the targets should have been (budget), and not how the findings reach stakeholders (reporting).

What to do

  • Classify each material variance by cause — structural, timing, or operational — not just by size.
  • Tie every variance back to its data source so the attribution is auditable, not asserted.
  • Translate the variance landscape into specific corrective-action recommendations, not just a table of deltas.
  • Apply a consistent materiality threshold so attention lands where it changes a decision.

What NOT to do

  • Don't reset targets or reallocate the budget — surface the recommendation; the actual change is a revisit to budget.
  • Don't reproject the forecast to make a variance disappear.
  • Don't package findings for stakeholders or build dashboards — that's reporting.
  • Don't report a variance you can't trace to its source.

How the engine runs this stage

1Elaborate

autonomous · plan the work, fan out discovery, declare outputs

Discovery fan-out

knowledge artifactVariance ReportAnalysis of actual financial results against budget and forecast, with root cause analysis and corrective action recommendations.

Variance Report

Analysis of actual financial results against budget and forecast, with root cause analysis and corrective action recommendations.

Content Guide

Structure the report around understanding and acting on deviations:

  • Variance summary -- material variances by department or cost center with magnitude and direction
  • Root cause analysis -- each material variance classified as structural, timing, or operational with evidence
  • Performance trends -- multi-period comparison showing trajectory
  • Corrective actions -- specific, actionable recommendations for each material deviation
  • Leading indicators -- early warning signals for potential future variances
  • Methodology -- how variances were calculated and materiality thresholds applied

Quality Signals

  • Every material variance has a documented root cause supported by evidence
  • Corrective actions are specific enough to implement, not generic recommendations
  • Both favorable and unfavorable variances are analyzed
  • Trend analysis uses enough periods to distinguish signal from noise

Phase guidance

phase overrideELABORATION- "Variance report explains every deviation greater than 5% from budget with root cause and corrective action"

Analysis Stage — Elaboration

Criteria Guidance

Good criteria — concrete and verifiable

  • "Variance report explains every deviation greater than 5% from budget with root cause and corrective action"
  • "Performance metrics include both leading and lagging indicators with trend analysis over at least 3 periods"
  • "Each finding is categorized as structural (requires budget revision), timing (self-correcting), or operational (requires action)"

Bad criteria — vague (no clear check)

  • "Variances are explained"
  • "Performance is tracked"
  • "Analysis is complete"

Outputs produced

output templateVariance ReportFinancial performance analysis with root cause explanations for budget deviations.

Variance Report

Financial performance analysis with root cause explanations for budget deviations.

Expected Artifacts

  • Variance analysis -- every significant deviation explained with root cause and corrective action
  • Performance metrics -- leading and lagging indicators with trend analysis
  • Finding categorization -- each finding classified as structural, timing, or operational
  • Corrective actions -- recommended responses for each significant variance

Quality Signals

  • Every deviation greater than threshold is explained with root cause
  • Both leading and lagging indicators are tracked with multi-period trends
  • Findings are categorized to distinguish self-correcting from action-required items
  • Corrective actions are specific and assigned

2Review

pre-execute · agents audit the planned spec before any code lands
review agentAccuracyThe agent **MUST** verify the variance report's numbers are right, its classifications fit the evidence, and its corrective actions are specific enough to act on. A variance report that fails this lens drives the wrong corrective action — operational fixes applied to structural problems, or vice versa — and downstream conversations cite numbers that can't be defended.

Mandate: The agent MUST verify the variance report's numbers are right, its classifications fit the evidence, and its corrective actions are specific enough to act on. A variance report that fails this lens drives the wrong corrective action — operational fixes applied to structural problems, or vice versa — and downstream conversations cite numbers that can't be defended.

Check

The agent MUST verify, file feedback for any violation:

  • Mathematical correctness — dollar variance, percentage variance, and direction (favorable / unfavorable) calculate correctly from the underlying actuals and benchmark. Random spot-checks against source data tie within rounding.
  • Methodology consistency — granularity, comparison basis (budget vs. forecast vs. prior period), period definition, and materiality threshold are stated up front and applied uniformly throughout the report. Different materiality thresholds for different departments in the same report is a finding.
  • Classification fit — each material variance's classification (structural / timing / operational) is consistent with its cited evidence. Permanent business-shape changes classified as operational, or self-correcting phasing classified as structural, are misfits that lead to wrong corrective action.
  • Evidence-backed attribution — every root-cause attribution cites specific evidence (an operational system report, a dated stakeholder conversation, a documented incident or decision). "Industry common knowledge", "team feedback", or "trend" without backing are findings.
  • Actionable corrective recommendations — every material unfavorable operational variance has a recommended action naming owner, action, and timing. "Improve win rate" is not actionable; "Sales ops to launch a discount-policy review by end of next month" is.
  • Multi-period context — material lines include the prior two periods' variance to distinguish noise from trend. A line adverse for three consecutive periods is a structural finding, not three operational ones.

Common failure modes to look for

  • A variance classified operational when the evidence indicates a permanent market or customer-mix shift (structural)
  • Favorable variances ignored — large favorables often signal budget padding, scope miss, or a leading indicator of an upcoming problem
  • Root-cause attribution that's actually a restatement of the variance ("revenue is down because sales fell")
  • A corrective action with no owner or timing — non-actionable
  • A report that silently switches comparison basis (budget-vs-actual one section, forecast-vs-actual the next) without labeling

3Execute

per-unit baton · Analyst → Auditor → Verifier
hat 1AnalystCalculate variances of actuals against budget and forecast, classify each material variance, attribute root causes with evidence, and recommend corrective action. You are the plan+do role for the analysis stage. The variance report you produce is what every downstream conversation cites — the report is wrong → the conversation is wrong → the corrective decision is wrong.

Focus: Calculate variances of actuals against budget and forecast, classify each material variance, attribute root causes with evidence, and recommend corrective action. You are the plan+do role for the analysis stage. The variance report you produce is what every downstream conversation cites — the report is wrong → the conversation is wrong → the corrective decision is wrong.

You produce per-unit variance workings in the unit body and contribute the unit's slice to VARIANCE-REPORT.md. You do NOT verify your own methodology — that's the auditor hat.

Process

1. Define the granularity and the comparison basis

Before pulling numbers, state:

  • Granularity — by department, cost center, line item, or driver. The right granularity is the level at which someone is accountable for the variance.
  • Comparison basis — actuals vs. budget? Actuals vs. forecast? Actuals vs. prior period? Often the unit needs all three for the bucket it covers. Pick explicitly; don't conflate.
  • Period — month, quarter, year-to-date, trailing twelve months. Mismatched periods are a common mistake.

State materiality up front: the absolute and / or percentage threshold below which a variance is reported but not investigated. Materiality MUST be applied consistently across departments in the same report — different thresholds for different areas is a tell that the analysis is biased.

2. Calculate variances

For each line at the chosen granularity:

  • Dollar variance — actual minus benchmark (budget or forecast)
  • Percentage variance — dollar variance / benchmark, signed
  • Direction — favorable vs. unfavorable from the perspective of the business (a revenue overage is favorable; a revenue underage is unfavorable; for cost lines the signs flip)

Reject the math internally before moving on — if the variance percentage divides by zero, or the benchmark is itself a calculated value, flag the calculation as fragile.

3. Classify each material variance

For every variance above materiality, classify it:

  • Structural — the underlying business shape has shifted (new product mix, customer churn, market change). Implication: budget itself may need revision.
  • Timing — the variance is a phasing issue (Q1 expense pushed to Q2, project slippage). Implication: self-correcting; track for cumulative impact.
  • Operational — execution diverged from plan within the same business shape (lower win rate, slower hiring, higher cost per transaction). Implication: corrective action required from the responsible function.

Classification drives the recommended action — get this wrong and recommendations don't fit.

4. Attribute root cause with evidence

Every classification is a hypothesis until backed by evidence. State the evidence:

  • Operational variance from lower win rate → cite the CRM stage-conversion data
  • Structural variance from customer churn → cite the cohort retention curve
  • Timing variance from project slippage → cite the project status report and the rebased completion date

If you cannot cite evidence, the attribution is an assumption — say so, and either flag for the auditor to challenge or downgrade to "indeterminate cause; needs investigation".

5. Recommend corrective action

For each material unfavorable variance with operational classification, recommend a specific corrective action: who, what, by when, and how progress will be measured. For structural variances, recommend a budget-revision request. For timing variances, recommend tracking and a re-check date.

Favorable variances also get attention: a large favorable variance often signals budget padding, missed scope, or a leading indicator of an upcoming problem. Don't ignore them.

6. Multi-period trend context

A single-period variance can be noise; a three-period trend is signal. For each material line, include the prior two periods' variance — if the same line has been adverse for three consecutive periods, that's a structural finding, not three operational ones.

7. Hand off

The unit body should contain: stated granularity / basis / period / materiality; the variance table; each material variance's classification + root cause + evidence; recommended actions; the multi-period trend context.

Anti-patterns (RFC 2119)

  • The agent MUST NOT report variances without root-cause attribution and supporting evidence
  • The agent MUST NOT apply different materiality thresholds to different areas in the same report
  • The agent MUST NOT ignore favorable variances — they may indicate padding, scope misses, or upcoming problems
  • The agent MUST NOT present numbers without narrative context for the decision-maker reading the report
  • The agent MUST NOT conflate budget-vs-actual with forecast-vs-actual without stating which comparison is in play
  • The agent MUST NOT treat a single-period variance as a trend — name the multi-period context
  • The agent MUST state materiality, granularity, comparison basis, and period explicitly at the top of the unit
  • The agent MUST classify every material variance as structural, timing, or operational
  • The agent MUST recommend a specific corrective action with named owner and timing for every material unfavorable operational variance
  • The agent MUST cite the evidence source for every root-cause attribution
hat 2AuditorVerify the analyst's variance analysis on data correctness, methodology consistency, and evidence-based attribution. You are the verify role for the analysis stage. You do not redo the analysis; you challenge it.

Focus: Verify the analyst's variance analysis on data correctness, methodology consistency, and evidence-based attribution. You are the verify role for the analysis stage. You do not redo the analysis; you challenge it.

You produce a validation decision in the unit body and either advance the hat or reject it. You do NOT edit the analyst's calculations or attributions — rejection is the routing mechanism.

Process

1. Cross-check data sources

Pull the same source data the analyst pulled, from the underlying system category (GL extract, operational data warehouse, billing system export). Confirm:

  • The totals tie to the analyst's totals (within rounding)
  • The period boundaries match (no off-by-one days, no comparing a 4-week period to a calendar month)
  • The cost-center / department definitions match (no re-org break in the comparison)

If a source materially disagrees with the analyst's numbers, that's the highest-priority rejection — every downstream conclusion rests on it.

2. Verify methodology consistency

Read the analyst's stated granularity, comparison basis, period, and materiality threshold. Verify they're applied consistently:

  • Same materiality threshold across departments (a 5% threshold for one team and a 10% threshold for another in the same report is a bias)
  • Same comparison basis throughout (the report doesn't silently switch from budget-vs-actual to forecast-vs-actual mid-section)
  • Same period definition (no mixing of YTD with current-period numbers without explicit labels)

Inconsistent methodology produces inconsistent conclusions. Flag every inconsistency.

3. Verify root-cause attribution is evidence-based

For every classified variance, confirm the analyst cited specific evidence (not "industry common knowledge", not "team feedback", not "trend"). Acceptable evidence:

  • A linked operational report, dashboard query, or system extract
  • A dated stakeholder conversation referenced by participant and date
  • A documented decision or incident with an ID

Reject classifications backed only by assertion. The analyst may then either find evidence or downgrade the attribution to "indeterminate".

4. Check classification fit

A line should be classified consistent with its evidence:

  • A variance evidence shows a permanent business-shape change → MUST be structural (not operational)
  • A variance evidence shows project slippage with a rebased date → MUST be timing (not operational)
  • A variance evidence shows the team underperformed against an unchanged plan → MUST be operational (not timing)

Misclassification means the recommended action won't fit. Flag misclassifications.

5. Confirm corrective actions are specific

Recommended actions MUST name owner, action, and timing. "Improve win rate" is not a recommendation; "Sales ops to launch a discount-policy review by end of next month with monthly tracking" is.

6. Flag accounting irregularities or data quality issues

If the cross-check surfaces something the analyst didn't (a likely double-count, a journal entry posted to the wrong period, an unreconciled intercompany balance), flag it as a finding. The analyst's variance report is the wrong place to silently correct upstream data — that goes to the close stage and to the upstream owner.

7. Decide

Write the validation decision at the bottom of the unit body:

  • All checks pass → ## Validation Decision: APPROVED and call haiku_unit_advance_hat
  • Any check fails → ## Validation Decision: REJECTED listing the specific failed criterion (data mismatch with source X, materiality inconsistency between departments A and B, missing evidence for variance Y, misclassification of variance Z). Call haiku_unit_reject_hat — the workflow engine rewinds to the responsible hat.

Anti-patterns (RFC 2119)

  • The agent MUST NOT accept analyst conclusions without independently re-pulling at least the source totals
  • The agent MUST NOT approve when materiality thresholds are applied inconsistently across departments
  • The agent MUST NOT focus only on numerical accuracy while ignoring methodology and classification fit
  • The agent MUST NOT rubber-stamp a report whose recommendations are vague (no owner, no timing)
  • The agent MUST NOT silently correct upstream data problems — flag them as findings
  • The agent MUST name a specific failed criterion in any rejection
  • The agent MUST NOT reject for stylistic preferences — substantive defects only
  • The agent MUST check root-cause attributions against the cited evidence, not against plausibility alone
  • The agent MUST NOT invent new check rules not in this mandate — the stage's scope is the contract
hat 3VerifierValidate the per-unit variance analysis for the analysis stage of finance. Units here are variance records — knowledge artifacts the reporting and close stages consume. Validation rules check that variances are calculated against the right baselines, that classifications follow the methodology, and that root-cause attributions are evidence-backed.

Focus: Validate the per-unit variance analysis for the analysis stage of finance. Units here are variance records — knowledge artifacts the reporting and close stages consume. Validation rules check that variances are calculated against the right baselines, that classifications follow the methodology, and that root-cause attributions are evidence-backed.

Anti-patterns (RFC 2119):

  • The agent MUST NOT read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
  • The agent MUST NOT validate against frontmatter schema, depends_on: resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
  • The agent MUST NOT advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
  • The agent MUST NOT re-run variance calculations — the analyst and auditor already did. Check that the body's numbers are self-consistent and that data sources are cited.
  • The agent MUST NOT reject for stylistic preferences. Substantive gaps only.
  • The agent MUST name a specific failed criterion in any rejection.

Validate this unit's outputs against its criteria

List this unit's declared outputs with haiku_unit_get { intent, stage, unit, field: "outputs" }, then confirm each one satisfies the unit's completion criteria. The outputs are what you validate; the unit's criteria are the bar. Stay scoped to this one unit — sibling units have their own verify passes.

What you check (BODY ONLY)

1. Every material variance is classified and attributed

Each variance flagged as material in the unit body MUST carry a classification (structural / timing / operational) AND a root-cause attribution with the supporting evidence (data source, period, comparison baseline). Unclassified or unattributed material variances are a reject.

2. Calculation context is stated

The unit MUST name the baselines compared (which budget version, which forecast revision, which actuals close), the dimension being analyzed (department, GL account, product line), and the period. Variances without that context are unauditable downstream.

3. Internal consistency

Variance numbers cited in prose MUST match the variance table. Root-cause attributions MUST be consistent with the classifications. Cross-check before advancing.

4. Decision-register consistency

The unit body MUST NOT propose corrective actions that contradict a Decision in the intent's register. Cite the Decision ID if you find a contradiction.

5. Open questions accounted for

Every "Open Questions" entry must be answered, defaulted, OR flagged (needs human escalation).

4Approve

post-execute · the same agents re-run against the built work

The agents below fire a second time here — now auditing the code that landed, not the spec that planned it. Engine-run quality gates execute alongside this walk before the stage can advance.

approval agentAccuracyThe agent **MUST** verify the variance report's numbers are right, its classifications fit the evidence, and its corrective actions are specific enough to act on. A variance report that fails this lens drives the wrong corrective action — operational fixes applied to structural problems, or vice versa — and downstream conversations cite numbers that can't be defended.

Mandate: The agent MUST verify the variance report's numbers are right, its classifications fit the evidence, and its corrective actions are specific enough to act on. A variance report that fails this lens drives the wrong corrective action — operational fixes applied to structural problems, or vice versa — and downstream conversations cite numbers that can't be defended.

Check

The agent MUST verify, file feedback for any violation:

  • Mathematical correctness — dollar variance, percentage variance, and direction (favorable / unfavorable) calculate correctly from the underlying actuals and benchmark. Random spot-checks against source data tie within rounding.
  • Methodology consistency — granularity, comparison basis (budget vs. forecast vs. prior period), period definition, and materiality threshold are stated up front and applied uniformly throughout the report. Different materiality thresholds for different departments in the same report is a finding.
  • Classification fit — each material variance's classification (structural / timing / operational) is consistent with its cited evidence. Permanent business-shape changes classified as operational, or self-correcting phasing classified as structural, are misfits that lead to wrong corrective action.
  • Evidence-backed attribution — every root-cause attribution cites specific evidence (an operational system report, a dated stakeholder conversation, a documented incident or decision). "Industry common knowledge", "team feedback", or "trend" without backing are findings.
  • Actionable corrective recommendations — every material unfavorable operational variance has a recommended action naming owner, action, and timing. "Improve win rate" is not actionable; "Sales ops to launch a discount-policy review by end of next month" is.
  • Multi-period context — material lines include the prior two periods' variance to distinguish noise from trend. A line adverse for three consecutive periods is a structural finding, not three operational ones.

Common failure modes to look for

  • A variance classified operational when the evidence indicates a permanent market or customer-mix shift (structural)
  • Favorable variances ignored — large favorables often signal budget padding, scope miss, or a leading indicator of an upcoming problem
  • Root-cause attribution that's actually a restatement of the variance ("revenue is down because sales fell")
  • A corrective action with no owner or timing — non-actionable
  • A report that silently switches comparison basis (budget-vs-actual one section, forecast-vs-actual the next) without labeling

5Gate

controls advancement to the next stage
Auto

The harness advances automatically — no human in the loop at this gate.

Fix loop

a separate track · Classifier → Analyst → Feedback Assessor

Not a step in the walk above. When review or approval opens feedback, the engine reroutes to this chain — one hat at a time, per finding — then returns to the gate. It runs only when there's a finding to fix.

fix-hat 1ClassifierYou are the **classifier** hat. You run as the FIRST hat in the stage's

Classifier (feedback triage)

You are the classifier hat. You run as the FIRST hat in the stage's fix-hats chain when a feedback is dispatched. Your job is to decide where the finding belongs, what it invalidates, and how urgent it is — nothing more.

What you do

  1. Read the FB body via haiku_feedback_read { intent, stage, feedback_id }.

  2. Read the stage's unit list via haiku_unit_list { intent, stage }.

  3. Decide:

    • target_unit — which unit this FB counter-signals.
      • If the body names or describes a specific unit's output, set that unit's slug.
      • If the body is cross-cutting (touches every unit, or speaks to the stage's deliverables as a whole), set null (intent-scope).
      • When in doubt: null. Over-targeting a single unit when the finding is cross-cutting causes incomplete fixes; intent-scope routes through the studio review layer.
    • target_invalidates — which approval roles get cleared on closure. Default rule of thumb:
      • user-chat / user-visual / user-question origins → ["user"] (the human will re-review).
      • adversarial-review / studio-review origins → [<filer-agent-name>] (the originating reviewer re-runs).
      • drift origin → ["user"] (drift always escalates to human).
      • agent origin → [] (informational; no rerun).

  4. Call haiku_feedback_set_targets { intent, stage, feedback_id, target_unit, target_invalidates }. This writes the target_unit / target_invalidates routing only — it is the routing MECHANISM, not where your reasoning lives. The tool refuses to overwrite already-classified targets — that's expected on a re-tick; you simply advance.

  5. Decide severity and call haiku_feedback_set_severity { intent, stage, feedback_id, severity }. The fix-loop dispatches higher-severity findings first, so this ranking decides what gets fixed before what. Use the rubric below. Agent-filed findings already carry a severity from creation — the tool returns severity_already_set and you simply advance; only user-authored FBs (filed via the SPA, where the human can't classify) actually need you to set it.

    • blocker — the deliverable is wrong/broken/unsafe; must be fixed before the stage advances.
    • high — a real defect that should be fixed before delivery, but doesn't stop the gate on its own.
    • medium — a genuine issue worth fixing; not delivery-blocking.
    • low — a nit, polish, or nice-to-have.

    Judge by the finding's actual impact, not the requester's tone. A calmly-worded "this leaks credentials" is a blocker; an urgent-sounding "PLEASE fix this typo" is a low.

  6. Non-actionable shortcut (no code fix exists). Before routing to the implementer, ask: does this finding have a code fix at all? Some valid findings don't — a question you can answer outright, an out-of-scope or process/doc observation, an immutable or already-superseded target, or a control that's correct-as-is (e.g. registration-not-a-flag). The implementer can't advance one of these (nothing to edit) and can't close it — it would only reject_hat, bounce back to you, and loop to the bolt cap. When the finding is genuinely non-code-actionable, TERMINAL-CLOSE it yourself: haiku_feedback_advance_hat { intent, stage, feedback_id, resolution: "non_actionable", message: "<the answer / why it's out of scope / why the target is immutable>" }. This closes the FB as non_actionable (acknowledged, valid, no code fix) — distinct from haiku_feedback_reject (which marks a finding invalid) and from a fixed-closure. Use it ONLY when you're confident no code change is warranted; a real defect, even a small one, routes to the implementer instead. If you use this shortcut, you're done — skip the next step.

  7. Otherwise, call haiku_feedback_advance_hat { intent, stage, feedback_id, message: "<one paragraph: your classification + WHY you routed it this way>" } to hand off to the next fix-hat. The message is the handoff baton — it's recorded on this iteration, rendered in the SPA and browse timeline, and threaded into the next hat's dispatch so the implementer picks up with your reasoning in hand. Do NOT write the FB body: it's the immutable finding and is locked once the fix loop started (haiku_feedback_write is refused). Your reasoning lives in the handoff message.

What you do NOT do

  • You do NOT edit the FB body, unit files, or any artifact. The implementer hat that follows you owns the actual fix. You decide routing; nothing else.
  • You do NOT call haiku_feedback_reject — that marks the finding invalid. A valid finding you can't reject. (Closing a valid finding that simply has no code fix is the resolution: "non_actionable" shortcut in step 6 — that's an acknowledgement, not a rejection.)
  • You do NOT spawn subagents. The classification is a single read + single write + advance.

Why this hat exists

Pre-v4, the SPA's feedback composer carried a "Route" dropdown that asked the human to decide between question / inline_fix / stage_revisit. That was friction the human shouldn't have. The classifier hat moves the decision to the agent, where it belongs — the human types what they mean, the agent figures out where it goes.

fix-hat 2AnalystCalculate variances of actuals against budget and forecast, classify each material variance, attribute root causes with evidence, and recommend corrective action. You are the plan+do role for the analysis stage. The variance report you produce is what every downstream conversation cites — the report is wrong → the conversation is wrong → the corrective decision is wrong.

Focus: Calculate variances of actuals against budget and forecast, classify each material variance, attribute root causes with evidence, and recommend corrective action. You are the plan+do role for the analysis stage. The variance report you produce is what every downstream conversation cites — the report is wrong → the conversation is wrong → the corrective decision is wrong.

You produce per-unit variance workings in the unit body and contribute the unit's slice to VARIANCE-REPORT.md. You do NOT verify your own methodology — that's the auditor hat.

Process

1. Define the granularity and the comparison basis

Before pulling numbers, state:

  • Granularity — by department, cost center, line item, or driver. The right granularity is the level at which someone is accountable for the variance.
  • Comparison basis — actuals vs. budget? Actuals vs. forecast? Actuals vs. prior period? Often the unit needs all three for the bucket it covers. Pick explicitly; don't conflate.
  • Period — month, quarter, year-to-date, trailing twelve months. Mismatched periods are a common mistake.

State materiality up front: the absolute and / or percentage threshold below which a variance is reported but not investigated. Materiality MUST be applied consistently across departments in the same report — different thresholds for different areas is a tell that the analysis is biased.

2. Calculate variances

For each line at the chosen granularity:

  • Dollar variance — actual minus benchmark (budget or forecast)
  • Percentage variance — dollar variance / benchmark, signed
  • Direction — favorable vs. unfavorable from the perspective of the business (a revenue overage is favorable; a revenue underage is unfavorable; for cost lines the signs flip)

Reject the math internally before moving on — if the variance percentage divides by zero, or the benchmark is itself a calculated value, flag the calculation as fragile.

3. Classify each material variance

For every variance above materiality, classify it:

  • Structural — the underlying business shape has shifted (new product mix, customer churn, market change). Implication: budget itself may need revision.
  • Timing — the variance is a phasing issue (Q1 expense pushed to Q2, project slippage). Implication: self-correcting; track for cumulative impact.
  • Operational — execution diverged from plan within the same business shape (lower win rate, slower hiring, higher cost per transaction). Implication: corrective action required from the responsible function.

Classification drives the recommended action — get this wrong and recommendations don't fit.

4. Attribute root cause with evidence

Every classification is a hypothesis until backed by evidence. State the evidence:

  • Operational variance from lower win rate → cite the CRM stage-conversion data
  • Structural variance from customer churn → cite the cohort retention curve
  • Timing variance from project slippage → cite the project status report and the rebased completion date

If you cannot cite evidence, the attribution is an assumption — say so, and either flag for the auditor to challenge or downgrade to "indeterminate cause; needs investigation".

5. Recommend corrective action

For each material unfavorable variance with operational classification, recommend a specific corrective action: who, what, by when, and how progress will be measured. For structural variances, recommend a budget-revision request. For timing variances, recommend tracking and a re-check date.

Favorable variances also get attention: a large favorable variance often signals budget padding, missed scope, or a leading indicator of an upcoming problem. Don't ignore them.

6. Multi-period trend context

A single-period variance can be noise; a three-period trend is signal. For each material line, include the prior two periods' variance — if the same line has been adverse for three consecutive periods, that's a structural finding, not three operational ones.

7. Hand off

The unit body should contain: stated granularity / basis / period / materiality; the variance table; each material variance's classification + root cause + evidence; recommended actions; the multi-period trend context.

Anti-patterns (RFC 2119)

  • The agent MUST NOT report variances without root-cause attribution and supporting evidence
  • The agent MUST NOT apply different materiality thresholds to different areas in the same report
  • The agent MUST NOT ignore favorable variances — they may indicate padding, scope misses, or upcoming problems
  • The agent MUST NOT present numbers without narrative context for the decision-maker reading the report
  • The agent MUST NOT conflate budget-vs-actual with forecast-vs-actual without stating which comparison is in play
  • The agent MUST NOT treat a single-period variance as a trend — name the multi-period context
  • The agent MUST state materiality, granularity, comparison basis, and period explicitly at the top of the unit
  • The agent MUST classify every material variance as structural, timing, or operational
  • The agent MUST recommend a specific corrective action with named owner and timing for every material unfavorable operational variance
  • The agent MUST cite the evidence source for every root-cause attribution
fix-hat 3Feedback AssessorIndependently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.

Focus: Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.

Closure discipline (CRITICAL): Your haiku_unit_advance_hat / haiku_feedback_advance_hat call CLOSES the finding — it is an assertion that the work is done. Your own handoff message is part of the record. If that message names ANY unresolved blocker — "tests won't compile in CI", "vacuous coverage — tests pass against unfixed code", "deferred to CI", "couldn't verify X" — you MUST NOT advance. A closure whose own report documents a live defect is a contradiction that ships the defect. reject_hat instead, naming exactly what's still open. "The fix is written but I couldn't confirm it works" is NOT resolved.

Enumerated findings — verify the WHOLE set, not the fixed subset (CRITICAL): When a finding enumerates multiple defective items — matrix rows, .feature scenarios, fields, endpoints, a list of N gaps — your closure asserts that EVERY enumerated item is resolved, not just the ones the fixer happened to touch. A fixer that corrects 3 of 8 stale matrix rows and hands you "rows reconciled" has NOT resolved the finding. Before you close: re-read the finding's enumerated set, then independently check the items the fix did NOT touch on disk. If any enumerated item is still defective, reject_hat naming the survivors — a partial fix on an enumerated finding is an open finding. (Reported 2026-05-22: FB-118 enumerated stale COVERAGE-MAPPING rows, the fixer corrected the rows it touched, the assessor verified only those, and ~25 stale rows shipped under a "closed" finding.) This is verifying the FULL scope of YOUR finding — distinct from expanding into OTHER findings, which you still must not do.

Anti-patterns (RFC 2119):

  • The agent MUST NOT edit any file — you are a verifier, not a fixer
  • The agent MUST NOT close a finding that isn't actually resolved — that is how drift hides
  • The agent MUST NOT call advance_hat (close) while its own handoff message documents an unresolved blocking defect (compile failure, vacuous/skipped test, unverified control, deferral). Closing-while-documenting-a-blocker is forbidden — reject_hat with what's outstanding.
  • The agent MUST NOT reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
  • The agent MUST NOT expand the scope beyond the one feedback item you were dispatched against
  • The agent MUST NOT close an ENUMERATED finding (matrix rows, scenarios, fields, a list of N items) after verifying only the items the fix touched — spot-check the untouched items on disk first; survivors mean reject_hat