Contents

A PWD* designation granted in July.
It takes effect from March.

Four months of payments were right when the ministry made them. They are now an underpayment: four months a client went without money they turn out to have been owed. The current system keeps only today's answer. It rewrites history instead of recording it. What did we know, when did we know it, and how do we prove it? This design keeps all three.

* Persons With Disability

Monthly entitlement the system would report, by the month asked about (columns) and the month the question was asked (rows). The highlighted cell matches the two sliders below.
Asked inMarAprMayJunJulAugSepOct
Oct$1,535.50$1,535.50$1,535.50$1,535.50$1,535.50$1,535.50$1,535.50$1,535.50
Sep$1,535.50$1,535.50$1,535.50$1,535.50$1,535.50$1,535.50$1,535.50$1,535.50
Aug$1,535.50$1,535.50$1,535.50$1,535.50$1,535.50$1,535.50$1,535.50$1,535.50
Jul$1,535.50$1,535.50$1,535.50$1,535.50$1,535.50$1,535.50$1,535.50$1,535.50
Jun$1,060$1,060$1,060$1,060$1,060$1,060$1,060$1,060
May$1,060$1,060$1,060$1,060$1,060$1,060$1,060$1,060
Apr$1,060$1,060$1,060$1,060$1,060$1,060$1,060$1,060
Mar$1,060$1,060$1,060$1,060$1,060$1,060$1,060$1,060

Asked in Jun about May, the system reports a monthly entitlement of $1,060.

Current version of the record: At application in March, no disability designation is in place.

Today the system reports $1,535.50 for May. The payment actually made that month was correct when it was issued, and is now an underpayment of $475.50.

Move either slider. The left one changes the month you ask about. The right one changes the month you ask in. The hard edge across the grid is the July decision reaching back over every earlier month. That is what a backdated decision looks like when the system keeps both axes.

Current State

Two ministries run case management: Children and Family Development, and Social Development and Poverty Reduction. The work covers assistance payments, service requests, social work, loss recovery and client support. All of it depends on a worker seeing the full picture. The work is life-critical. A wrong answer means someone might not eat this month, or a child misses a check-in.

Two systems do the work. One is an Oracle Siebel customer relationship management product, adapted for government. The other is a mainframe built in 1982. They run side by side and share the core programs between them. Every attempt to retire the mainframe has stalled or failed.

The New Design is Built on Three Pillars

Evidence, not 'facts'

The system will not store "this person is an adult." It stores this: on 14 July, AI agent ID-33422 read the uploaded image of identification, matched it to the case, and read the date of birth as 22 April 1988. Business rules then decide the person is an adult. Who or what decided, when, and on what basis all sit in the record. They do not sit in an attached PDF, or outside the system altogether.

Evidence

Apt boundaries

Two ministries with broad mandates carry a very mixed portfolio. The current system forces all of it into one rigid model. That is how a design turns brittle. Here each program family gets its own model.

Domains

A decision you can re-run

Every entitlement decision stores the rules, the engine, the facts it saw, its own reasoning, the template of the letter the client was sent, how up to date its facts were, and what kind of decision it was. A manager four days later, or a tribunal years later, can re-run it instead of piecing it together from memory.

Determinations

Why do backdates matter?

Much of case management is building one clear timeline as information arrives. It does not arrive in order, and what turns up later can change what earlier events meant. In the backdated designation above, the client spent four months short of what they were owed. Someone on assistance has no savings to absorb that. The same machinery runs the other way too. It lands on the same person, who then has to pay the money back.

When someone is paid too much, the money falls into one of two classes. If the client's circumstances changed and they told the ministry late, it is a recoverable overpayment. The ministry takes it back at $10 a month, out of a payment that was already only just enough. If the ministry held the information all along and did not act on it, that is administrative error, and the client should not carry it.

Telling those two apart means knowing when the ministry knew. That is a transaction-time question. A system that records only when a fact was true cannot answer it. Nor can one that stamps every moved record with the date it moved. Almost the whole overpayment backlog sits in records from before any cutover.

Mispayment is one example of many. Evidence has to back nearly every claim a client makes. That cycle of claim, evidence and proof is the core loop of the whole service.

How this is modelled

Every evidence assertion carries three time dimensions: valid_time (the period in the world for which the fact holds), recorded_at (when this system learned it), and legacy_asserted_at (when the old system asserted it, where the old record still shows that).

The third axis is nullable. It carries a confidence value of DECODED, INFERRED or UNKNOWN. On UNKNOWN, any consumer working out a knowledge-state answer must return INDETERMINATE. It must not quietly substitute the migration timestamp.

None of this can be added later. Events are immutable: you can add a field with a default, but you cannot fill it in afterwards. The axis has to exist before the first production event.

What this site covers

These pages set out the domain model, and the thinking behind the least conventional choices. Each one leads in plain English and keeps the technical statement behind a disclosure.

The design comes from the law, from policy and from the nature of the work, not from the old system. Current State gives the context: how the work is done today, and what the design must not repeat. Parameters lists the twenty-one rules the design has to hold to, each with the check that catches a breach.