Skip to content
MirrorFirm

How do invariant and link checks catch a wrong allocation in a clinic billing environment?

A health fund payment is applied to the wrong household account, passing arithmetic invariants but failing a check that follows the claim reference link.

A patient accounts officer at a medical clinic receives payment PAY-9032 for 640.00 from a private health fund. The remittance cites claim CLM-3377. In the environment, CLM-3377 links to INV-6140 on account ACC-5511, outstanding 640.00. A second account, ACC-5510, belongs to the same guarantor household and has INV-6102 outstanding at 410.00 and INV-6120 at 230.00.

The agent matches on the guarantor name and calls `apply_allocation` for 640.00 against INV-6102. The environment rejects it with code OVER_APPLY, because the allocation would exceed the 410.00 outstanding. The agent adjusts, applying 410.00 to INV-6102 and 230.00 to INV-6120. Both calls pass every arithmetic invariant.

**State after the episode:** ACC-5510 shows zero outstanding, ACC-5511 still shows INV-6140 overdue at 640.00, and the audit log shows a clean sequence.

**What the grader finds:** a link check compares each allocation's payment reference with the claim-to-invoice link. It finds that no allocation touches INV-6140 and flags the episode as MISDIRECTED_ALLOCATION.

**Consequence in the workflow:** the household would receive a reminder on the wrong account and the fund's claim would look unpaid.

**What it teaches:** invariants catch impossible states, not plausible wrong ones. A grader needs link-aware checks, and the data needs near-identical sibling accounts to make the test meaningful.

Arithmetic invariants catch impossible states, but only link-aware checks catch plausible wrong ones, so a grader needs both.

Audience:
Environment builders
Content type:
Scenario
Buyer question:
How to evaluate it

Content release: r-a220eb6e099b243b

More on Payment allocation