Stafford

← 2026-10-02 · all briefs · 2026-10-04 →

Stafford Brief — 2026-10-03

Saturday. Short version: the scan found three good instruments this morning; Stafford found the document that was already on this system's own to-read list and has been sitting there for thirteen days — and it says Brandon's thesis back to him, a year early, to his own audience, with 5,000 people behind it.

The 12:00 scan's brief is good and this one does not repeat it. It found the merged-pull-request cluster, conceded that the learning-rate counterargument gained its first supporting measurement, and built a construct-validity argument on top of the concession. That holds. Three things it could not do, because two of them live in files it cannot read and one needed a full text it flagged as owed:

  1. Its new pattern pre-registered an escalation test this base had already passed, twice, months ago.
  2. The document it named as the next target was named in Stafford's own ledger on 2026-09-20, with the instruction "read this, don't search for it." Nobody read it. It was read this afternoon.
  3. The owed Murphy-Hill full text took one fetch. It overturns a recorded limit and adds a result nobody has.

OPS: merged clean from main (base c473144); no thread was due today. research-evidence: pushed to claude/modest-faraday-d52cr0 (commit 11d1347) — evidence layer only (the DORA KB file, the staged entry, the Murphy-Hill verification addendum). Not pushed to its main; promote-claude-branches folds it in once scripts/verify.sh passes, or opens a PR if it does not. No shared meta file, research-index.json, dashboard, brief or CLAUDE.md was touched there — those are the seven PROPOSED-UPDATE blocks at the end of this brief.

📖 TODAY'S READ

DORA's current report says the thing Brandon says, and says it to the people he is trying to convince.

2025 DORA Report: State of AI-assisted Software Development (Google Cloud, published 23 September 2025, about 5,000 technology professionals plus 100+ hours of interviews). File: knowledge-base/dora-2025-state-of-ai-assisted-software-development-2025-09.md. Staged as 2026-10-03-dora-google-clo-2025-dora-report-state-of-ai-assist.

The headline, in their words: "AI doesn't fix a team; it amplifies what's already there. Strong teams use AI to become even better and more efficient. Struggling teams will find that AI only highlights and intensifies their existing problems. The greatest return comes not from the AI tools themselves, but from a strategic focus on the quality of internal platforms, the clarity of workflows, and the alignment of teams."

That is Technology Illusion. Stated more plainly than Paper 4 states it, a year earlier, under Google Cloud's distribution, to engineering leadership. And DORA supplies the moderator in structural terms rather than cultural ones: "teams working in loosely coupled architectures with fast feedback loops see gains, while those constrained by tightly coupled systems and slow processes see little or no benefit" — which is Process Friction with an architecture variable bolted on.

The second finding is the one that matters for the measurement argument, and it is a split. AI adoption is now positively related to delivery throughput and product performance — reversing their 2024 result — and still negatively related to delivery stability. Their reading: "AI accelerates software development, but that acceleration can expose weaknesses downstream."

Why the split is not just another data point. Stability is measured by what happens after a release — things breaking, work having to be redone, how long recovery takes. It is detected by production, not by a reviewer. Every metric in this morning's merged-PR cluster is produced by a reviewer. More on that in Four Forces below; the one-line version is that DORA is measuring the half of the picture that this morning's three instruments structurally cannot see, and on that half the sign is negative.

What Brandon should take from it: cite it. Today. Verified by strict search this afternoon — DORA, Forsgren, "State of DevOps," Accelerate and "error budget" appear nowhere in Papers 2 through 6, and nowhere in the book. The exposure is not that he is wrong. It is that the first reader who follows DORA will find him arriving second without acknowledgement, and that reader is his buyer.

Honest limit, stated up front: this is an opt-in survey where the same person reports both how much AI they use and how well delivery is going. That is a real weakness and Brandon should not lean on it, because his own evidence base is practitioner cases and third-party surveys. Also: the full report PDF was not read — this rests on the first-party announcement — and the 2025 errata page has not been checked.

🔭 THINKER TO WATCH

Nicole Forsgren — lead author of Accelerate and co-founder of the DORA research programme. On the map today for a reason that is uncomfortable rather than interesting: she owns Brandon's central claim in the field Brandon is writing for, and this base holds nothing of hers.

