Ship It — คันเร่งอิสระ งานปฏิบัติการ และเช็กลิสต์ก่อนปล่อยShip It — The Autonomy Slider, Operations, and the Checklist

🤔 Your system passed every suite from the previous post — so who presses the release button, on what evidence, and if it refunds the wrong order tomorrow morning, who gets woken up?

The previous post, Prove It, ended with a harness that answers the four validation questions — the system routes as specified, attacks written after reading the rules get through the soft layer but not the execution rail, and stateful failures fail closed. But evidence is not a decision. This final post is about what remains: how much autonomy the system should be granted, who looks after it after launch day, and how we know that "ready" is a finding rather than a feeling.

This post's answer has three layers. First, set the autonomy level with the autonomy slider per kind of effect, not per app — and leave the autonomous-times-irreversible cell empty forever. Second, build operations on the five deployment realities the paper states plainly, from the latency the envelope charges to the residual attack rate that never reaches zero. Third, walk the paper's ten-item practitioner checklist, where every item must be answered with an artifact rather than an adjective — and because we have walked nine posts together, every row of that checklist already has its artifact waiting. That is what zero-to-hero actually means: on launch day nothing new has to be built, only pointed at.

1. The Autonomy Slider — Speed from the Model, Control from the Loop

This section's conclusion fits in two sentences: the autonomy level is not a single setting for the whole system but a value set separately per kind of action, governed by one principle — verification effort must grow with decision authority and with the irreversibility of the effect — and the cell where the highest authority meets an irreversible effect is the one the paper marks not advised, no matter how heavy the verification.^[1]

The paper's Section 9 frames everything as one loop: the AI generates, the gates filter, a human verifies the residue, and the golden set grows on every pass — a generation–verification loop in which the model's capability and the envelope's machinery divide the work cleanly. The paper compresses that division into a sentence I think belongs on the team-room wall:

Speed from the model; evidence and control from the loop.^[1] — Neither half substitutes for the other.

The four positions of the slider

The paper orders autonomy in four steps, from most human-dependent to least.^[1]

• Suggest — the system proposes options or points at things; the human does everything. Every effect comes from a human hand.
• Draft — the system produces complete work; the human reviews, edits, and presses send. The work is accelerated, but release remains a human decision.
• Act with approval — the system prepares a real action all the way to ready, then stops for per-item approval. The human sees the action before the effect exists, not after.
• Autonomous — the system carries the task to completion with no human in the path — which the paper qualifies in the same breath: for low-stakes work only.

The figure above is drawn from the paper's Fig. 2, and I have to annotate it exactly the way the paper annotates itself: this is an illustrative heuristic. The bands are ordinal, not a calibrated scale, and the figure deliberately implies nothing about how many controls each cell requires. It intends to carry exactly two claims. First, verification effort grows monotonically along both axes at once — the system's decision authority, and the irreversibility of the effect the system produces through its own mediated path. Second, the autonomous-times-irreversible cell is marked not advised — no amount of verification substitutes for a human decision on an irreversible external effect.^[1] The figure works as a compass; it does not work as a calculator.

A real deployment must replace the compass with a model: the paper says to estimate expected harm = likelihood × consequence, adjusted by two factors — detectability, how quickly we would notice a miss, and recoverability, how much of a miss can be undone.^[1] The same reasoning anchors NIST's AI RMF: risk as likelihood times magnitude, and risk acceptance as a declared decision, never a default.^[2]

Three consequence classes — and why settings are made per action class

Why must the risk budget, sampling rate and review set be set per action class rather than as one global value? Because a detector's error is a property of the distribution it runs on, not a universal number belonging to the detector. The same classifier misses at different rates on policy questions and on refund requests — and even if the rates happened to be equal, equal rates would not imply equal acceptability: one wrong policy answer in a hundred and one wrong refund in a hundred are different risks in different worlds.^[1] Each class's budget line therefore carries its own threshold, its own sampling, and its own reviewer — which is exactly what Step 3 writes down as a real file.

2. Deployment Realities — and the Eight Recurring Failures

Conclusion first: the envelope is not free — it charges latency on every request. What can be economized is the semantic-evaluation layer; what must never be economized is the structural layer. Golden sets must be re-run every time the model moves. "Auditable" means traceable, not safe. And injection defences always leave a non-zero residual attack rate. These are the price tags the paper attaches in advance, in Section 10.^[1]

Five realities to accept before launch day

