Intent · CHG-2026-014913

change_id: CHG-2026-014913
risk_class: R2
autonomy_tier: A2
controls: ['TRC-01', 'CHG-04']
data_classification: internal
originator: olaf@freundcloud.com
agent_identity: svc-agent-platform
model_route: gateway/tier-frontier
supersedes: None

Problem

The playbook was written in August 2026 and argues its case almost entirely from first principles. In the month since, the evidence caught up with it — and the document does not cite any of it.

It is missing the corroboration. DORA’s 2026 research describes AI as an amplifier that expands capacity where tests and context are good and magnifies dysfunction where they are not. That is this playbook’s thesis, arrived at independently by someone else, and it is not mentioned. Thoughtworks’ Technology Radar Vol. 34 independently lists two of the four portable assets. UK supervisors are on a statutory path to designate major AI providers as critical third parties by end-2026, which turns §3’s concentration-risk argument from a consultant’s opinion into a scheduled regulatory event.

It is missing the counter-evidence, which costs more. METR’s randomised controlled trial found experienced developers were 19% slower with AI tools while estimating they had been 20% faster. §2 opens with “the build step collapsed from weeks to hours” and never engages with this. A reader who already knows the METR result and does not see it here stops trusting the rest of the document — and the perception gap is, in fact, the strongest argument that exists for §9’s Tier 3 “do not measure” list.

Its threat section is one team’s opinion. §8.5 has four well-chosen paragraphs written before OWASP published a peer-reviewed Top 10 for Agentic Applications. Four threats are now ten, with identifiers, and four of the ten are unaddressed here.

It has no named incidents. Abstract risk does not move a risk committee. 2026 supplied incidents that each demonstrate one of the seven principles, including one — untrusted GitHub metadata treated as authoritative prompt content across three rival vendors at once — that proves the vendor-neutrality argument better than any reasoning in §3 does.

Every statistic in it is unsourced. “Roughly a third of new enterprise code”, “roughly half of organisations”. No citation, no date. A document whose fifth principle is evidence as a by-product, not reconstruction cannot carry unsourced numbers; it hands a reviewer the easiest possible objection.

And it is unreadable by half its intended audience. It is written for a CTO, CISO or head of internal audit. A board member, a business sponsor or a risk officer without an engineering background gets through §1–§3, hits §5, and never recovers. §6 and §7 are unreachable for them. This stopped being only a presentation problem in August 2026, when national enforcement of EU AI Act Article 4 — the AI literacy obligation on providers and deployers, proportionate to role — opened.

Who is affected

The board member or business sponsor asked to fund this, who currently cannot read past §5.
The second-line risk officer mapping this to a control framework, who needs identifiers, not prose.
Anyone citing a statistic from this document in a paper that goes to a supervisor.
The engineer who has read the METR result and is deciding whether this document is honest.

Success criteria

Every statistic carries a primary source, or it is removed.
The threat section maps onto OWASP ASI01–ASI10 and addresses all ten.
At least four named 2026 incidents, each attached to the principle it demonstrates.
A reader who does not write code can understand what this proposes, from the front page.
The regulatory picture covers UK as well as EU, and includes Article 4.
Nothing the document newly claims is a control this repository cannot evidence.

Out of scope

A sixth plane. Identity deserves the depth and gets it, inside §5.2. It does not get its own plane: §5 opens by requiring each plane be independently sourceable, replaceable and auditable, and identity is cross-cutting rather than separable. Adding one would also falsify site/assets/casts/control-layer.cast, which says “five planes” in a recording that cannot honestly be edited.
policy/. No new control here is machine-checkable, and policy/** carries an R3 path floor. Paying R3 for a documentation change with no new gate is not a trade worth making.
New Substitution Test checks. Appendix C is twelve items because substitution_test.py implements check_01–check_12. Changing one without the other splits the source of truth.
Re-recording the screencast. No change here alters what the demo does.

Constraints

The document’s argument is sound and stays. This is corroboration, correction and access — not a rewrite.
Anything added to §8.4 or §9 that this repository cannot evidence must be recorded as a deliberate departure in docs/playbook-map.md, not left as an unbacked claim.
Sources must be verifiable at origin. One claim in the review that prompted this change was a citation I doubted and could not confirm from secondary sources; it turned out the playbook was right and the doubt was wrong. Both the confirmation and the method belong in the record.

Why this is 014913 and not 014912

It was 014912 when it was committed, and 014912 was already taken.

The Stage 6 detector allocated that id on 30 August 2026 for a post_deploy_error_rate anomaly at 6.926 sigma. Its intent lives on branch stage6/CHG-2026-014912 and its triage is issue #8. Neither is on main, which is exactly why this went unnoticed: the next id was chosen by listing intent/, specs/ and plans/ on the default branch, and an id allocated by an automated detector on a branch it is not permitted to merge is invisible to that check.

The id is the join key. §6.2 claims the chain can answer “which production changes in Q2 touched control X, agent-authored, at what tier, approved by whom” in one command. Two unrelated changes under one id do not make that question hard, they make the answer wrong — a documentation rewrite and a production anomaly returned as one change.

Renumbered forward rather than by rewriting the published commit: 83c61ab says 014912 in its message and is already on origin/main, and rewriting a pushed history to tidy an audit trail is a worse failure than the one being fixed.

The generalisable finding. Allocating a change id by reading the default branch is only correct where nothing else allocates ids. This repository has an automated detector that does, on branches, by design — the same segregation of duties that stops Actions opening pull requests is what keeps its output off main. Any allocator here has to look at branches and issues too, which is what docs/org-prerequisites.md should say and does not yet.