The Accelerate programme's organizing argument — established over a decade of survey research across thousands of organizations — is that software delivery performance and organizational performance are one subject, not two. That is structurally identical to the claim the Five Breakpoints makes about transformation. Her programme got there first, with more respondents, and its vocabulary is already the default among the engineering leaders who read Brandon's papers.

Brandon's differentiation is real but it is narrower than he probably assumes, and it rests on one thing. DORA names the amplifier and does not decompose it. "What's already there" is a single undifferentiated quantity, proxied by platform quality, workflow clarity and team alignment — three capabilities, not five failure modes. DORA tells an organization to improve its foundations. It does not tell them that vague purpose, misaligned incentives, structural friction, technology-on-broken-conditions and false progress fail differently and are fixed differently. "Amplifier" is a finding. Five Breakpoints is a diagnostic. That distinction is defensible and it is the whole of the differentiation argument.

The actionable part: Accelerate is the unread half of a reading assignment this system set itself on 2026-09-20 and has not done. The DORA report is now read; the book is not. It is a book, not a search, and no exploratory slot will ever produce it.

🏢 CASE IN THE WILD

The anonymous "2× mandate" company — already in the base since 7 September, and today's rule says its headline conclusion does not hold.

The case (He, Agarwal, Denisov-Blanch et al., arXiv 2607.01904; 802 developers, 196,212 pull requests, January 2024 – April 2026): a mid-sized AI-forward company committed to doubling merged pull requests per engineer, and hit it — 2.09× the pre-mandate baseline. In the process it rebuilt code review around automation: the share of pull requests getting at least one human review fell from 89% to 68%, automated AI review went from about 19% to about 84%, and load per remaining reviewer roughly doubled.

The company's evidence that quality survived all of this is that "merge and revert rates held steady."

Here is the problem, and it is the mechanism worth naming. A revert is somebody noticing a change was bad and deciding to roll it back. That requires review attention — the exact thing the company had just halved. So a flat revert rate is consistent with two completely different worlds: nothing went wrong, or nobody was left to catch what did. The metric offered as proof that the review step survived is produced by the review step. It cannot settle the question, and this base's own file noted on 7 September that no defect, incident or escape measure appears anywhere in the paper.

This is Technology Illusion in its most expensive form — not a tool bought and ignored, but a tool installed into the judgment step, with the assurance that it works being that the pipeline did not visibly break.

The open question, and it is answerable: that company has the data. Change-failure rate, incidents per release, time to restore — all of it is in the same systems that produced the 196,212 pull requests. It reported the two metrics that cannot distinguish the two worlds and not the ones that can. Was that a reporting choice or an instrumentation gap? Because if a company running a formal, publicly documented 2× mandate with academic co-authors did not measure its own escape rate, the generalisation is bleak: nobody is measuring the thing, and the published record will keep looking reassuring.

⚙️ FOUR FORCES CONCLUSION

Capability — and the specific contribution today is a way to tell which Capability numbers can be trusted.

The scan correctly identified Capability as the force in play and correctly separated readiness from flow. The addition is a sorting rule, and it applies to any function, not just software.

Metrics divide by where a failure gets caught:

The rule: you cannot test "the review step is overloaded" with a number the review step produces. Under saturation, gated metrics can hold steady or even improve because detection failed. That is not a subtle statistical point — it is the difference between "we caught nothing because there was nothing" and "we caught nothing because nobody was looking."

This matters because the scan's new pattern treated six outcomes as interchangeable — "defect rate, incident rate, rework, revert rate, delivered value, time-to-restore." They are not. Three of those are gated and would not have tested anything. The criterion needs to require a post-release outcome, or it can be discharged by a revert rate and will "prove" quality held.

And when you sort the base's instruments this way, they stop disagreeing:

Instrument What it measures Verdict on AI
DX, LinearB, Murphy-Hill gated (merged PRs) gains
He et al. gated (merge + revert) quality held
Faros AI (22,000 devs, telemetry) ungated (bugs +54%, incidents-per-PR +243%) deterioration
DORA 2025 (n≈5,000) ungated (delivery stability) deterioration

Every ungated instrument says the same thing, and it is the opposite of what every gated instrument says. Two different methods — one telemetry, one survey — agreeing across the gate line is considerably stronger than four instruments agreeing on the same side of it.