• The envelope charges latency — one request's path crosses five rails plus one judge call. A fully enveloped system will always be slower than a bare one. Measure and declare that price; never quietly strip a guard to chase a number.
• The soft layer can be economized; the hard layer cannot — semantic evaluation may be sampled or tiered by risk, but structural validation and the hard enforcement of effects stay on every applicable call. There is no exception for speed.
• Golden sets re-run on every model change — a hosted model shifts behaviour under our feet silently (non-stationarity). A golden set that was green last month says nothing about the version running today.
• Auditable means traceable, not safe — a complete decision trace lets us reconstruct every route after the fact, but it does not make any route correct. A perfectly auditable system can release wrong answers every day.
• Injection defence always leaves a residual — prompt injection is a risk that can be pressed down but not eliminated. The honest number for any defence stack is a non-zero residual attack success rate, which is exactly what both the paper and the industry's standard risk list concede.^[5]

The four-layer stack a system needs in full

The paper draws the deployed whole as four stacked layers: the data foundation at the bottom, then the AI-OS core (models, context, memory, and RAG), then the agentic applications, closed at the top by the human-in-the-loop — with guardrails cross-cutting every layer and gates governing every change.^[1] The shape is not new in reliability engineering — it is the same lineage as Sha's Simplex architecture, where a simple, verifiable component bounds the damage a complex, unverifiable component can do.^[4] What has changed is that our complex component is a language model, and the paper prices skipping any layer in a sentence that leaves no room to argue:

Skip the data foundation and the core starves; skip the guardrails and it is unsafe; skip the gates and you are flying blind.^[1] — Each clause names a different bankruptcy: an underfed core, an unbounded one, and one whose changes nobody can see.

The eight failures — what each looks like when it happens to a real team

Bolted-on chatbot — the paper calls this "one application, mistaken for a computer". A team staples a chat window onto the old system with no data foundation under it. The demo looks great because none of the demo questions touch real data — and in the first week after launch, half the customers' questions need order state the chat cannot see. What the organisation gets is a system that answers brilliantly on the topics nobody asks about.

Vibes-based shipping — shipping because "we tried it and it felt good" on five prompts the demo-giver chose. No fixed suite, no baseline. The day an executive asks whether this build is better than the last one, the honest answer is that nobody knows — and, working this way, nobody ever will.

Trusting fluency — a well-written answer passes review more easily than a correct one, so the team drifts, without noticing, into reviewing prose instead of facts. But the first core assumption we set down back in post #5 is that the core's errors are fluent — confident, well-formed, and wrong. Convincing language is evidence of nothing except linguistic competence.

Ungrounded generation — answers not bound to any passage actually retrieved. One day the unguarded system will explain a return policy that exists in no document the shop ever wrote, and explain it confidently enough for the customer to remember and quote back. Span-level attribution at rail five exists precisely to prevent this.

Unbounded autonomy — the confused-deputy route in full: privilege flows with content, because instructions and data share one channel. The system holds the authority to call refund, and it reads text anyone can write — a single planted passage is enough for that authority to be spent on our behalf. Most teams grow their tools' capability faster than their mediation, and the gap between those two lines is the attacker's workspace.^[5]

Deleting the validating glue — validation code between layers always looks "redundant" once the system has been quiet for three months. Someone refactors it away in good faith, and everything stays green until the model gets a version bump — at which point the breakage surfaces far enough from the deletion that nobody connects the two events. The validating glue is not excess fat; it is the reason the system was quiet.

No golden set — every incident becomes a debate from memory, and no fix can be proven not to regress the last one. Post #9 built this set for you. The later, more painful version of the failure is having the set and letting it stop growing — the correct rule is that every miss found in the field becomes a new case in the set before its ticket closes.

Single-layer safety — betting all safety on one filter, usually at the output because that is easiest to install; then whatever passes that one layer gets everything at once. The leave-one-control-out results from the previous post state this as numbers: remove a single rail and the whole family of challenges that rail used to absorb reaches the system immediately. Defence in depth is not a luxury — it is the only reason one layer's error is not yet the whole system's error.

3. The Seven Steps

The seven steps are the whole launch ceremony — the first four set autonomy and verification, the next two prepare for the day it breaks, and the last is the deciding checklist. Every step ends with the real KramKraft beat.

Step 1 — Set the autonomy level per action class, not per app

