A system saying “done” is not the same as a system proving “done.”
A parcel can be marked delivered while sitting at the wrong door. A payment can be accepted but not settled. A repair can be completed locally while the receiver still experiences failure. A student can produce one correct answer without having reached stable understanding.
The gap between a claimed state and a proven state is where state validation matters.
State validation is the process of gathering enough evidence to justify that the system really is in the condition its record, interface or operator says it is in.
A State Claim Needs an Evidence Rule
“Open,” “approved,” “safe,” “mastered,” “settled,” “delivered” and “recovered” are all state claims.
Each should have an evidence rule: what observations, records or conditions must exist before the label is justified?
- Delivered: what proves receipt?
- Settled: what proves final movement of the financial claim?
- Safe: which measurements and interlocks must be within limits?
- Mastered: what performance under what conditions is enough?
- Recovered: what end-to-end function must be restored?
Without an evidence rule, state becomes a label people can apply differently.
Validation Is Stronger Than Self-Reporting
A component can report its own state, but the report may be incomplete.
A software service may return “success” because it finished its local task while a downstream system rejected the result. A maintenance worker may close a job because the repair action was performed, even though the asset has not yet been tested under load.
Strong validation therefore asks for evidence beyond the actor’s declaration when consequence justifies it.
Component State and Receiver State Are Different
A component can be healthy while the system-level outcome is broken.
A lift motor may work while a station remains inaccessible because another lift in the route has failed. A lesson may have been delivered correctly while the student cannot use the concept independently. A payment gateway may accept a transaction while the merchant does not receive usable confirmation.
This means validation often needs two layers:
- local validation: did the component reach its intended state?
- end-to-end validation: did the receiver experience the intended result?
This distinction is central to How Repair Routing Works.
Validation Depends on Invariants
An invariant is a condition that should remain true when the system is in a valid state.
A financial ledger may require balances to reconcile. A safe railway state may require separation and door conditions. A valid data record may require identity, format and referential relationships to remain consistent.
Validation checks whether the claimed state satisfies these protected relationships, not only whether one visible output looks correct.
Positive Evidence and Negative Evidence
Some states are validated by proving something happened. Others are validated by showing that prohibited conditions are absent.
- Positive: receipt signature exists; sensor confirms alignment; learner solves independently.
- Negative: no unresolved fault remains; no duplicate payment exists; no safety interlock is open.
The absence of evidence is not automatically evidence of absence. Negative validation often needs active checks designed to detect the prohibited state.
Freshness Matters
A state can be valid at 10:00 and invalid at 10:01.
Validation must therefore include a time relationship between observation and decision.
High-speed safety decisions need very fresh state. Long-duration institutional facts may remain usable longer. A learner’s mastery claim may need revalidation after time has passed because retrieval strength can change.
This connects validation to state synchronisation: evidence must not only be correct but current enough for the decision.
Independent Checks Increase Confidence
When consequences are serious, one channel of evidence may not be enough.
A system can compare independent sensors, reconcile records, require a second approval or test the function through a different path.
The purpose is not ritual duplication. It is to reduce the chance that one shared failure mode creates a false state claim.
Validation Can Be Sampled
Some systems cannot inspect every unit or every future condition.
They validate by sampling: quality-control inspection, audit, assessment items, load tests or statistical monitoring.
The claim must then match the evidence. A sample can support a statement about expected quality under specified conditions; it cannot magically prove every unobserved case.
This is why evidence design and state validation are closely related. See How Evidence Works and How Explanation Testing Works.
Worked Example: A Parcel Marked Delivered
The carrier’s internal state changes to delivered after a scan.
But what should validate the state?
- GPS or location context may support that the scan happened at the intended place.
- A photograph may support physical placement.
- A signature may support receipt by a person.
- A customer acknowledgement may support successful end-to-end delivery.
Each evidence type validates a slightly different claim. “Driver scanned parcel” is not identical to “correct recipient received parcel.”
Worked Example: A Repair
An engineer replaces a failed component. The component powers on. Is the system recovered?
Local validation says the replacement works. End-to-end validation may still require the whole service to operate under normal load, alarms to remain clear and the receiver to regain the required function.
The repaired state is therefore not “part replaced.” It is “required function restored and verified.”
Worked Example: Learning
A student gets five questions correct immediately after instruction.
That validates something: the learner can perform under recent, matching conditions.
It does not yet validate durable, independent transfer.
A stronger mastery claim may require delayed retrieval, mixed questions, reduced prompting and an unfamiliar problem where the student must choose the method rather than being told which one to use.
The lesson is not to make assessment endless. It is to match the strength of the state label to the strength of the evidence.
False Positive and False Negative States
Validation systems can make two broad errors.
- False positive: claim the desired state exists when it does not.
- False negative: reject a valid state that actually exists.
Safety-critical systems may strongly prefer avoiding false positives. High-volume service systems also care about false negatives because excessive rejection creates friction and queues.
Validation thresholds therefore encode trade-offs. The right balance depends on consequence.
A State Validation Sequence
- Define the state claim precisely.
- Define the invariants that must hold.
- Identify direct observations and records that support the claim.
- Check freshness and provenance.
- Use independent evidence where consequence justifies it.
- Test the receiver-side outcome where relevant.
- Record unresolved uncertainty rather than hiding it.
- Only then promote the system into the validated state.
Validation Is the Gate at the End of a Transition
Guard conditions ask whether a transition may begin. State validation asks whether the transition truly finished.
Together they form a disciplined pair:
Before: are the conditions right to cross? After: what evidence proves we reached the state we intended?
This pattern appears in machines, finance, institutions, education, healthcare, logistics and the larger mechanisms of civilisation.
Return to the master How X Works hub to continue from boundaries and state change into interfaces, feedback, failure, repair and the wider blueprint of how civilisation keeps claims connected to reality.