For paper-2 Claim 4 (the failure mode is harder to detect because AI produces the appearance of execution): this is the mechanism, specified. The appearance of execution is not a vibe. It is the arithmetic consequence of scoring a rollout with metrics the rollout's own bottleneck produces.

💭 OPEN QUESTION

Do strong engineering foundations protect an organization from AI-induced instability, or not? Two large instruments in this base answer that question in flat contradiction, and it is the single most consequential thing Brandon will be asked in a client room.

Same function, overlapping period, opposite answers. And note which way the convenience runs: Faros is the thesis-convenient one. If foundations don't protect you, then the problem must be organizational, which is Brandon's argument. If DORA is right, the remedy is platform engineering and a consultant with a five-breakpoint diagnostic is less necessary than a good staff engineer.

Why it is genuinely open rather than resolvable from the armchair. The designs differ in a way that could produce exactly this split without either being wrong: DORA's maturity measure is self-reported by the same person who reports the outcome, so teams that feel competent report both good practice and good outcomes. Faros measures practice maturity from telemetry and compares an organization against itself at lower AI adoption — a harder test, which strong performers can fail. It is entirely possible that foundations protect you in self-assessment and not in production. That is a publishable finding and nobody has written it.

What it changes for Brandon: he currently has no position on this, and it is the obvious first objection to the whole argument — surely well-run organizations are fine. He should not answer it by picking the convenient instrument. The honest answer available today is that the field's two best instruments disagree, the disagreement tracks whether maturity was self-reported or measured, and the measured one is the pessimistic one.

🥊 CHALLENGE

Logged as a new OPEN challenge today, and it is the largest positioning exposure this base has recorded: DORA published Brandon's thesis in September 2025, at n≈5,000, to his audience, and he has never cited them.

Stated at full strength, and note that it concedes he is right: a reader who follows DORA already knows that AI deployed onto weak organizational conditions returns little, because Google Cloud told them so a year ago with 5,000 respondents and a structural moderator. What is the framework adding? No additional evidence fixes this, because the objection is not about evidence. Being right second, uncited, in front of the people who read it first, is a credibility problem.

What it would take for the objection to win: it wins by default if the corpus keeps stating the organizational-conditions claim as though it were new.

What answers it, and it costs one paragraph. Cite DORA's amplifier finding as independent large-sample corroboration — then say what the framework adds that DORA does not: which of five things is being amplified, and what to do differently depending on the answer. That move converts the biggest exposure in the corpus into its best external support. It is the cheapest high-value item in the challenge ledger.

Second challenge logged today, against Stafford rather than Brandon, because it should not wait to be noticed. The gated/ungated rule above sorts this base's instruments in a suspiciously convenient order: it validates the two that support the thesis and demotes He et al., which is the base's strongest COUNTERARGUMENT. A rule invented by the thesis's own research agent, on the day it was needed, which happens to discredit the best evidence against the thesis, is not a rule anyone should accept on that agent's word. Three things defend it independently of which way it cuts — He et al.'s own paper documents the 21-point collapse in human review coverage; this base recorded the "no defect, incident or escape measure" weakness on 2026-09-07, seven weeks before the rule existed and with no pattern to protect; and the rule has a falsifier that does not mention the thesis. It still must be stated prospectively and applied symmetrically, and the first symmetric test is pre-registered: the Faros-versus-DORA conflict above, where the rule's logic cuts against Brandon's preferred instrument. A rule that only ever fires at the counterargument is not a rule. All three entries: knowledge/thesis-challenges.md.

📈 PATTERN BUILDING

PROPOSED: escalate The Merged-PR Proxy to ESCALATED. Its escalation criterion was met before it was written — by two instruments already in this base.

The scan opened the pattern this morning at three members and pre-registered, carefully and in good faith, what would escalate it: "a fourth instrument on the same substrate measuring AI's effect on a different outcome — defect rate, incident rate, rework, revert rate, delivered value, time-to-restore."

That test was already passed, and not narrowly:

So the pattern escalates, and the test came back confirming it in the strongest available form: changing the outcome variable changes the conclusion, from "AI raised capability" to "AI degraded reliability." That is exactly what the pattern predicted and exactly what nobody had checked.

Member count stays at 3. Faros, He and DORA are the contrast class, not members — they do not share the merged-PR outcome, which is the whole point. The scan's own rule holds: a fourth merged-PR study would add nothing.

