Determinations

Someone can challenge a decision about their entitlement years after the ministry made it. So the design treats every decision as something you re-run, not something you remember.

The problem with asking a system what it decided

Ask a typical case management system why a person got a particular amount in March 2022 and it will work the sum again. It uses today's rules, today's data and today's software, then reports the answer with confidence. The answer may well be right. Nobody can tell, and nobody can show a tribunal the difference.

Three things have shifted underneath since March 2022. Policy changed. The person's recorded circumstances changed, perhaps several times. And someone upgraded the software. A rules engine upgrade can change how the same rule reads, and nobody notices until a client appeals.

Treating a decision as a function

The design makes entitlement a calculation with no hidden inputs. It reads the rules, the facts and the date it is deciding for. While it runs it does not read the clock, query a database, or call another service. It gets everything it needs up front.

That rule sounds academic. It is what makes the next part work: if nothing hidden went in, then storing what went in is enough to reproduce what came out.

The function signature

Determine(rulesArtefactVersion, evidenceSnapshot, referenceDate) → DeterminationResult

Pure: no input or output, no clock reads, no database access, no service calls. No rules engine gives you this on its own. The shell around the engine enforces it. The engine runs in-process against a snapshot passed by value, and that is what puts byte-identical replay within reach rather than in the brochure.

Five things stored with every decision

Storing the answer is not enough. Storing the answer and the rules is still not enough. The system binds five artefacts into the record at the moment it makes the decision.

• 1 The rules Content digest, tagged and immutable once released Stored
• 2 The engine Version number and the archived binary Stored
• 3 The facts it saw Copied in full into the record, never referenced Stored
• 4 The reasoning Which rules fired and which branches were taken, in a ministry-owned format Stored
• 5 The letter Content-hashed template, resolved at decision time Stored

The decision can be replayed.

Four years on, the same inputs produce the same answer, the reasoning can be read aloud, and the letter the client received can be reproduced.

Teams leave out the fifth one most often. A decision that reproduces perfectly, next to a letter nobody can rebuild, still misses the question the tribunal asked. That question is often about what the person was told, not about what the system worked out.

How long replay has to work

Archiving the software tells you what it was. It does not promise that anything in twenty years can still run it. The operating system, the processor and the container runtime all die younger than a child protection record, which the ministry keeps for ninety years.

Rather than leave that hanging, the design commits to a horizon in three stages and writes it down in advance.

1. Years 0–7

   We archive the software itself and test it every quarter to confirm it still runs. Seven years covers the appeal, reconsideration and audit paths that really do re-run a decision.

2. Years 7–20

   The rules live on as a written specification, with a test suite that any rebuild has to pass. The suite stays independent of the engine from day one, so this handover costs nothing when it comes.

3. Beyond 20 years

   The stored reasoning, the letter and the facts are the record. Re-running stops being on offer. This is what a paper file has always been.

Re-running a decision proves what the rules worked out. It does not prove the rules matched the policy in force at the time. So every rule carries the policy it comes from and the date that policy took effect. The ministry does not publish old versions of its policy manual, and its archive of old rate tables has gaps. So for each family of rules the horizon also records how far back the policy itself can still be produced. Before that date, the stored reasoning, the letter and the facts are the record, and the ministry says so in advance.

Where the policy version is kept

The policy citation and its effective-date marker sit inside the rules artefact, which the decision record binds by its content digest. There is no sixth artefact. The horizon statement records, per rule family, the earliest effective date for which the governing policy text or rate can be produced from a retained source. Historical rates are harvested once, at ingest, rather than fetched later from an archive with no retention commitment.

Two decisions made moments apart can disagree

Storing the inputs makes replay reliable. It says nothing about whether the inputs were gathered consistently. That is where the remaining gap sits.

Gathering the facts means reading across several stores that update on their own schedules. Two decisions issued seconds apart, with one store briefly behind, can each see a different world quite legitimately. Both replay perfectly. Both are reproducible. They disagree, and nothing described so far catches it. So the design pins each snapshot to a point in the sequence of recorded events. A later reader can then tell which view of the world a decision was made against.

Before a decision: a letter that is not one

Sometimes the ministry writes to a client before it decides: this is what we found, this is what it may mean, reply by this date. That letter is not a decision, and the system keeps it separate from one. It carries its reasons, its reply-by date and a plain statement that no decision has been made. Whatever the client sends back is recorded as evidence for the decision that follows.

A client can still ask for a reconsideration at that point. The request is always recorded, and nobody turns it away at the counter. Whether a reconsideration is available is decided by the independent reconsideration unit, not by the worker who sent the letter.

When a decision is challenged

A decision that is overturned is never edited. The original stays in the record as what was decided, with everything it was based on. The new decision sits beside it, with its own record, and says what caused it. The client's history shows both, in order, with reasons. The money owed either way is worked out from the difference between the two.

The appeal tribunal can confirm the ministry's decision or rescind it. It cannot change it part way, and it cannot send it back. An appeal can also end without the tribunal deciding, because the client withdrew it or abandoned it. The system records how the appeal ended and, only if the tribunal decided, what it decided. A rescinded decision is marked, never erased, and the ministry then decides again.

A client waiting for a reconsideration or an appeal may keep receiving assistance at the old level. That money is paid on a promise to repay whatever the final decision does not support. The system holds it as repayable from the day it is paid, linked to the decision it is waiting for, and settles it automatically when that decision is made.

How challenges are modelled

PreDecisionCommunication belongs to Eligibility & Entitlement, in the shell around Determine, never inside it. Its amount is a class (iii) output, it carries a no_decision_made marker, and its reply window is a statutory clock artefact. Reconsideration availability is a DiscretionaryDetermination recorded in Evidence & Verification by the Reconsideration and Administrative Fairness Unit; Appeals & Reconsideration reads it and never writes it. Appeal outcome is two attributes: disposition (decided, withdrawn, abandoned) and panel determination (confirmed, rescinded). Interim assistance is a RepayableIssuance in Financial Components, resolved on the awaited DeterminationIssued; on denial it becomes an overpayment component classified by policy.

Decisions that affect people carry their own classification

Every rule carries a label saying what kind of decision it produces. Some produce an administrative decision, which needs reasons. Some produce a decision a person has to make before it takes effect. The rest are working sums that affect nobody on their own.

That label travels with the decision into the letter. A decision that goes against someone sends out its reasons, its appeal period and the route to challenge it, because the label says it must. Not because somebody remembered.