5. Worked cases
Two cases show the framework at work, and a third gives context. Harbourline is taken through every step on paper; the steps that need recorded runs could not be completed. Citigroup is analysed from the regulator's account and stops at the analysis gate. Northgate was analysed with NFE in the authors' working paper, not taken through this framework; it shows the same kind of loss in a different setting. Harbourline and Northgate are fictional; their agent runs are illustrative traces written to show reasoning, not recorded results. Appendix I gives the full records.
5.1 Harbourline: a claims payment, end to end
The decision. At 10:30 on 10 November 2026 a claims handler at Harbourline Mutual, a small-business property insurer, asks an AI assistant: "Can we pay Drywell's invoice INV-5531 on CL-2207 today?" The claim is a flood at a bakery on 28 October 2026. The invoice is £18,000, of which £3,000 is VAT the insured can recover. At A1 the question is rewritten to name every rule the answer depends on: how much of the invoice is payable under the terms in force on the date of loss, after the policy-year flood limit, VAT and the excess, and who may approve that amount? The decision is tier 3, a payment. The assistant's remit is to recommend.
The right answer. Seven rules decide it. The loss falls under the policy version in force on 28 October, with a flood limit of £40,000 for the policy year across all flood claims. Settled and pending payments in that year use £27,500 of it, so £12,500 remains; a cancelled payment does not count. The covered amount is £15,000 net of VAT. The excess was already taken on an earlier payment. The payable amount is therefore the lower of £15,000 and £12,500: £12,500. Because £12,500 is above the handler's £10,000 limit, the claims manager must approve it. This derivation, computed from the rules, is the oracle for the acceptance test.
The network. The case names eleven actors, among them the handler, the manager, the model, the client, the server, the tool descriptions, and three source systems. The framework's rule that every rule is carried by an inscription surfaced four more that the case had folded into systems: the policy wording, the authority matrix, the VAT rule, and a free-text memo field on the invoice. The mediation map follows the invoice amount through seven hops, with the policy system and the claims ledger joining at the server (Figure 1). One hop is a hidden mediator: accounts payable looks like a copy of the contractor's PDF, but turns "Total due" into an unqualified field called amount, which everyone downstream reads as the amount payable.
The losses. In the case's illustrative traces, the first design (v0) wraps the existing APIs one for one and answers that the full £18,000 can be paid. The case lists eight failures, each with a dimension. The framework records them as losses L1 to L8 and adds a mode to each, which the case had not done. Under the framework's definition, a loss's effect is the change in the decision's output when only that loss is present.
| Loss | Mode; dimension | Hop | Effect on the payment alone |
|---|---|---|---|
| L1 Reserve of £30,000 read as headroom | Substitute; semantic | Server to model | Not separable; it supports the wrong "yes" |
| L2 Policy version chosen by today's date | Re-time; temporal | Policy system to server | +£2,500 |
| L3 Pending payment left out | Narrow; source | Ledger to server | +£2,500 |
| L4 Cancelled payment counted (possible; not shown in the first design's traces) | Widen; source | Ledger to server | −£2,000 |
| L5 Limit taken per claim, not per year | Narrow; contextual | Server aggregation | +£2,500 |
| L6 Gross amount treated as covered | Re-base; transformation | PDF to accounts payable | £0 |
| L7 Excess deducted again | Repeat; transformation | Server rule | £0 |
| L8 Recommendation reported as approval | Promote; authority | Model to handler | Approval by the wrong role |
The case reports component effects: L6 overstates the payment by £3,000 and L7 understates it by £2,500. On this fixture both change the payment by £0, because the flood limit binds at £12,500. The distinction matters for testing: only assertions aimed at L6 and L7 directly can detect them, since the final amount does not move. No existing loss mode fitted L7, a deduction applied twice. The framework added a ninth mode, repeat.
Other findings. Four findings were not losses. amount is a persuasive field, not only a hidden mediator. No decision owner is named, so G1 can pass only on a proposed owner. Changes to the policy wording reach no one who maintains the server, a rule gap referred to underwriting. And free text in the invoice memo can carry planted instructions, a rival meaning closed by quarantining free text.
Design and test. The redesigned server (v1) has six read-only tools and no write tools. Each control closes named losses: the policy terms are fetched by the date of loss; the flood aggregate is computed in the server across all claims in the policy year, counting pending and excluding cancelled payments, and shows its working; the reserve is labelled as an estimate, not a payment limit; the invoice returns gross, VAT and net; and a read-only authority check names the approver. Acceptance test EV-CLM-PAY-001 fixes every input and the as-of time, uses the derivation above as its oracle, and has ten assertions, each guarding named losses. G2, the design gate, is blocked under the current rule: at tier 3 every tool not shown by test to be read-only needs safety analysis, and without recorded runs no tool has been shown to be read-only.
The release gate refuses. G3 does not pass, and correctly so. The only runs are illustrative, the oracle has not been independently reviewed, as tier 3 requires, and only one of six tools has a capability record. The framework will not certify a network on illustrative evidence.
Upkeep. Four disturbances are planned for. At renewal, the excess changes from per claim to per event, a rule change that reopens the fidelity specification, tool specification, acceptance test and capability records. Finance connects a second server whose get_payments tool competes with the flood aggregate. An invoice PDF carries planted text claiming approval. A new tool described as a read places a hold on the payment run.
5.2 Northgate: a short contrast
Northgate Supplies, a fictional distributor, is asked at 15:40 on a Wednesday whether it can promise 300 cases of a product by Friday (described in full in the authors' working paper on Network Fidelity Engineering, section 7). Stock is held in packs, pooled across two warehouses in the enterprise resource planning (ERP) system, and taken from a 06:00 snapshot; it reaches the model as available_qty. Two illustrative runs answer "yes", one from 8,400 and one from 420. The faithful answer is 150 cases on Friday from Leeds and 150 on Monday from Bristol, with the logistics manager's approval and the customer's agreement. The contrast with Harbourline is the tier and the shape of the answer: a tier 2 customer commitment rather than a tier 3 payment, and a split recommendation rather than a reduced amount. The kind of hidden mediator is the same: a stock view whose field name suggests "available to promise" but whose value means "on hand minus allocated, all warehouses, in packs, at 06:00".
5.3 Citigroup: analysis only
On 2 May 2022, a bank holiday in the UK, a trader at Citigroup Global Markets in London set out to sell a basket of equities worth US$58m. The case is analysed from the Financial Conduct Authority's Final Notice of 17 May 2024, steps A1 to A5 only; paragraph numbers refer to the notice. There is no AI agent in this network, so the case also tests whether the framework works when the last reader is a person.
The key value is "58,000,000", followed from the trader's intention to the market. The mediation map located both hidden mediators that explain the incident. The trader entered the value in the field for the number of units, not the total in dollars, so the system built a basket of 349 orders worth US$444bn (para 4.26). The field the trader checked for the basket's value, ValAtBM, fell back on a default price of −1 when a price feed was unavailable, and displayed −58,000,000, "which was the number they expected to see" (para 4.27). Other fields on the screen showed the true value; the trader checked only this one. A warning pop-up listed 711 messages, of which 18 were visible without scrolling (paras 4.15, 4.28). The map also separated the hops where meaning was lost from the one where it arrived intact: a final confirmation showed about US$196bn, and the trader confirmed it (para 4.32).
The analysis produced three losses and five further findings, all referred to owners: a missing basket-level hard limit, a per-order limit set too high to be effective (para 5.6), a price control left at 15% since 2020 without review (para 4.20), the faithful US$196bn figure that was not acted on, and monitoring handed on a holiday to a desk that did not watch these alerts. Each loss was given a mode, a dimension and an effect, so G1 passes on proposed owners, and the analysis pack is the product. No design follows, which is the right ending: every finding belongs to a control owner, not to a tool. About US$1.4bn of shares was sold before the orders were cancelled (para 4.38).
The case forced four changes to the specification: the remit may be "none" when no automated actor acts; two new finding kinds, control design for a control that exists but does not work, and response for a faithful value that is not acted on; and a channel attribute for how much of a message is visible without action.