The parts that decide whether this survives contact with a real registry

Every engine is a pure function whose rule set carries a version, and `asOf` is an argument rather than a clock read. That combination is what makes a figure reproducible: the same inputs and the same version produce the same rupees on any future day, on any machine, including one belonging to the person disputing it.

Rule sets are never edited in place. A change to the arithmetic is a new version, and the version is printed next to the figure it produced, so an old screenshot can always be reconciled against the rules in force when it was taken.

This is also why the circular-override layer is data handed to the engine rather than a branch inside it. Due dates moved twice by circular last season. An engine that can only be corrected by a deploy is an engine that is wrong for every day between the circular and the deploy.

On the WhatsApp channel the idempotency key is the Meta message id, and it is claimed with an INSERT into `whatsapp_messages` before the reply is composed. The insert IS the lock. A check-then-set would race against the very retry it exists to catch, and Meta retries on any non-2xx and on its own timeouts.

The same discipline applies to account linking: a one-time code is redeemed in the UPDATE itself, conditional on `consumed_at IS NULL`, so two messages carrying the same code cannot both succeed. Reading first and writing second would let both through.

Filing is not implemented here and therefore charges nobody. When it is, the key is the SRN, not a request id: a resubmission of the same SRN is one filing in two attempts, and a fee engine that keys on the request would bill the retry.

Fail closed, say so, and never imply that anything succeeded. The concrete case in this build is the company register: it is served from an official open dataset over a shared, rate-limited key.

A throttled lookup is not the same fact as an absent company, and the code refuses to collapse them. A 429, or a 200 carrying a rate-limit error body, returns `register-unavailable` with an explanation — never the six demonstration companies, and never "no match". The distinction is enforced one level lower too: a degraded lookup is not written to the cache, because caching a throttle would pin "no such company" over a company that exists for the next hour.

The model layers degrade the same way. No key, a timeout, a refusal or an exhausted budget all return unavailable, and the deterministic answer underneath is unaffected — which is the point of keeping the legal content out of the model in the first place.

Possession of a phone number is not authority for a statutory act. The WhatsApp channel is therefore permanently read-only: no filing, no payment, no consent grant, no profile change is reachable from it, and every action that would alter a record hands off to the portal. That is a structural property, not a policy — there is no write path in that module to disable.

Binding a channel to an account requires proof of both sides: a signed-in browser session mints a six-character code, valid ten minutes, redeemable once, and sending it from the handset completes the pair. No one can bind a number to an account they cannot already sign into.

Identifiers are hashed before storage. The binding table is the one place a phone number would sit beside a DIN, and that pairing is worth more to an attacker than either column alone.

Inbound webhooks are verified before they are parsed: HMAC-SHA256 against the app secret, compared in constant time. A webhook URL is public, and without that check anyone who learns it can impersonate the platform.

The filing lifecycle records an actor, a reason and a timestamp on every state transition, and the inbox is DERIVED from those timestamps rather than written alongside them.

That choice is deliberate and it is the interesting one. An events table has to be written by something, and the thing that writes it eventually misses a case — and a missing row in an inbox is invisible, because nobody notices the notice that never came. Deriving means a notice exists exactly when the underlying fact does, and asking "what did this account look like on the day that scheme closed" answers itself.

This is the part the product is actually for, because the value is arriving before the money starts rather than explaining it afterwards. It is also the only part of this build that runs when nobody is looking at a page.

It is a separate Worker on its own Cron Trigger, on the pattern already used for the data pipeline, so a slow or failing delivery run cannot take the citizen portal down. Daily it reads the live subscriptions, recomputes each company through the same pure engine the website uses, and decides whether anything has changed enough to be worth saying.

Two properties decide whether it is trustworthy rather than annoying. It fires on a TRANSITION rather than on a day — thirty days out, seven days out, the day a filing becomes overdue, and once more at thirty days late — and each notice is claimed by an INSERT on a unique (subscription, transition) key, so the second attempt is refused by the database rather than by a conditional someone can forget. And it recomputes rather than storing a figure, so a reminder can never quote a number the portal disagrees with.

What is NOT working is delivery to arbitrary addresses: Cloudflare delivers only to verified Email Routing destinations, so most rows record `blocked-unverified` rather than pretending to have been sent. The scheduling, the arithmetic and the refusal to send twice are unaffected, and all three are visible in the run record.