Enumerate everything the system can do, group the items into action classes by consequence (using the table in section 1), then set a slider position for each class separately. The reason a single dial per app is forbidden: one app always holds several classes, so one value covering all of them is simultaneously too strict for reads — burning human time on what should flow automatically — and too loose for writes, which is the direction that costs far more. Nong Kram separates into four classes: policy and product answers (read-only over the corpus), order-status checks (read-only over the order store), small refunds under narrow conditions, and refunds outside those conditions.

💡 My view: grant autonomy the way you grant production access — promote one level at a time after a trial period with numbers behind it, and revoke the whole level immediately on an incident, no meeting required. The paper does not prescribe this cadence; it is my own practice. But it makes the slider something earned with evidence and lost with events, rather than a value set once and forgotten.

Step 2 — Scale verification to authority × consequence

For each class, estimate expected harm = likelihood × consequence, adjust for detectability and recoverability, then choose verification density to track the result — not technical difficulty, and not the team's convenience. Use Fig. 2 as a one-direction compass: more verification as authority rises, more again as effects become irreversible, and a hard stop at "no autonomous release" where both axes peak together. For Nong Kram: policy answers get sampled semantic evaluation, while the refund path gets the full stack plus a human in the loop — because the price of one miss is not the same.

Step 3 — Set a residual-risk budget, sampling rate and review set per action class

Write the residual risk down as a file, not as a shared understanding in the team's heads — one line per class stating the acceptable escape budget, the sampling rate, the set a human reviews, and the review cadence. The reason was given at the end of section 1. For Nong Kram the most important line is refund_small.sampling: "100% within 24 hours" — every approved refund is seen by a human in retrospect, always, even if the slider position is promoted later. The full file is in section 4.

Step 4 — Wire golden-set re-runs into every model, corpus and prompt change

Make the gate automatic: whenever any term of the release manifest from post #4 changes — model version, corpus snapshot, prompt-template hash, evaluator version, or a threshold — CI must run the entire golden set and block promotion on regression. This is the mechanical answer to non-stationarity — we cannot stop upstream from changing, but we can make every change visible. For Nong Kram: a single job named golden-gate watches the manifest hash and runs the harness from post #9 — whoever edits the prompt "just slightly" walks through the same gate as whoever swaps the whole model.

Step 5 — Prepare rollback and incident response

Fix three things in writing, in advance, before they are needed at three in the morning.^[3]

• Roll back to what — to the last approved manifest in its entirety, never the model alone, because behaviour belongs to all the terms jointly. Rolling back some terms creates a mixed configuration that has never been tested at all.
• Who gets woken up — real names, real channels, a real contact order. "The relevant teams" is not an answer, because at three in the morning nobody is named that.
• What stops the system — a precisely defined kill switch: close the execution rail to deny-all, and the whole system degrades to advisory mode, fail-closed — some capability disappears, but external effects stop completely and immediately.

Nong Kram's one-page runbook reads: for a refund-level incident, freeze the refund tool first, keep the read-only answers alive for customers, wake the shop owner and the engineer in that order, and roll the manifest back once diagnosis is done — the shop keeps answering questions all night; it just cannot refund on its own until a human is back in the loop.

Step 6 — Audit yourself against the eight characteristic failures

Walk all eight items from section 2 as a document, not as nods in a meeting — for each one, answer three columns: does this happen to us, what evidence supports that answer, and if it does happen, who owns the fix and by when. An item answered "does not happen" with no evidence counts as unanswered. For Nong Kram, the first audit found half of item 7: the golden set exists but is thin on one side — shipping-condition cases are clearly fewer than return-policy cases — producing an action item to add shipping cases before launch. That is what a good audit yields: a specific repair list, not a stamp that says passed.

Step 7 — Run the ten-item practitioner checklist

The paper's last word is a checklist whose one rule is strong enough to change how a whole organisation behaves: every item must be answered with an artifact — a document, a table, a log file that can be handed over — never with an assurance adjective.^[1] The ten items are these.

1. Scope — the task set, the authority measure, and the indispensability ablation, with thresholds declared before evaluation
2. Manifest — model, decoding, context, corpus, tools, policies, evaluators and thresholds pinned together as one release
3. Boundaries — every released payload and every external effect reaches the world through one mediated path
4. Hard controls — identity, authority, schema, parameter, rate, transaction and idempotency checks all outside the model
5. Soft controls — detector false accepts and false rejects measured on the slices actually served, and none of them called a guarantee
6. State oracles — tests judged from authoritative post-state and the released payload, never from the model's narration
7. Adversary — fixed, hidden and adaptive-to-implementation cases kept separate, with the attacker's access and query budget stated
8. Operations — the duplicate, timeout, tool-error, partial-failure, rollback and trace-write paths all fail closed
9. Economics — utility, escapes, unsafe effects, escalation, latency, tokens and cost reported by consequence class
10. Reproduction — per-case records, schemas, a dependency lock, a one-command runner, licence, citation metadata and an immutable archive