The uncomfortable half, which belongs in the pattern file. This is the second time in eight days that this system has pre-registered a criterion, or declared an absence, that its own base already answered — the 2026-09-26 ledger note records the scan asserting an absence into the half of the base it cannot read. Today's instance is worse, because nothing was unreadable: Faros and He et al. are both in research-evidence's own knowledge-base/, and a grep for "incident" would have found them. The remedy is mechanical and should be written into the scan's method: before pre-registering a criterion, grep the base for it. A criterion that is already satisfied is not a criterion; it is a finding being deferred.

🧱 ASSET SUGGESTION

The asset the scan registered this morning has a better argument available than the one it was registered with. Same thousand words, no new reporting.

As registered: the merged-PR proxy — three instruments share one outcome variable, so their agreement is an artifact. True, but it is a claim about a literature, so the reader has to care about the literature.

The better version is a claim about the reader's own dashboard: "Your AI metric is gated by the step your AI rollout broke." The metrics an AI rollout reports are mostly produced by the review and approval step, and a rollout's main effect is to overload that step. Merge rates, approval rates, revert rates — each needs a reviewer to act. If the reviewers are saturated, those numbers can look fine precisely because nothing is being caught. The metrics that survive are the ones production detects on its own: incidents, change failures, time to restore. That version generalises past software, which the shared-proxy version does not — and generalising past software is the whole of Brandon's claim to a wider audience.

It now has independent confirmation on the ungated side from a non-vendor at n≈5,000 (DORA), agreeing with Faros's telemetry from the opposite methodological direction.

And the closer should change. Swap Murphy-Hill's "a merged PR is not the same as the value it delivers" (an author limiting their own paper) for the sentence found in the full text this afternoon: "The pressing open question is now about quality, whether this added throughput yields better software. The field still lacks agreed-upon measures to answer it." That is the best-identified instrument on the substrate saying the field has no agreed measure of the thing boards are being shown.

New required concession, larger than the one registered: the piece must cite DORA rather than present the organizational reading as novel. Handled well, that is a feature — it lets Brandon stand on a Google-distributed result and then say the thing DORA doesn't.

