Evidence
ICM tracks facts. It overwrites fields and buries history. In the new system the unit of information is a dated claim, tied to its evidence and to whoever made it. Later work can disprove that claim, confirm it, overturn it or replace it, and nothing is lost on the way.
Why not store facts?
A system that stores only the current state, "Income: $900", leaves the important questions open. How do we know? What evidence is there? When did we know? Is this the corrected number, or the number we recorded at the time?
Front-line staff adapt, so the information is not lost. It is just not modelled. It goes into notes, forms and attachments, and only a thin slice of it is ever held as data.
This is not an auditing nicety. It closes the gap between how the system holds data and how front-line staff work. Substantiating evidence against claims is the most common task a worker performs, and the system does not model it at all, so it is done by hand. Social workers spend hours mapping their notes onto a structure that serves the software rather than their clients.
So the unit the system records, and the unit its parts exchange, is an assertion:
The four things that can happen to an assertion
Once the system records something, nobody edits it in place. Four operations change what the system believes. They differ in one respect: what each does to the period the claim covers.
The world changed.
- valid time
- a new period
- transaction time
- now
The earlier assertion stays true for its own period. The new one takes over from a later date.
For example A partner moves in on 1 May, and the client reports it.
If this produced an overpayment, the classification rule reads the operation as the world having changed.
That distinction is why the model exists. It is a policy rule written into the shape of the data. It applies consistently because the record itself names the operation that caused the recalculation. Nobody has to guess at it afterwards.
The operation feeds the classification without settling it. Who caused the error matters too. A client who hid a relationship is not in the same position as a worker who mis-keyed a figure. The model promises something narrower and more useful: the question has an answer at all, and the answer comes from the record rather than from whoever opens the file today.
Where a conventional record gives up
Take the assertion above to a tribunal. The client accepts a relationship exists but disputes that it began in January. Three separate things are now in question, and they are easy to confuse:
- What the ministry believed about the household in each of those eight months.
- When the ministry changed its mind, and on what evidence.
- What start date the ministry now asserts.
A conventional design holds one relationship start date, plus an audit entry saying a worker changed it on 12 September. That answers the third question, gestures at the second, and cannot touch the first. It leaves the eight monthly payments looking like errors. Each one was the right answer to what the ministry knew at the time.
The operations, formally
| Operation | Valid time | Transaction time | Meaning |
|---|---|---|---|
RecordEvidence | asserted period | now | We learned a new fact |
SupersedeEvidence | new period | now | The world changed |
CorrectEvidence | same period | now | We were wrong about the world |
InvalidateEvidence | closed | now | The assertion should never have existed |
The aggregate is the evidence succession set: the stream of versions of one logical fact about one subject. Commands append events; current state is a projection. Verification status transitions are themselves events.
The third date, and the history problem
Two time axes are standard. This design carries a third, because the new system inherits fifteen years of records from systems that are still running.
Old records all arrive on the same day. Make that migration date the "when we learned it" date and every historical fact looks as though it arrived at the same moment. Supersede and Correct then look identical across the whole pre-cutover record. The overpayment rule stops working on exactly the records where most overpayments sit.
The third axis holds the date the old system asserted the fact, where the old record still shows it. Often it cannot be read at all, so the date carries a confidence marker. Where the answer is unknown, the system says so rather than guessing.
The period in the world for which the fact holds.
Set by whoever asserts it, from the source.
When this system learned it.
Set at recording. Never changes.
When the previous system asserted it, if that can be decoded.
Set at migration. Often unknown, and marked as such.
Nobody can add this later. Events are immutable: you can introduce a field with a default, but you cannot fill it in afterwards. Either the migration decoded the source or it did not. So the decision has to come before the first production record.
Confidence values and replay behaviour
legacy_asserted_at travels with legacy_assertion_confidence, which takes DECODED (read straight
from the legacy record or audit trail), INFERRED (worked out from a related
artefact by a written rule) or UNKNOWN.
On UNKNOWN, any consumer working out a knowledge-state answer must return INDETERMINATE. That covers the overpayment rule, a tribunal reconstruction
view and a disclosure history. An overpayment whose classification is INDETERMINATE is treated as administrative error unless a person reclassifies
it on recorded evidence. Valid-time questions, such as recalculating an amount, go ahead
and are marked TEMPORALLY_UNVERIFIED. For a migrated fact, recorded_at is always the import time.
Backdated recalculation runs off valid time, which any competent migration preserves, so recalculation survives. Something narrower breaks without the third axis: what the ministry knew and when. That is the question separating a recoverable debt from the ministry's own error.
Every kind of evidence is registered, including judgement
Each kind of evidence, such as income or household composition, is registered before anyone can use it. The registration sets its shape, what counts as verifying it, how sensitive it is, how long it is kept and how it ends, and whose record it is. None of that is guessed later from where the data happens to sit.
One registered kind matters more than it looks: a worker’s judgement. Much of the work is a worker using a discretion the law gives them. The system records that as evidence too, as a discretionary determination. It names the law that gives the discretion, the authority the worker acted under, who decided, the evidence they weighed, and their reasons in their own words. A decision that rests on judgement can then be re-run like one that rests on arithmetic. Without it, the judgement ends up in case notes, and the decision rests on something nobody can find.
When a fact is corrected, every copy has to act
Other parts of the system keep their own copies of evidence (see Domains). When the source corrects a fact, every part holding a copy must be told, and must act. This is enforced. A part that holds a copy without listening for corrections fails its own release checks.
What happens to decisions already made from the old copy is a policy choice. Each program family sets it, and keeps it as a versioned rule. There are three answers. Re-open: make a fresh decision on the corrected facts. Annotate only: the outcome does not change, so the decision record notes the correction and why nothing followed. Flag for review: nobody can tell mechanically whether it matters, often because a worker’s judgement was one of the inputs, so a person decides.
Registered types, discretion and correction, formally
Evidence types live in a schema registry with versioned definitions. Each carries its schema, verification policy, security classification, retention and disposition class, custodianship and provenance requirements.
DiscretionaryDetermination is a registered type with a mandatory schema: discretion_head, authority_relied_on, decision_maker, rationale, factors_considered and outcome, with supervisory_endorsement where the discretion class
requires it. It is carried by value in the input snapshot like any other evidence. Whether
reconsideration is available is one such determination, recorded by the Reconsideration
and Administrative Fairness Unit.
EvidenceCorrectionRecorded is a mandatory subscription for every context that
holds a copy, checked at release by a fitness function. Every copy carries five stamps: source_context, source_evidence_id, source_evidence_version, source_transaction_time and copied_at. Each program family publishes its mapping from evidence type to
Re-open, Annotate-only or Flag-for-review as a versioned policy artefact, and the mapping in
force is recorded on the correction annotation.