Assurance Contract — เขียนสัญญาเป็นรายคุณสมบัติThe Assurance Contract — Stop Saying "Safe and Trustworthy"; Commit Per Property

🤔 If a vendor puts a one-page attestation on your desk saying that this system is "safe and trustworthy", what evidence would you use to audit that sentence?

The previous post, When Is AI the Core?, ended at the classification: we now know which pieces of work are genuinely AI-core, how much authority the model holds, and whether the work collapses when the model is removed — and we have tied everything that determines behaviour — model, decoding, context, retrieval, tools, memory, orchestration, environment — into a single manifest. The next question is the one the risk committee always asks, and the one engineering teams most often answer the wrong way: so what can we actually guarantee?

The short answer for the whole post is this: stop answering with adjectives, and answer with an assurance contract written one property at a time — each row stating its assumptions, the obligation the system must meet, whether the claim is a guarantee or only an estimate, the evidence, the owner, the threshold, the rule that governs change, and the response on breach — and not one row anywhere saying "the whole system is safe".

1. "Safe and Trustworthy" Is Not a Contract

Chapter 8 of AI Transformation as an Organizational Core opens with a single sentence that is both a definition and the condition for everything that follows: "Assurance converts confidence into accountable testable obligations and makes failure routing part of the design."^[1] — assurance turns confidence into obligations that can be tested and assigned to a named person, and it makes the route a failure takes a designed thing rather than something improvised on the day it happens.

Notice that the sentence contains no word "safe" at all, and that is deliberate. The book writes the rule out plainly in the paragraph that follows:

An assurance contract states, for each property, the assumptions, obligation, guarantee or estimate, evidence, owner, threshold, and response to change or breach. It should never claim that the whole AI system is safe. It should say narrowly what can be enforced, what can only be estimated, and what residual risk remains.^[1]

I want the word narrowly read carefully, because it is not rhetorical modesty — it is an engineering requirement. A sentence that reaches wider than its evidence can cover fails and passes an audit at the same time: it has no falsifiable state for a reviewer to hold on to. On the day something actually goes wrong, that sentence helps nobody — not the engineering team that has to say what broke, not the legal team that has to say who is liable, and not the executive who has to decide whether the system stops.

Three questions that audit a marketing claim on the spot

When an attestation lands on the table I ask these three in order, and they come straight out of the book's own sentence.

• What is enforced — which properties does the structure of the system make impossible to violate, not merely hard to violate, and what condition has to hold for that enforcement to be real?
• What is only an estimate — which properties can be measured only by a classifier or an automated evaluator, on which population, at what threshold, and with how many false accepts and false rejects?
• What residual risk remains — what do the first two not cover, who accepts that risk on behalf of the organisation, and until what date do they accept it?

An attestation that cannot answer these three does not mean the system is bad. It means we do not yet have a contract — we have the feelings of whoever wrote the document, and feelings cannot be audited, cannot be handed over, and disappear with the author on the day they resign.

Envelope and contract are not the same thing

These two words are confused often enough that I separate them at the start. The assurance envelope is the set of mechanisms that actually surrounds the AI system — the filters, the authorisation checks, the structure validators, the trace store and the failure routes. The assurance contract is the document that declares what those mechanisms give us, under which assumptions, and what happens when the contract is broken.

