Validation
For Both Executive and Technical Readers“Verified against exact enumeration” and “validated against reality” are different guarantees. We give both where data allows, and we are explicit about where only the first is possible.
01 The Gap
Verification and validation are two different guarantees. Most systems blur them.
An elicited model is more falsifiable than a black box, not less.
Most discussion of probabilistic models blurs two guarantees that should never be confused. Verification asks whether the inference is computed correctly, no algorithmic error. Validation asks whether the model’s claims match the world, when it says 0.7, does the thing happen about seven times in ten. Conflating them produces a system that is correctly wrong: exact inference on a miscalibrated model, presented with false confidence.
An elicited model is more falsifiable than a black box, not less. Every edge is a stated assumption. Every stated assumption is falsifiable and locatable. When something is off, you can point at the specific assumption and fix it, rather than retraining a vector no one can read.
02 The component
An elicited model is more falsifiable than a black box, not less.
Validation is a Cognitive Primitives, Epistemics component, and the instantiation of the Learn primitive. It runs three checks where data exists: calibration (when the model says 0.7, does reality oblige at that rate?), cross-validation (does the structure hold on held-out data?), and causal validation (do intervention predictions match observed experimental or natural experiment results?). Where data does not exist, it says so explicitly.
| Check | What it answers |
|---|---|
| Calibration | A reliability curve and a Brier score, when the model says 0.7, does reality oblige at that rate? |
| Cross-validation | A held-out log-score, does the structure generalise beyond the data it was fit on? |
| Causal validation | A match rate against natural experiments, where one exists, or marked not applicable, never guessed |
The honest_boundary field is mandatory. A ValidationReport without it is incomplete. Saying what you could not test is as important as saying what you could.
03 How it works
Reliability diagram. Held-out log-score. Do() predictions vs. observed interventions.
Calibration. When the model commits to a probability, does reality oblige at that rate? A reliability diagram, a plot of predicted probability against actual frequency, answers it directly: bin the cases where the model assigned p ∈ [0.6, 0.7], and check whether ~65% of them actually occurred. A well-calibrated model lies on the diagonal.
Cross-validation. Held-out log-score: train the parameters on a subset of historical data, evaluate on the rest. This tests whether the elicited structure generalises, not just whether it fits the training period.
Causal validation. Where natural experiments or historical interventions exist, check whether the model’s do() predictions match the observed post-intervention distributions. This is the hardest check and the most valuable, it tests the causal structure, not just the probabilities.
Where none of these checks are possible, because the events are rare, the interventions have never been made, or the data does not exist, the ValidationReport says so. That honesty is a feature.
04 The Brains
Not that it computes correctly, that what it computes is right.
Validation is the check that the brains is still right, not just that it is computing correctly, but that what it is computing reflects the world.
There is no .bayes file for Validation, Validation operates on any domain model. The ValidationReport is appended to the AuditRecord alongside the RobustnessReport. Together they constitute the evidentiary basis for trusting the model in production.
| Check | Result |
|---|---|
| Calibration | Brier score 0.08, well calibrated. Reliability curve lies close to the diagonal. |
05 Query in plain English
Is this model right, and how do we know?
Validation answers the question that precedes trust: is this model right, and how do we know?
The audit trail is the ValidationReport. The honest boundary is part of the audit trail.
06 Where it sits
Before production deployment and alongside Robustness as the second epistemic check.
Validation sits alongside Robustness (06) as the second epistemic check. It operates before production deployment (confirming the model is calibrated) and on a standing basis (re-running calibration checks as new data arrives via 11 Monitoring).
Upstream: historical data and the domain model parameters. Downstream: the ValidationReport appended to the AuditRecord, consumed by 12 BPMN Integration. Validation interacts closely with 11 Monitoring (which watches for calibration drift in production) and informs 02 Discovery (which parameters most need re-elicitation).