Three things the piece must not do, recorded so they aren't discovered in draft: don't cite DX, LinearB and Murphy-Hill as three agreeing instruments (the standing citation rule forbids it, and the piece's own argument depends on that rule); don't cite the "25% more AI adoption → 7.2% less stability" figure circulating as DORA 2024 (not verified against the 2024 primary — logged Low, do not cite); and don't use Faros and DORA together on whether foundations protect, because they contradict each other there and that is a separate, better essay.

Full spec: knowledge/asset-suggestions.md, amendment 2026-10-03. Blocker unchanged: a venue decision and a thousand words. No clock.

🎓 SPARRING NOTE

Ninth ever; cap clear (zero notes issued since Monday 09-28, four consecutive declines). This does not replace the live 09-17 note — it makes it easier, and it is fifteen minutes.

The live note asks: for a hostile reader who knows Kotter cold, what does Five Breakpoints claim that Kotter's eight errors do not? Today handed you the same problem with a live opponent instead of a historical one, and the live one is harder. Kotter is from 1995 and your reader has to be reminded of him. DORA is current, your buyer reads it, and it says your thesis with 5,000 respondents behind it.

The exercise: answer 09-17 with two columns instead of one. Column A is Kotter. Column B is DORA's amplifier finding. Same question down both: what does Five Breakpoints claim that this does not?

Why two columns is less work than one, not more. The answer for column B is already drafted above — DORA names the amplifier and never decomposes it; "what's already there" is one undifferentiated quantity where you claim five distinguishable shapes with different remedies. If that answer is right, it is probably the same answer as column A — Kotter also gives you a list of errors and no diagnostic for which one you have. And if one sentence answers both columns, you have found the actual contribution and it is the diagnostic, not the taxonomy and not the speed claim — which is precisely the three-way choice 09-17 asks you to make, now with evidence instead of introspection.

The failure mode to watch for, and it is edge #1's signature: the temptation is to answer column B by attacking DORA's instrument (self-reported, same respondent on both sides). Don't. It is true, it is in the KB file, and it is a trap — your own evidence base is practitioner cases and third-party surveys, so that door swings both ways. Ground the claim, don't discredit the neighbour.

SOURCES & THREADS

Candidates: 1 added, 0 promoted, 0 expired. PROPOSED for source-candidates.md — DORA (Google Cloud), first seen 2026-10-03, surfaced by the exploratory read, 1 signal, cadence annual (a yearly report series; under the 2026-10-02 cadence rule its clock is 14 months, and a flat 60-day clock would have expired it long before the next edition). Note for the ledger: this one arrives already proven, not on probation — a decade-old programme whose vocabulary the target audience already speaks. The promotion rule says two signal-rich finds; the honest observation is that the second signal here is Accelerate, which is a reading task rather than a find.

Threads: 0 due, 0 opened, 0 closed, 2 advanced on owed items rather than on dates. No thread's next-check date fell today — the earliest open is 2026-10-09 (middle-manager load-bearing), and the two stale headers the scan repaired this morning are correct.

Exploratory slot (Saturday — no falsification sweep). Spent on reading, not searching, and that was the finding. The scan's handed-forward target was "the DORA-style delivery-outcome genre." Stafford's own query log already named the exact document on 2026-09-20 and said "Next move is reading, not searching: Accelerate plus the current DORA report. Do not re-run this as a general web search" — and it sat unread for thirteen days while two agents independently rediscovered the need for it. Base checked against the target first per the 09-26 correction: zero of 634 index entries and zero KB files in either repo on DORA, State of DevOps, Forsgren or Accelerate. Route: straight to dora.dev and the first-party Google Cloud announcement; one domain-restricted search used only to locate those pages. Version check performed per hard rule 14 and it earned its keep: dora.dev/research/publications/ lists no 2026 report, so the September 2025 edition is current and the several third-party pages titled "DORA 2026" are aggregator restatements — citing one would have misdated the current edition by a year. Logged in knowledge/query-log.md. Do not re-run as a web search.

Method handed forward, and it is a correction to this system's priorities rather than a next population. Today's best find was not discovered; it was collected from a list this system had already written. Two independent paths converged on one named, unread document. The binding constraint today was reading, not search. The next exploratory slot should check the owed-reading list before composing a query — and the remaining item on it is Accelerate (Forsgren, Humble & Kim, 2018), which no slot will ever produce because it is a book.

No window opened. Fourteenth consecutive scan without one. An asset amendment was filed instead; see above.

Routing

strategy — the highest-value paragraph in the corpus is one paragraph long and it is unwritten. Cite DORA's amplifier finding as independent large-sample corroboration of the organizational-conditions claim, then state what Five Breakpoints adds: which of five things is being amplified, and what to do differently depending on the answer. This converts the base's largest positioning exposure into its best external support. Papers 2 and 4 both need it; so does any talk given to an engineering audience. knowledge/thesis-challenges.md, priority challenge, 2026-10-03.

strategy — a diagnostic sharper than the one the scan proposed this morning. The scan's prior question was "is this number an output of the tool or an outcome of the business?" Better, because it is checkable in thirty seconds in a client meeting: does producing this number require a reviewer to do something? If yes, it cannot tell you whether your review step is holding. Ask for one metric that production detects without a human in the loop — incidents, change failures, time to restore. That question works in any function, not just software.

market — the asset's spine, closer and required concession all changed; the cost did not. See 🧱 above and the amendment in knowledge/asset-suggestions.md.

governance — nothing today.

personal — the one live sparring note (09-17) got cheaper to answer, not more expensive. See 🎓 above: two columns, Kotter and DORA, one question down both.

PROPOSED-UPDATE blocks for research-evidence (shared meta files — Stafford proposes, Brandon applies)

1. knowledge/emerging-patterns.md — anchor: Scan 2026-10-03 → Pattern: The Merged-PR Proxy → "What would make this escalate".

Escalated 2026-10-03 (Stafford, same day) — criterion (a) was already satisfied when the pattern was written, by two instruments in this repository's own knowledge-base/. Criterion (a) asked for "a fourth instrument on the same substrate measuring AI's effect on a different outcome — defect rate, incident rate, rework, revert rate, delivered value, time-to-restore." Discharged three times: Faros AI (faros-ai-engineering-report-acceleration-whiplash-2026-04.md, filed 2026-08-16; 22,000 developers, within-organization telemetry; bugs per developer +54%, incidents-to-PR +242.7%, code churn +861%, PRs merged with no review +31.3%); He et al. (he-denisov-blanch-2x-mandate-review-capacity-2026-07.md, filed 2026-09-07; revert rates on 196,212 PRs); and DORA 2025 (dora-2025-state-of-ai-assisted-software-development-2025-09.md, found 2026-10-03; delivery stability, n≈5,000). The test returned the strongest possible confirmation: changing the outcome variable reverses the conclusion, from AI raising capability to AI degrading reliability. Member count stays at 3 — these three are the contrast class, not members, since they do not share the merged-PR left-hand side. Amendment to criterion (a) itself, because as written it could have been discharged by a metric that cannot test the claim. The six outcomes it lists are not interchangeable; they divide by where a failure is detected. Gated outcomes are produced by the review-and-merge step (revert rate, merge rate, approval rate, rework-in-review). Ungated outcomes are detected after release by production (incidents, change-failure rate, time-to-restore, escaped defects). A hypothesis that the review step is overloaded cannot be tested with a metric the review step produces — under saturation it holds flat because detection failed. He et al. is the demonstration: human review coverage fell 21 points (89%→68%), automated review rose to ~84%, per-reviewer load doubled, and the evidence offered that quality held is "merge and revert rates held steady." Criterion (a) should require a post-release outcome. Sorted this way the base stops disagreeing: both ungated instruments (Faros telemetry, DORA survey) report deterioration; all gated ones report gains. Method note for this repo, and it is the second instance in eight days. The 2026-09-26 ledger note records an absence asserted into the half of the base this scan cannot read. Today nothing was unreadable — Faros and He et al. are in this repository's own knowledge-base/, and a grep for "incident" would have surfaced both. Before pre-registering a criterion, grep the base for it. A criterion already satisfied is a finding being deferred.

2. knowledge/story-threads.md — anchor: Does AI actually make juniors senior faster? — the learning-rate channel.

2026-10-03 (Stafford, same day): criterion (c) discharged — negative — and the owed Murphy-Hill full text is read. Fetched from arxiv.org/html/2607.01418v1. The paper contains no review-burden, revert, defect, incident or code-quality measure, and nothing on sign-off authority. The authors state the gap: "The pressing open question is now about quality, whether this added throughput yields better software. The field still lacks agreed-upon measures to answer it." Three further results, two of which change the base's reading of this paper. (i) Identification specified and stronger than recorded: CausalImpact BSTS against a synthetic control of ten never-user pools (+24.0%, 95% CI +14.5–33.7%, p<0.001) plus engineer-and-week fixed-effects Poisson on within-person variation — so the KB file's limit 3 ("the counterfactual is doing unexamined work… selection is the whole question") is withdrawn, in the direction favouring the counterargument. (ii) The effect is a C shape: junior ICs and senior managers gained more than mid-career (IC4 ref +21.3% [+19.6, +23.0]); same by tenure (5–15yr ref +21.5%). Friebel's channel needs the bottom of the distribution, not both ends — a C shape is task composition, not qualification. (iii) Collision with the DX entry filed the same day: the authors flag their <1-year-tenure estimate as possibly confounded by onboarding, which is the correlation DX publishes as its headline. Recorded as a dated verification addendum to the KB file. Thread criterion (c) remains the most valuable open item but should now be restated as unmeasured by anybody, on the authors' own statement, rather than as awaiting a search.

3. knowledge/story-threads.md — anchor: Does the merged-PR proxy survive a value measurement? (opened 2026-10-03, next check 2026-12-05).

2026-10-03 (Stafford, same day): the discriminating test as pre-registered is already answered, so narrow it. Criterion (a) — AI exposure against a non-throughput outcome on the same units — is satisfied by Faros (2026-08-16), He et al. (2026-09-07) and DORA 2025 (today). Replacement criterion, which is genuinely open: does the ungated instruments' pessimism survive a design in which engineering maturity is measured rather than self-reported? The live form is a direct contradiction between two large instruments — DORA (n≈5,000, self-reported maturity): loose coupling and fast feedback loops determine whether AI gains or costs. Faros (22,000 developers, telemetry, within-organization): strong DORA-style foundations give no protection regardless of baseline maturity. Significant development: any instrument measuring practice maturity independently of the respondent and testing it as a moderator of AI's effect on a post-release outcome. Next check brought forward to 2026-11-07 — this is checkable now and does not need December.

4. knowledge/publication-windows.md — anchor: ASSET — The merged-PR proxy (registered 2026-10-03, no clock).

Amended 2026-10-03 (Stafford, same day), no new work, no clock. Spine: reframe from the merged-PR proxy to "Your AI metric is gated by the step your AI rollout broke" — a claim about the reader's dashboard rather than about a literature, and one that generalises past software. New independent support on the ungated side: DORA 2025, n≈5,000, non-vendor — AI adoption positive on throughput, negative on delivery stability, agreeing with Faros's telemetry from the opposite methodological direction. Closer changed to Murphy-Hill et al.'s full-text sentence "The pressing open question is now about quality… The field still lacks agreed-upon measures to answer it." Second required concession, larger than the registered one: DORA stated the organizational-conditions claim in September 2025, so the piece must cite it as corroboration rather than present that reading as novel. Three prohibitions: do not cite DX/LinearB/Murphy-Hill as three agreeing instruments; do not cite the "25% adoption → 7.2% stability" figure attributed to DORA 2024 (unverified against the 2024 primary — Low, do not cite); do not use Faros and DORA together on whether foundations protect — they contradict each other there, and that is a separate essay. Full spec: stafford-research/knowledge/asset-suggestions.md, amendment 2026-10-03.

5. knowledge/source-candidates.md — new candidate.

DORA (Google Cloud) · first seen 2026-10-03 · surfaced by: Stafford's exploratory read of 2025 DORA Report: State of AI-assisted Software Development (2025-09-23, n≈5,000) · signal count 1 · cadence annual (14-month clock under the 2026-10-02 rule; a flat 60-day clock would have expired it eight months before the next edition). Note: arrives proven rather than on probation — a decade-old research programme whose vocabulary Brandon's target audience already speaks, and whose 2025 headline states Paper 4's thesis. Related outputs to acquire, not yet held: Impact of Generative AI in Software Development (March 2025), DORA AI Capabilities Model (December 2025), and the 2024 Accelerate State of DevOps Report — the last of these is needed to verify or kill the circulating "25% adoption → 7.2% stability" figure.

6. knowledge/field-map.md — new entry.

Nicole Forsgren — lead author of Accelerate (Forsgren, Humble & Kim, 2018), co-founder of the DORA research programme. First logged 2026-10-03. Why she is in Brandon's territory: the programme's organizing claim — software delivery performance and organizational performance are one subject — is structurally identical to the Five Breakpoints' claim about transformation, established over a decade of survey research across thousands of organizations, and already the default vocabulary of the engineering leaders Brandon's papers address. Brandon's differentiation, and it is narrow: DORA names the amplifier and does not decompose it — "what's already there" is one undifferentiated quantity, proxied by platform quality, workflow clarity and team alignment, where Brandon claims five distinguishable failure modes with different remedies. Amplifier is a finding; Five Breakpoints is a diagnostic. Base coverage: zero files on her work. Accelerate is the unread half of a reading assignment set 2026-09-20.

7. knowledge/paper-2-case-file.md — anchor: Claim 4.

2026-10-03 (Stafford): Claim 4 acquires its mechanism, not just more evidence. Claim 4 holds that the AI-era failure mode is harder to detect because AI produces the appearance of execution. The appearance is now specifiable rather than evocative: it is the arithmetic consequence of scoring a deployment with metrics the deployment's own bottleneck produces. Gated metrics (merge rate, approval rate, revert rate, rework-in-review) require review attention to be generated; an AI rollout's primary effect is to consume review attention; so under load those metrics can hold steady or improve because detection failed. Ungated metrics (incidents, change-failure rate, time-to-restore) are produced by production. Across this base, every ungated instrument reports deterioration (Faros: incidents-to-PR +242.7%, bugs +54%; DORA 2025: delivery stability negative at n≈5,000) and every gated one reports gains or stability. Two methods — telemetry and survey — agreeing across the gate line is stronger support than four instruments agreeing on one side of it. Caveat required in print, per the challenge logged today: this rule demotes He et al., the base's strongest COUNTERARGUMENT, so it must be stated as a general principle and applied symmetrically — including to the Faros-versus-DORA conflict, where it cuts against Brandon's preferred instrument.