KramKraft's completed copy — with links back to the artifacts of all nine preceding posts — is the heart of the next section.

4. The Artifact — Nong Kram's Go-Live Review

The series-closing artifact is a single document, go-live-review.md, in three parts: the autonomy table per action class, the residual-risk budget, and the ten-item checklist with every row pointing at something real. It is the document on the release meeting's table — and the one read again after the first incident.

Part one — the autonomy table per action class

Part two — the residual-risk budget

# residual-risk-budget.yaml — Nong Kram's residual-risk budget
# All numbers are this tutorial's, not the paper's

answer_policy:            # read-only over the corpus
  escape_budget: "at most 2 policy-contradicting answers per 1,000 sampled"
  sampling: "5% of traffic, plus every case a customer complains about"
  review: "weekly, by the shop owner and the engineer"

order_status:             # read-only over the order store
  escape_budget: "cross-customer order data = 0 (enforced by session binding, not by budget)"
  sampling: "1% of traffic"
  review: "monthly"

refund_small:             # up to 1,000 baht, undelivered orders only
  escape_budget: "prohibited transactions released = 0 (enforced at the execution rail)"
  sampling: "100% of approved transactions, reviewed within 24 hours"
  review: "every escalation, plus a weekly summary"

refund_large:             # above 1,000 baht, or outside the conditions
  autonomy: "act-with-approval always — no autonomous path"
  review: "human approval per transaction"

Notice the division of labour inside the file: the two zeroes are not really budget at all — they are structural guarantees carried by the execution rail and by session binding. The genuine budget is the answer_policy line, which admits plainly that semantic checking can miss, and declares exactly how much it may miss before somebody has to be woken up.

Part three — the ten-item checklist, filled in

This is the payoff of the whole journey: on the day the go-live review is due, not one row starts from zero. The worksheet from post #1 answers the first item, the manifest from post #4 the second, the loop code from post #6 the fourth, and the harness from post #9 answers three items in a row. A team that walked this sequence does not merely "have a system" — it holds one complete body of evidence about the system, and that is the only currency the checklist accepts.

5. Validation Check — This One Is the Launch Gate

Unlike the nine posts before it, this table is not an end-of-chapter exercise — it is the launch gate itself. The rule is the checklist's own: a row passes only when a named artifact is produced. A verbal assurance is worth nothing here, and any row you cannot answer means your system's launch day has not arrived yet.

6. The Road Ahead

The series' ten posts walked from the question of whether your system is genuinely an AI-core system to the document a release decision is made on — and if the whole road had to compress into one sentence, I would use the paper's own conclusion: put hard invariants at the boundaries that admit them; measure semantic properties as fallible estimates; retain enough evidence to reconstruct every route; and scale autonomy to consequence and residual uncertainty.^[1] Those four clauses are the entire series in miniature.

What must be said plainly at the close is what the paper deliberately does not claim — and this series inherits every one of those boundaries. Every number in the paper (517 executions, 37 tests, 30/30 benign, 0/40 against 40/40, 8/12 against 12/12, 0/4 against 4/4) was measured on fixtures the author constructed, over deterministic cores — it is evidence of conformance of the wiring and the boundary semantics, not a field-safety claim, not a verdict on model quality, and not a population claim of any kind.^[1] The empirical warning the paper plants at its centre governs everything we built: a clean fixed suite can coexist with a high semantic escape rate. A system that passes all seven gate rows above is therefore not a system "proven safe" — it is a system whose limits are fully declared, fully evidenced, and fully owned, which is the best that engineering can give a probabilistic core.

The work after launch day is the same loop with no end: every incident feeds the golden set, every slider promotion needs numbers behind it, every model change walks the same gate. And the next question — the one this series has not answered — is the organizational one: what kind of team runs a system like this, how its budget and KPIs are set, what an executive must ask in the approval room. All of that is the subject of the companion series, AI Transformation for Organizations, which starts from this very question seen from the organizational layer downward. This series built the system; that one builds the organization around it.