FIELD NOTE / INSTAGRAM
Correct arithmetic can bill the wrong contract.
The complete written thought and the evidence behind it. The video edition will follow its public release.
The written argument is here.
This approved Instagram edition is on the journal now. Its video player and original platform link will appear after each public release is verified.
Correct arithmetic can bill the wrong contract.
Video caption
Correct arithmetic can bill the wrong contract.
A source ID is not proof of current authority.
Keep interpretation separate from source and ledger checks.
A typed total is not an authority receipt.
#EricFieldNotes
Full written post / accessibility read
Imagine an agent extracts a discount clause from an account agreement and returns a valid typed record. The billing service does the arithmetic correctly. Yet a signed amendment replaced that clause last month. The invoice can be wrong even though the JSON and the math are flawless.
The model can cite agreement version one while the customer now operates under version two. A parser checks the citation's shape; it does not verify that the cited clause governs this account and period. TypeSafe also recommends doing arithmetic and date comparisons in code, but code cannot repair a stale source selection by itself.
Let the model identify the disputed clause as a proposal. The host fetches the signed current amendment from a protected store, verifies customer and billing-period scope, then computes the total from versioned ledger inputs. At invoice issue, compare the source version and reconciled amount again.
Record the signed clause version, account scope, formula inputs and reconciled ledger total. Do this because format control can guarantee a usable record, but only current source authority and deterministic calculation can justify what the customer owes.
#EricFieldNotes
Four-beat scene transcript
1. Correct arithmetic can bill the wrong contract.
Imagine an agent extracts a discount clause from an account agreement and returns a valid typed record. The billing service does the arithmetic correctly. Yet a signed amendment replaced that clause last month. The invoice can be wrong even though the JSON and the math are flawless.
Visual: The calculation is only as sound as its source.
2. The dangerous field is the citation.
The model can cite agreement version one while the customer now operates under version two. A parser checks the citation's shape; it does not verify that the cited clause governs this account and period. TypeSafe also recommends doing arithmetic and date comparisons in code, but code cannot repair a stale source selection by itself.
Visual: A source ID is not proof of current authority.
3. Resolve authority before calculating.
Let the model identify the disputed clause as a proposal. The host fetches the signed current amendment from a protected store, verifies customer and billing-period scope, then computes the total from versioned ledger inputs. At invoice issue, compare the source version and reconciled amount again.
Visual: Keep interpretation separate from source and ledger checks.
4. Make the whole bill reproducible.
Record the signed clause version, account scope, formula inputs and reconciled ledger total. Do this because format control can guarantee a usable record, but only current source authority and deterministic calculation can justify what the customer owes.
Visual: A typed total is not an authority receipt.
Research and claim limits
The examples identified as illustrative or simulated are design probes, not reported incidents. Vendor specifications do not establish workload performance.