The envelope is what runs in production; the contract is what the committee reads. Both have to exist together: an envelope with no contract is a set of controls nobody knows the promises of, and a contract with no envelope is paper. This post (#12) is about the paper; the next one (#13) is about the mechanism, and I split them deliberately, because in real organisations the two are usually built by different teams and never laid side by side.

💡 My view: the first of this chapter's five operating principles is "State claims property by property — separate guarantees, estimates and governance duties."^[1] I treat this as the most expensive one to ignore, because a single word that sweeps every property together drags three things of completely different natures into one sentence — what can be enforced, what can be estimated, and what can only be recovered afterwards — and then the reader believes all three are equally strong.

2. The Three Control Classes That Must Never Be Blurred

Before a contract can be written, you have to separate the kinds of mechanism you actually hold, and what each one really provides. The book separates three, and insists: "Keep three control classes distinct" — genuinely distinct, not merely listed on the same slide.

The sentence in the bottom-right cell is very short and I think it is the most valuable one in the whole table. The book's wording is that governance "creates accountability and recovery, but cannot make an individual answer correct"^[1]. A great many organisations answer the question of AI quality with governance structure — appoint a committee, issue a policy, write a manual, name an approver — and believe the work is done. But no committee anywhere in the world makes the refund-eligibility explanation the system gives the next customer on a Tuesday afternoon correct. What a committee can do is make us notice faster when it is wrong, and let us reverse it when it is wrong.

Why hard enforcement is the layer that has to be laid first

Because it is the only layer that supports the word "guarantee" in the real sense of the word, and the book states its condition without hedging: effect mediation holds only when no path can bypass the mediator. In practice that means that if the system has any shortcut at all — a migration script that writes to the database directly, an internal endpoint exempt from the authorisation check, a button on an admin page that calls a tool without passing the guard — the word "guarantee" in that contract row is void immediately. Not "weakened": void, because the assumption holding it up is no longer true.

What follows from that is proposal–effect separation, which the book compresses into one sentence: "The model proposes; an external guard authorizes; a transactional tool creates the effect."^[1] The mechanism of that dividing line is the subject of the next post, but its consequence for the contract belongs here: properties that sit behind the line can be written as structural, while properties in front of the line can be written, at best, as semantic.

3. Structural Guarantee versus Semantic Estimate

Once the control layers are separated, the claim types you can write into a contract come down to two, and the book is precise about both.

A structural guarantee is a property enforced by deterministic architecture — authorization, accept-lists, data formats, hard limits, sandboxes or transaction rules.^[1] A semantic estimate is a probabilistic verdict — correctness, relevance, policy alignment, or attack detection — which has to be measured and must never be called a guarantee.

The second definition carries its own prohibition inside it, and that is the whole point of this section.

The example the book uses, and why it is sharp

The book carries one use case through the whole volume, CX-REFUND-01 (a fictional case from the playbook), a customer-refund task, and writes its contract as two sentences deliberately placed side by side:

For CX-REFUND-01, the contract can structurally guarantee that a refund routed through the execution guard will not exceed 2,000 baht or execute without an authenticated approval token. It cannot guarantee that every eligibility explanation is correct. Faithfulness must be measured on labeled policy cases, and evaluator error reported at the operating threshold. If the model proposes 2,500 baht, the guard rejects and creates an escalation trace even if the explanation sounds plausible.^[1]

These sentences sit in one paragraph because they are properties of the same system in the same interaction. The system promises that the money will not exceed 2,000 baht, but it does not promise that the reason given to the customer is right — and the last clause, "even if the explanation sounds plausible", is the heart of it, because it says the guard must ignore the quality of the explanation entirely. Plausible language is not evidence of authority to act. The figures 2,000 and 2,500 in this paragraph are fictional values inside the book's worked example, not thresholds recommended to any organisation.

The evidence that actually separates the two

The question worth asking next is how we know this difference between claim types is real in practice, rather than a tidy-sounding taxonomy. The book draws on the r8 paper, the author's own unpublished document, which carries a deliberately bounded specimen — 517 deterministic executions the author constructed himself.^[2]

In the fixed suite, a system running the full envelope completed 30 of 30 benign cases, allowed zero of 40 policy escapes, allowed zero of six prohibited refund effects, and recorded 70 of 70 route traces.^[2] That set of numbers reads comfortably, which is exactly why the next set has to be read immediately after it.

Switch to adaptive evaluation — attacks adapted to the actual implementation rather than a fixed test set — and the whole picture changes: violating candidates were released eight of twelve times — soft control missed two-thirds of the cases — while hard execution mediation blocked prohibited effects in all four attempts.^[2] A base of only four is very small, so it illustrates a mechanism rather than any population's safety rate.

The pair eight-of-twelve and four-of-four is the entire reason a contract has to keep the two claim types apart. Under the same pressure, in the same system, the layer that estimates meaning leaked and the layer that enforces structure did not. If we write the contract as the single sentence "the system prevents policy violations", we get a document that is partly true and partly false at the same time, with no way to tell which part is which.

A fixed threshold does not make a fallible score true

The sentence printed under the contract table in the book's Artifact 2 is the one I want everybody who is about to set a pass/fail threshold to read first: "A fixed threshold does not make a fallible score true." — the same instruction is printed in the Thai edition of the book.^[1]

The point is not that you should avoid thresholds — you must set them, and set them in advance. The point is that setting a number does not change the epistemic status of the score. A score that scraped over the line is still an estimate that is wrong at the same rate it was before. Declaring the threshold changes only what we do with the score; it does not change what the score is.

The international guidance that addresses this at the process level moves in the same direction. NIST AI 600-1, the Generative AI Profile of the AI Risk Management Framework, was published in July 2024 and, as verified on 5 September 2026, is still the current version — a voluntary companion document whose suggested actions an organisation must select and tailor to its own use case and risk tolerance.^[3] In that document, establishing minimum thresholds for performance or assurance and reviewing them as part of the go/no-go approval policy is one suggested action, and measuring false positives and false negatives is another — the two are placed as activities to be done together, not as alternatives.

NIST also writes the limits of measurement out plainly: "Measurement gaps can arise from mismatches between laboratory and real-world settings", noting that current testing approaches often remain confined to benchmarks and laboratory conditions that may not extrapolate to real-world settings.^[3] This is why a semantic row in the contract must always name the population it was measured on: the claim can be no stronger than the resemblance between that population and the real work.

4. The Eight Elements of a Single Contract Row

Now to the actual structure. The book states that every property needs eight cells, and I will stress that "every property" is meant literally — the contract does not have eight cells, it has eight cells per row. If you have seven rows, you have fifty-six cells to fill, and a row that is not filled completely is a row with no contract in it.

The weakest cell is almost always the obligation

I have seen it often enough to state it as an observation: the cell teams write worst is not the threshold and not the evidence — it is the obligation, because it looks like the cell where "anything can go". The book's definition closes that gap by embedding three tests inside the definition itself: the obligation must be written precisely enough to (a) assign an owner, (b) gather evidence, and (c) decide pass or breach.

Compare two sentences. How many tests does "the system must respond responsibly" pass — assigned to whom, evidence of what, decided how as of today? Against: "every answer that asserts a policy condition must cite a passage from the retained policy document, and any answer that cannot cite one must be withheld before release." The second can be assigned (the policy owner), evidenced (the share of answers carrying a citation, and the cited passages themselves) and decided (pass/fail per answer). It is twice as long, and its auditability has gone from zero to something.

The chapter's other four operating principles

The first is already in the 💡 box in section 1. The remaining four of Chapter 8 are here, and each one translates neatly into a cell in the table above.^[1]

• Put hard controls at release and effect boundaries — complete mediation is a prerequisite (the assumptions cell of every structural row)
• Calibrate semantic gates — report threshold, population, false accepts, false rejects and correlated failure (the evidence and threshold cells of every semantic row)
• Inspect state and traces — model narration is not evidence that an effect occurred correctly (the evidence cell — evidence is the real state, not the text the system printed)
• Test beyond the visible suite — combine fixed, hidden, adaptive, stateful, failure and live evidence (the reason the fixed-suite numbers in section 3 are not yet enough)

The third of those is short but carries a great deal. "Model narration is not evidence that an effect occurred correctly" means that if the system writes "the refund has been processed", that text has the status of model output, not of evidence that money left an account. The evidence is the state in the transactional system plus the trace proving the transaction passed the guard — the two are always different things, and in a system with a problem they differ in the direction that causes damage.

5. Artifact 2 — The Ready-to-Use Seven-Row Contract

Appendix B of the book carries a worksheet called AI-core assurance contract that can be copied and used as it stands, and it answers "how many rows should there be" with a very specific number: seven. The book states its purpose, its use condition and its owner as follows.^[1]

Purpose Replace "safe and trustworthy" with property-specific commitments covering assumptions, obligation, claim, evidence, owner, threshold, change, and breach. Use when approving an AI-core release, provider, service boundary, or residual risk. Accountable owner Release owner maintains the integrated contract; each row has one answerable property owner.

The last sentence is the one usually skipped: the release owner maintains the integrated contract but does not own every row. Each row has one owner who can answer for that row. If an organisation writes the same name into all seven rows, that is not clarity — it is a bottleneck about to become a point of failure.

The worksheet: seven rows and what each cell must state

Under this table the book writes two sentences that must always be read together, because they are the filling rule for the two kinds of row: "For semantic rows, state population, threshold, false accepts, false rejects and weak slices. A fixed threshold does not make a fallible score true. For structural rows, state mediation, validator, identity, bypass and logging assumptions."^[1]

"Weak slices" is the phrase I would underline. The headline number for a semantic gate usually looks good, because easy cases make up most of the volume — but the cases that cause real damage usually sit in the slices with the fewest examples: mixed languages, stacked policies, customers with complicated histories. A contract written only in averages is a contract that guarantees precisely the cases that needed no guarantee.

The completed example: CX-REFUND-01

The book fills all seven rows for the CX-REFUND-01 case (a fictional case from the playbook). Every number and every role name in the table that follows is a fictional value inside the worked example — not a recommended threshold, not a measured result, and not something any organisation should copy as a target. What is worth copying is the shape of the sentence.

Read all seven rows in sequence and you see what I think is the most important property of this kind of document: not one row talks about the whole system. Every sentence addresses one property, in one scope, with one kind of evidence, and one person accountable. A document assembled out of seven sentences like these is incomparably more useful than a thirty-page one that ends in the words "safe and trustworthy".

6. No Control Layer Covers Everything

Chapter 8 places mechanisms at five points along the seams of the system — the five rails are input, dialog, retrieval, execution and output, with trace retention spanning all of them. The mechanism of each rail is the next post's material, but what belongs to this post is the sentence the book writes immediately after introducing them: "No rail covers everything." — followed by four very specific examples.^[1]

What I like about laying the gaps out this way is that it turns them from "a limitation everybody knows and nobody writes down" into text in a document with an owner. Residual risk that has been written down is risk somebody has accepted; residual risk that has not been written down is the thing that becomes an argument about responsibility on the day of the incident.

💡 My view: the third gap is the most dangerous, because it does not look like a failure. A tool call that is "authorized but against intent" passes every gate green, raises no alert and leaves no anomalous log, and it is discovered only when somebody looks at the real state and asks why it is like this. That is exactly why the chapter's fourth operating principle insists on inspecting state rather than inspecting narration.

A row I add myself: personal data

One closing observation for this section: NIST AI 600-1, ISO/IEC 42005:2025 and the book's contract structure are three different kinds of document doing three different jobs — the first is a voluntary set of suggested actions for generative-AI risk, the second is guidance on impact assessment, and the contract structure is the author's synthesis from the r8 paper, not a standard. The three are not equivalent and do not map onto one another as a one-to-one table. I use the first two only as inputs to the evidence cell and the residual-risk cell.

7. The Metrics That Matter, and the Failure Patterns

A contract with no metrics is a contract you can only audit after something has happened. The book gives eleven metrics along with one very firm prohibition. The table below follows the book's order, and the Scorecard column maps them onto the six-column organisational scorecard from Chapter 1 — that mapping is mine; the book attaches no Scorecard column to this metrics list.

The prohibition I mentioned is the sentence that closes the list: "Never collapse utility and security into one score."^[1] The reason is straightforward: a blended score lets a system that got faster and less safe keep the same number, and the committee has no way of knowing what was bought with what this month. The book's six-column scorecard exists for exactly the same reason — read the columns together, never fold them into one score.

On the governance side, NIST AI 600-1 sets out two activities that translate directly into governance rows: establishing and maintaining procedures for escalating generative-AI incidents to the organisational risk authority when criteria for deactivation are met, and establishing and regularly reviewing the specific criteria that warrant deactivating a system, in line with the organisation's risk tolerance.^[3] Notice that both speak of criteria set in advance rather than judgement exercised in the moment — which is precisely the eighth cell of the contract.

Failure patterns

The book lists eight. I reproduce all eight in the book's order.^[1]

• Treating a threshold as deterministic truth — handling a fallible score as a fact, simply because a threshold number is attached to it
• Assuming stacked judges are independent — layering several evaluators and multiplying the probabilities as if they never fail together, when they usually fail together for the same reason
• Claiming zero risk after no fixed-suite failures — converting "not found in the set we know about" into "does not exist"
• Placing all protection at output — defending at a single point at the end, when a great many effects occur before anything reaches the end
• Approving narration instead of state — approving because the system says it did the thing, rather than because the real state says it did
• Writing traces after release — recording after the result goes out, which turns every route that failed at release into a route with no evidence
• Suppressing escalation to improve automation — reducing the number of items routed to humans to make the automation figures look better, while the risk does not fall with them
• Granting autonomous irreversible effects because semantic scores are high — using a semantic score as the justification for letting irreversible effects happen automatically

And in the practice of contract-writing itself, I would add four more that I see often when reviewing documents — these four are my own grouping, not the book's list.

• Adjectives instead of properties — "accurate", "transparent", "responsible" are not properties that can be decided pass or fail. Test them by asking what evidence you would gather
• One threshold for every slice — a single bar for easy cases and hard ones, which buries the slices that most needed a guarantee under the average
• Calling an estimate a guarantee — writing "the system prevents injection" when the actual mechanism is a detector with false accepts
• Rows with no owner — an empty owner cell, "the relevant teams", or the same name in every row; all three produce the same result, which is nobody able to answer on the day

Notice that the book's eight are failures of the system, while my four are failures of the document. Both sets end in the same place: the day something happens and nobody can say which of the things we once promised is still true.

8. The Road Ahead

If the whole chapter had to be reduced to one change in the way we work, I would choose this: change the question in the approval room from "is this system safe enough yet?" to "what enforces this property, on which population was it measured, who owns it, and what happens if it is breached?" The first question produces an answer everybody nods at before leaving the room with different understandings. The second produces a document that people who were not in the room read and understand the same way.

Three things can be done next week. One: take one attestation for an AI system about to be released and underline every sentence that has an adjective but no population, no threshold and no owner. Two: open the seven-row table in section 5 and fill in exactly one row completely — the effects row, because it is the fastest way to find out whether complete mediation in your system is real. Three: log the four residual risks in section 6 with the name of whoever accepts each one and a review date — and if nobody will sign for a single one of them, that is the most valuable information you will get out of that week.

What this chapter does not answer is where in the system those structural constraints should sit. The contract says what has to be guaranteed, but not which point on the path of a request makes that guarantee real — and that requires actual mechanism, not a document.