A hedged sentence in a supplier's email becomes a delivery commitment nobody made. Following it through the stages that should stop it: interpretation, typed candidate, deterministic assessment, human confirmation and authority, the owner's durable record, and the state other agents read.
Mostly design: the stages are taken from Tinor's design records and named as they are named there. The supplier case and the ten admission cases are fictional. The table near the end separates behaviour exercised by Tinor's automated tests (re-run for this revision) from behaviour that is design only.
The email arrives on 12 October from the sales director of Northfield Components, a fictional supplier, to its customer Buyer B:
"We should be able to ship the 20,000 housings by end of November, assuming the resin arrives on time."
Buyer B's assistant reads it and records:
{ "commitment": { "debtor": "Northfield Components", "creditor": "Buyer B",
"object": "20,000 HX-40 housings", "due": "2026-11-30" } }
The extraction is not wrong in any obvious way. The parties, the quantity and the date are all in the sentence. But "should be able to" and "assuming the resin arrives" are gone, and with them the difference between an expectation and a promise. If this record enters shared state as a commitment, Buyer B's planner schedules a production line against it, and in December someone discovers that Northfield never committed to anything.
A model's output can be useful, accurate and still not a fact anyone has taken responsibility for. The rest of this essay follows the sentence through the stages that should stop it, using the names Tinor's design records use for them.
Six stages, each with one job
1. Interpretation. A model reads the material and proposes what it might mean. It may extract, summarise and explain, and it can produce fluent statements its inputs do not support (Ji et al., 2023). In Tinor's design it may not decide identity, authority or admission, and its confidence does not raise the authority of what it proposes.
2. Typed Candidate. The proposal is expressed against a pinned target contract — here, an agreement change set with debtor, creditor, object and due date — with every field pointing to the text it came from. A candidate is explicitly not a fact.
3. Assessment. Deterministic checks decide whether the candidate may be admitted, and on what terms. Among the questions they answer: does it fit the contract; is the cited text really in the material on record; does the source support a proposition this strong; is each party bound to exactly one organisation; is there enough evidence; is the submitter entitled to make it; does it conflict with something already recorded. A failed or unanswerable check produces a reason a person can act on, not only a rejection.
For the email, the quoted words are there and both companies resolve to exactly one organisation. The question of strength fails: the source supports "Northfield's sales director expects to ship by end of November, conditional on resin delivery", not "Northfield commits to deliver by 30 November".
4. Human Confirmation and authority. These are two different things, and the design keeps them apart. Human Confirmation is a person approving the current draft as an operational step. It is not a source of authority, and it does not make the content more true. Authority is whether the party making a statement is entitled to make it — for an agreement, whether every party the change binds has confirmed it. A buyer's employee clicking "approve" on the record above would not turn Northfield's hedge into Northfield's commitment.
5. Owner Commit / Durable Record. Only the service that owns a kind of record writes it, and only what survived assessment. What it writes depends on the type of fact and the path by which it was admitted: a claim, an attestation or an agreement change becomes an Atomic Event on the history of the object it is about; descriptive data about a subject, such as a supplier's profile, is updated as governed profile data; other kinds of record have their own governed stores. Here the result is an evidence-only note recording what the email says, with its condition, attributed to the sales director and derived from the email it quotes — attribution and derivation in the sense of PROV-O. No commitment is written.
6. Read: the resolved state. When another agent asks what Northfield has committed to, it gets the state resolved from admitted events for that subject, time and viewer: no delivery commitment for November; an expectation from the sales director, conditional on resin delivery, dated 12 October. Pending candidates are never served as facts.
What happens when the promise is real
A week later the sales director writes again: "We offer 20,000 HX-40 housings, delivery by 30 November 2026, USD 1.85 per unit, valid until 31 October." This sentence does support a commitment, and its author can make one for Northfield.
It still does not become shared state on arrival. An agreement is shared by both parties, so the change set needs confirmation from every party it binds — Northfield and Buyer B — on that exact change set. Who must confirm follows from what the change binds, not from whom the proposer chose to ask. Until Buyer B confirms, the outcome is hold. When the goods later arrive, Northfield's "delivered" is Northfield's claim; acceptance is Buyer B's (Proof Is Not Truth takes that step apart).
Ten cases, ten different stopping points
The two emails are cases a05 and a06 in a published set of ten admission cases. Each has a different reason for its outcome, and each reason has a different remedy.
| Case | Candidate | Expected | Reason |
|---|---|---|---|
| a01 | lead time bound to the wrong "Northfield" | hold | two organisations match — ask which |
| a02 | test result quoted from a report on another grade | refuse | the quoted text is not in the cited report |
| a03 | "46,000 units/month" written into a capacity field | hold | a rate with no stated period — ask which month |
| a04 | firm delivery promise from an account that cannot commit | refuse | the sender is not entitled to commit the company |
| a05 | the hedged email above | admit, qualified | the source supports only a conditional expectation — evidence-only note |
| a06 | the firm offer, buyer not yet confirmed | hold | required confirmations missing |
| a07 | supplier's honest transcription of a lab report | admit | as the supplier's transcription |
| a08 | supplier marks the same report "attested by the lab" | refuse | assurance claimed for another party |
| a09 | the lab records its own report | admit | independent issuer |
| a10 | an integration adds "verified": true to a record |
refuse | a field the contract does not declare |
The case file gives each reason a short code of its own; those codes are labels for the benchmark, not Tinor's internal vocabulary. Collapsing these ten into "accepted" or "rejected" would discard exactly what a reviewer needs to fix them.
What is tested and what is design
| Behaviour | Status |
|---|---|
| A commit capability without authority to act for the company does not let an account write a claim on the company's behalf (a04). | Tested |
| Undeclared payload fields, wrong types and missing required fields are refused (a10). | Tested |
| A party cannot claim another party's attestation; a same-account "independent" assessor is refused; an independent issuer is admitted; an honest transcription is admitted as a transcription (a07–a09). | Tested |
| Required confirmers are derived from the change and cannot be reduced by the proposer; a confirmation targets one exact change set (a06). | Tested |
| A monthly amount without an explicit interval is not accepted into a measurement field (a03). | Tested |
| Same name never means same entity; the user is asked to choose (a01). | Covered by a database integration test, not re-run for this revision |
| Grounding against material on record (a02); semantic strength (a05); the assessment as a whole; the model being unable to decide admission; the choice of durable record by fact type. | Design |
"Tested" means Tinor's own automated tests exercise the behaviour; they were re-run for this revision and passed. It does not mean the behaviour has been measured on real traffic or verified by anyone outside Tinor.
Limits
- Strength is hard to calibrate. Deciding which propositions a given sentence supports needs domain rules that someone must write and maintain. Hedges are easy; "we typically ship within six weeks" is not.
- Upstream errors still matter. If the source is a scanned PDF, grounding is only as good as the text the scan produced.
- This is overhead where nothing binds. For notes, research and drafts, a model's interpretation is fine as it is.
- Admitted is not true. An admitted record says who stated what, on what basis, under which rule. The statement can still be wrong.
Agent Memory Is Not Operational State discusses when this machinery is worth having. Reality Needs a Type System looks at the contracts the candidate is compiled against, and Toward Zero Invalid State Admissions at how to measure whether a system gets cases like these right.
References
- Ji, Z. et al. (2023). Survey of Hallucination in Natural Language Generation. ACM Computing Surveys 55(12). arXiv:2202.03629
- W3C (2013). PROV-O: The PROV Ontology. w3.org/TR/prov-o
Originally published at tinor.io.
Top comments (0)