Variance Reporting
Variance reporting is the explanation layer between planned cost and realized cost.
What Variance Answers
Section titled “What Variance Answers”- Where did the budget move?
- Which systems or subsystems changed?
- Which costs exceeded expectations?
- Was the cause market, design, logic, execution, or decision?
Provisional and Substantiated Variance
Section titled “Provisional and Substantiated Variance”Variance is reported dually:
| Type | Meaning |
|---|---|
| Provisional | All entries — including unsubstantiated ones |
| Substantiated | Only entries backed by a document, or by both an invoice number and a supplier |
There is no hard block on unsubstantiated entries. They contribute to provisional variance totals but are clearly distinguished from substantiated amounts. The same evidence rule applies across cost control: unsubstantiated entries never count toward commitment consumption or cancellation guards, only toward display and variance totals. See Actual Costs.
Variance Findings
Section titled “Variance Findings”A Variance Finding is a human-attributed explanation for a delta between budgeted and actual cost, linked to a specific cost group. Each finding includes:
- Cause code — one of five enforced values:
PRICE,QUANTITY,SCOPE,EXECUTION,DECISION - Note — optional free-text explanation. When AI-drafted, Darwin guards the language: it rejects overspend wording when the actuals are below the baseline and underspend wording when they are above it
- Source entity — optional link to the entity believed responsible (module, material, labor, or expense)
- Budget snapshot — budgeted, actual, and substantiated amounts are frozen at finding creation time so later edits cannot rewrite the finding’s story
Finding Lifecycle
Section titled “Finding Lifecycle”Open → InLearning → Resolved| Status | Meaning |
|---|---|
| Open | Finding exists; no work request created yet |
| InLearning | An active work request is linked to the finding |
| Resolved | Resolution outcome and timestamp are set |
Resolution Outcomes
Section titled “Resolution Outcomes”| Outcome | Meaning |
|---|---|
MODULE_UPDATED |
The relevant module was updated |
ASSUMPTION_DOCUMENTED |
An estimating assumption was recorded or corrected |
PRICING_PRACTICE_CHANGED |
Pricing approach was adjusted |
ACCEPTED_VARIANCE |
Variance is accepted as a legitimate outcome |
Learning Queue
Section titled “Learning Queue”The Learning Queue surface provides a dedicated view of variance findings organized by status: Open, InLearning, and Resolved. Findings can be escalated into governed work requests with Category == Learning for assigned follow-up.
Three-Layer Variance Analysis
Section titled “Three-Layer Variance Analysis”With commitments, variance can be drilled down as:
- Baseline → Commitment — procurement variance (did we buy at the planned price?)
- Commitment → Actual — execution variance (did final costs match the commitment?)
- Baseline → Actual — total project variance
Module Learning Accuracy
Section titled “Module Learning Accuracy”Resolved findings feed per-module learning history: each module records its cause and outcome counts, and a learning-accuracy score shows how well its estimated contribution matched actual costs over time. Only substantiated actual costs are used for accuracy — unsupported entries make a data point ineligible, so substantiating actuals is what keeps the learning signal trustworthy.
Why It Matters
Section titled “Why It Matters”Variance reporting is learning, not just control. When used well, it improves future module quality, pricing decisions, assumptions, and project planning discipline. Variance findings flow into the learning loop, connecting execution reality back to reusable cost logic.