Divergence escalates the wrong population: unanimous misses auto-pass
Agent Determinism Illusions (Part 7)
Where this fits: This part ...
For further actions, you may consider blocking this person and/or reporting abuse
The T1/T2 distinction here is clarifying. I've been thinking about this as cheap recurrence detection vs expensive novelty detection — T1 catches the modes you've already burned, T2 catches the ones you haven't seen yet.
The out-of-channel update is the part I keep coming back to. Same-channel verification (another LLM reading the same prose) feels like it should help but often just replicates the same blind spots. The checksum/structural probe that doesn't need the rationale to be interpretable — that's the real boundary.
Question: have you tested whether the out-of-channel probe catch rate stays stable as the task complexity increases? I'm wondering if there's a complexity threshold where even structural invariants become too expensive to compute relative to the task itself.
Xiao Man — sharp framing. I ran it as two axes, not one: task/artifact depth (T1–T4) × probe depth (P1–P4), checksum-style only (pass/fail from schema+artifact, never from judge rationale).
Catch, when matched: 100% across T1–T4. On this fixture, out-of-channel catch is stable with task complexity — if probe depth tracks the schema.
Catch, when under-specified: collapses. Same T4 artifacts: P1 23% → P2 30% → P3 70% → P4 100%. Misses are exactly the nested/cross-field rules the shallow probe never looks at. Having “a checksum” is not enough; the invariant set has to cover the failure surface.
Relative cost: under an instrumented execution-ops model, matched cost_ratio stayed below 1 all the way (≈0.23 / 0.14 / 0.20 / 0.19). No threshold where the probe became as expensive as the task representation. Deeper probes cost more; over-spec keeps catch while raising cost — waste, not safety. An authoring-cost model would cross earlier.
Wrote the matrices into Part 7 §5 Update (2026-07-24). Same caveats as the hold-out: fixture + structural half of the novelty bar, not production wall-clock, not causal independence. Thanks for forcing the dual-axis cut.
The P1→P4 progression is the part that stuck with me. 23% → 30% → 70% → 100% — that's not gradual improvement, that's phase transitions at specific schema coverage thresholds.
The 'over-spec = waste not safety' point is sharp. I've seen teams add more validation layers thinking they're buying robustness, but they're just burning cycles on invariants that never trigger because the failure modes are elsewhere.
Question on the probe selection: in your setup, is the P-level fixed per task type, or do you escalate dynamically based on artifact characteristics? Wondering if there's a cheap pre-check that routes to P3/P4 only when P1/P2 signal potential cross-field issues.
Xiao Man — yes on the phase-transition read, and thanks for the routing question. I ran both forks on the same checksum fixture.
Fail-signal / cheap pre-check: P1 PASS → accept; P1 FAIL → jump to matched Pi. On T4 that drops catch to 23% (same floor as under-spec P1) with 22/31 cross-field misses — budget / port-unique / fingerprint breaks often pass the shallow probe, so the cascade never fires. It also looks cheaper (~7 vs ~30 ops). That is the trap that pairs with “over-spec = waste”: under-spec saves cycles on the blind spot. Cascading on PASS up to schema-matched depth recovers catch, but that ceiling is fixed matched depth — not a savings policy.
Artifact characteristics: infer depth from keys (
budget→ P4,services[]→ P3, …). On honest artifacts, catch matches fixed task-type routing (100% T1–T4). Strip the depth cue or inject a decoy nest and it breaks: cue-erase → 82% (P4-only fingerprint misses); T2+decoy services → 0% catch at ~5× the ops. So shape can set P-level only as an honest schema proxy — still matched-depth routing, not “deepen when P1/P2 signal.”Direct answer: in this setup P-level is fixed by schema depth (task type, or a non-writable shape proxy for it). A cheap P1/P2 pre-check that routes deeper only on fail does not catch the cross-field population — those are exactly the failures the pre-check does not signal.
Wrote both runs into Part 7 Update (2026-07-27). Same caveats as the dual-axis: fixture, structural half, instrumented ops.
Scripts / results:
github.com/zxpmail/blog/blob/main/...
github.com/zxpmail/blog/blob/main/...
github.com/zxpmail/blog/blob/main/...
github.com/zxpmail/blog/blob/main/...
Part 7 (local body; sync DEV.to Update if the live post is behind):
github.com/zxpmail/blog/blob/main/...
Thread:
dev.to/zxpmail/divergence-escalate...
Yes on the "savings policy vs fixed depth" split — the cheap fork looks cheaper (~7 vs ~30 ops) but it concentrates misses on the same band the cascade was supposed to catch. That's the under-spec blind spot showing up as a 23% T4 floor.
The depth-from-keys inference is the part that stuck. budget → P4, services[] → P3 is deterministic by schema, which makes it cheap, but it also makes the key shape the new attack surface. Strip the budget key, nest the services under a wrapper, and the depth signal is gone before any probe runs. cue-erase → 82% isn't the probe failing — it's the routing layer failing to classify the artifact in the first place.
So I'd push the stable-referent test one level up: instead of "does this case have a stable referent?" ask "is the depth signal in this artifact stable under minor shape changes?" If yes → schema rule. If no → don't infer depth; route to a fixed mid-depth probe as a baseline, then escalate to a human or full verification.
That keeps the fast path fast but puts the inferability question in front of the depth question. Otherwise the geometry just moved one level up.
The "geometry moved one level up" read is right. budget→P4 and services[]→P3 are schema-deterministic and cheap, but the determinism is on surface shape —
exactly what an adversarial artifact rewrites. Ran three perturbation cells against the same router; all three flip routing classification entirely.
cue_erase (strip budget cue, force wrong fingerprint residual): artifact-shape routing sends 80/80 to T3/P3 instead of T4/P4. Catch drops to 82.5% — 7
cross-fingerprint misses. Right probe at wrong depth.
decoy_nest (inject decorative services[] into T2): routes 80/80 to T3/P3 instead of T2/P2. Catch drops to 0% — 40/40 missed. Wrong probe, wrong depth.
rename_keys (services→components on T3, schema-synonym rename, semantic-preserving): routes 80/80 to T1/P1 instead of T3/P3. Catch 100% — but P1
over-rejects everything because T3 has no top-level max_connections. False_reject 100%. New failure axis: cue_erase and decoy_nest broke catch;
rename_keys breaks specificity.
Worse: in the rename_keys cell, fixed_matched ALSO false-rejects 100%, because the probe implementation itself hardcodes
art.get("services"). So thekey-coupling isn't just at the routing layer — the probe layer has it too. "Fixed mid-depth probe as baseline" only works if the probe is anchored to
structural invariants, not to key names.
So "is the depth signal stable under minor shape changes?" — no, on three perturbations and two axes. Your design cut is the right one: don't infer depth
from shape; route to a fixed mid-depth probe as baseline; escalate when the probe signals cross-field. Fast path stays fast on honest artifacts; unstable
cases fail over to fixed-depth rather than right-probe-wrong-depth. Add: anchor the baseline probe to structural invariants (checksum fixture), not key
names.
My prior reply said P-level is "fixed by schema depth, or a non-writable shape proxy for it." Your sharpening makes the non-writable assumption explicit
and testable. The three perturbation cells already broke it; I should have drawn the design implication instead of stopping at "shape can set P-level only
as an honest schema proxy."
github.com/zxpmail/blog/blob/main/...
github.com/zxpmail/blog/blob/main/...
@zxpmail The death-cell tiebreaker is the cleanest decision rule we've landed on.
Rate alone can't break the 7/8 three-way tie — that's a real result. Picking synonym_list as primary because it dies only on out-of-declaration rename (exactly the failure the declaration review catches anyway) is elegant: the gap in the anchor maps to the place where a human check already exists. You're not choosing the best anchor — you're choosing the one whose blind spot is cheapest to cover.
The secondary layer reinforces this. Structural dies on shape-clone, which is a different and more expensive failure mode, so it earns its place as the parallel probe. cross_field at 6/8 with the P7 inner-rename death is real but too costly for always-on. Keeping it in the suite but off the commit gate is the right call.
On fallback-with-logging over voting: agreed completely. Voting reopens the disagreement-routing problem this thread started with. Logging disagreements while keeping one gate in charge turns the secondary into telemetry without diluting accountability. That's the production-grade design.
The pipeline summary — declare, path-pass every renamed key outer and inner, primary plus secondary with disagreement logs, retire against real traffic — is the most complete verification recipe we've built across this entire series. The last step ("retire against real traffic") is the one most people skip. Anchors that look essential in the mutation suite may never fire in production, and anchors that fire constantly may all be catching perturbations the codebase never generates.
"Data picks; philosophy doesn't" — that's the right closing frame for the whole series.
The death-cell tiebreaker is the cleanest decision rule this open question lands on.
Rate alone can't break the 7/8 three-way tie — that's a real result. synonym_list as primary because it dies only on out-of-declaration rename (exactly the failure the declaration review catches anyway): the gap in the anchor maps to the place where a human check already exists. Not choosing the "best" anchor — choosing the one whose blind spot is cheapest to cover.
Secondary reinforces that. structural dies on shape-clone, a different and more expensive failure mode, so it earns the parallel-probe seat. cross_field at 7/8 with the P7 inner-rename death is real but too costly for always-on — keep it in the suite, off the commit gate.
On fallback-with-logging over voting: agreed. Voting reopens the disagreement-routing problem this thread started with. Logging disagreements while keeping one gate in charge turns the secondary into telemetry without diluting accountability.
Pipeline: declare → path-pass every renamed key (outer and inner) → primary + secondary with disagreement logs → retire against real traffic. That last step is the one most people skip. Anchors that look essential in the mutation suite may never fire in production; anchors that fire constantly may only be catching perturbations the codebase never generates.
Data picks; philosophy doesn't.
github.com/zxpmail/blog/blob/main/...
github.com/zxpmail/blog/blob/main/...
github.com/zxpmail/blog/blob/main/...
The death-cell-as-tiebreaker read is exactly right. Rate is necessary but not sufficient — three anchors at 7/8 means rate tells you they are all good, not which one is good in the right way. The diagnostic is the failure mode, not the success rate.
synonym_list dying only on out-of-decl rename is the clean mapping to an existing human check. That is what makes it the right primary: its blind spot is not "somewhere in the design space" but "exactly where the declaration review already covers." Cheap anchor for expensive failures.
And fallback-with-logging over voting closes the loop. Voting would reopen the disagreement-routing problem. Logging keeps one gate in charge and turns the secondary into telemetry. That is a design decision, not a compromise.
Yes — failure mode over rate, primary as placement not ranking. Ran the logging claim.
Primary synonym_list + secondary structural, no vote. Disagreement only on P2 (primary dies) and P6 (secondary dies). Under rename-heavy traffic (n=400), disagreements cluster on P2 → pressure on the primary (declaration review already covers that cell). Under shape-clone-heavy traffic, they cluster on P6 → pressure on the secondary (primary never dies there; do not promote secondary to co-gate).
So logging is design, not compromise: the modal disagree cell says which side is under pressure. It does not reopen a committee at commit time.
github.com/zxpmail/blog/blob/main/...
github.com/zxpmail/blog/blob/main/...
@zxpmail The scope note matters and I want to make sure I read it right.
The sensor is telemetry on measured axes (P2/P6), not a substitute for T2 or out-of-channel novelty. That is the correct boundary. When both anchors agree and are wrong, the sensor stays quiet — same shape as the unanimous miss from Part 7. No signal is not the same as no problem.
What this does add is operational clarity: you now know which axis is under load before you escalate. The disagree cell does not resolve the miss; it tells you where the probe suite is being stressed. That is the difference between load sensor and judge — a judge claims verdict authority, a sensor claims pressure visibility.
The unanimous miss shape is the one this architecture cannot fix internally. You need an out-of-channel probe or a different substrate entirely to catch it. The load sensor just makes sure you are not wasting time looking at the wrong axis when the silence means something went past both gates.
You read the scope note right — and the pressure-visibility vs verdict-authority cut is the one I wanted locked.
Pinned the mute cell on the same fixture (synonym_list primary, structural secondary). Controls still fire: P2 lights primary pressure, P6 lights secondary. New cell P8: true payload moved to
instances(outside the synonym list); bait undermodules(in-list + haslimits). Both anchors land onmodules, both wrong, sensor quiet, primary non-null so the gate would ship the bait subtree.So: disagree cell = which measured axis is under load. Agree-wrong = no cell, same shape as Part 7's unanimous miss — no signal is not no problem. The sensor does not catch that population; it only stops you from escalating down a lit axis that is not where the silence is. T2 / out-of-channel still required for the miss that never disagrees.
github.com/zxpmail/blog/blob/main/...
github.com/zxpmail/blog/blob/main/...
@zxpmail P8 is the cell I was waiting for, and the 5x5 table makes the architecture legible in a way the previous posts did not. The fact that both FP cells (P2, P9) are now visible but only one gets to call it FP is exactly the lever -- the sensor suite can name "something is wrong" but it cannot own "this is the wrong thing." That distinction is what separates a load sensor from a verdict, and your table shows it cleanly: QUIET/FIRE on the left axis, check/cross on the right axis, and the cross tells you who gets to make the call.
A few things I want to push on:
The three provenance options are ordered by epistemic distance, not cost. same-author = you redraw the boundary (cheapest but you are still the reference); different-author = a second party with a verdict; no reference = tripwire only, no judgment. I read your ordering as: as you move from same-author to no-reference, you give up answering and gain correctly failing open to a human. The cost is not the tripwire's compute -- it is the latency to human review for every legitimate relocation that crosses the gate. P9 (legit to modules) is the price: you saved the FP in P2 by handing the FP in P9 to escalation, not by removing it.
"There is always a gate" is the design parameter, not a concession. What you have actually shown is that the tripwire does not remove the gate, it moves the gate's reference point further from the producer. The new parameter is how far from the producer the gate's reference sits. same-author = 0 distance (gate sits inside the same epistemic channel), different-author = 1 hop, no-reference = unbounded (the reference is whatever the human brings). The failure modes scale with this distance: 0 hops = in-channel collapse, 1 hop = verdict-authority attacks, unbounded = you are now depending on a human who can also be wrong. The 5x5 table is essentially a partial survey of which attacks each distance protects against and which it admits.
"Who verifies the verification" terminates in a trust gate, and that is a different failure class. I think the structural difference is: an in-channel gate fails by false confidence (it cannot tell P2 from P8), an out-of-channel gate fails by false negative (it can tell P2 from P8, but it also escalates P9, which is correct behavior, not failure). The bias of the out-of-channel gate is conservative; the bias of the in-channel gate is silent. That asymmetry is what makes the tripwire honest even when it routes correctly.
The open question I think the table leaves open: who owns the baseline? If the baseline is a frozen commit, then different-author still has a reference and the no-reference branch is a one-time choice per project. If the baseline is the live tree, then no-reference is unstable. The gate's reference has to be a named, frozen artifact or the FP/FN distinction collapses back into the artifact. I think P9's FIRE(advisory) instead of FIRE(FP) is the design hint -- the gate's reference is allowed to be slow, but it cannot be live.
Yes — and the lever you name is the one the table was built to show.
Load sensor = can surface pressure; cannot own the verdict. QUIET/FIRE says whether something moved on a measured axis; the check/cross is who is allowed to call the cell. P8 is where both axes agree and both are wrong: the suite stays quiet, and quiet is not a pass — it is the absence of a claimant.
On the ordering: epistemic distance, not compute cost. Agreed, and sharper than I had it. Same-author is zero hops — you redrew the boundary inside the producer's channel. Different-author is one hop — a second party that can still verdict. No-reference is unbounded — tripwire only, judgment deferred. What you give up as you move right is answering; what you gain is failing open to a human instead of failing closed into false confidence. The bill is not the tripwire's cycles. It is review latency on every legitimate relocation that crosses the gate. P9 is that bill in one cell: the FP that used to sit silently in P2 is not deleted — it is handed to escalation as advisory FIRE. Saving the silent FP by paying the loud one is the design, not a leftover.
"There is always a gate" as the parameter, not the concession — yes. The tripwire does not remove the gate; it moves the gate's reference farther from the producer. Zero hops collapses in-channel (cannot tell P2 from P8). One hop buys a real second author and admits verdict-authority attacks on that author. Unbounded depends on a human who can also be wrong. The 5×5 is a partial attack survey across those distances — which misses each distance closes, which costs it admits.
The failure-class cut is the one I want locked. In-channel gate fails by false confidence: it cannot separate P2 from P8, so it ships quiet. Out-of-channel gate fails by false negative on the verdict axis — more precisely, it refuses the verdict axis and escalates, including P9. That escalation is correct behavior, not a defect. Conservative bias vs silent bias. The asymmetry is what makes the tripwire honest when it routes: it can be wrong about whether a human needed to look only in the direction of looking too often, never in the direction of looking away while both anchors agreed on the bait.
On who owns the baseline — you closed the question I left open. If the baseline is a named, frozen artifact (a commit, a sealed checksum, a release tag), different-author still has a referent, and no-reference is a one-time project choice of which freeze to trip against. If the baseline is the live tree, the FP/FN distinction collapses back into whatever the tree happens to be today — the gate's reference becomes another editable surface. P9's FIRE(advisory) instead of FIRE(FP) was the hint: the reference is allowed to be slow; it is not allowed to be live. Refreshing the freeze is a deliberate human act — a new named artifact — not a pull from the working tree.
So the design parameter, restated in your terms: how many hops from the producer the gate's reference sits, and whether that reference is frozen. Distance sets which attacks you can name; freeze sets whether the names stay put.
@zxpmail P8 is the cell I was waiting for, and the 5x5 table makes the architecture legible in a way the previous posts did not. The fact that both FP cells (P2, P9) are now visible but only one gets to call it FP is exactly the lever -- the sensor suite can name "something is wrong" but it cannot own "this is the wrong thing." That distinction is what separates a load sensor from a verdict, and your table shows it cleanly: QUIET/FIRE on the left axis, check/cross on the right axis, and the cross tells you who gets to make the call.
A few things I want to push on:
The three provenance options are ordered by epistemic distance, not cost. same-author = you redraw the boundary (cheapest but you are still the reference); different-author = a second party with a verdict; no reference = tripwire only, no judgment. I read your ordering as: as you move from same-author to no-reference, you give up answering and gain correctly failing open to a human. The cost is not the tripwire's compute -- it is the latency to human review for every legitimate relocation that crosses the gate. P9 (legit to modules) is the price: you saved the FP in P2 by handing the FP in P9 to escalation, not by removing it.
"There is always a gate" is the design parameter, not a concession. What you have actually shown is that the tripwire does not remove the gate, it moves the gate's reference point further from the producer. The new parameter is how far from the producer the gate's reference sits. same-author = 0 distance (gate sits inside the same epistemic channel), different-author = 1 hop, no-reference = unbounded (the reference is whatever the human brings). The failure modes scale with this distance: 0 hops = in-channel collapse, 1 hop = verdict-authority attacks, unbounded = you are now depending on a human who can also be wrong. The 5x5 table is essentially a partial survey of which attacks each distance protects against and which it admits.
"Who verifies the verification" terminates in a trust gate, and that is a different failure class. I think the structural difference is: an in-channel gate fails by false confidence (it cannot tell P2 from P8), an out-of-channel gate fails by false negative (it can tell P2 from P8, but it also escalates P9, which is correct behavior, not failure). The bias of the out-of-channel gate is conservative; the bias of the in-channel gate is silent. That asymmetry is what makes the tripwire honest even when it routes correctly.
The open question I think the table leaves open: who owns the baseline? If the baseline is a frozen commit, then different-author still has a reference and the no-reference branch is a one-time choice per project. If the baseline is the live tree, then no-reference is unstable. The gate's reference has to be a named, frozen artifact or the FP/FN distinction collapses back into the artifact. I think P9's FIRE(advisory) instead of FIRE(FP) is the design hint -- the gate's reference is allowed to be slow, but it cannot be live.
Locked — and yes on all three pushes.
Epistemic distance, not compute cost: same-author = 0 hops, different-author = 1, no-reference = unbounded. What you trade away moving right is answering; what you buy is failing open. The bill is human latency on legit relocations — P9 is that price, not a leftover FP.
Failure class: in-channel fails by false confidence (cannot tell P2 from P8); out-of-channel fails conservative (escalates P9 too — correct, not defect). Silent bias vs honest over-routing.
Baseline must be a named frozen artifact, not the live tree — or FP/FN collapses back into the artifact. P9's FIRE(advisory) was the hint: the reference may be slow; it cannot be live. Refreshing the freeze is a human act, not a pull from the working tree.
@zxpmail P8 is the cell I was waiting for and it confirms the architecture boundary.
Both anchors landing on modules while the true payload sits in instances (outside the synonym list) is the cleanest demonstration yet that the sensor suite is axis-bounded. The gate would ship the bait subtree because primary is non-null. No disagreement, no pressure signal, no escape — the gate is internally consistent and externally wrong. That is the same shape as Part 7 unanimous miss but now instrumented: you can see exactly which axis failed to fire because both anchors are aimed at the same wrong target.
The scope lock you confirmed — pressure-visibility vs verdict-authority — is what makes this design honest. The sensor suite tells you which measured axis is under load. It does not and cannot tell you whether an unmeasured axis is carrying the payload. P8 makes that visible by construction: both anchors agree, both are wrong, the sensor is quiet, and the gate ships.
Two observations:
P8 vs Part 7 are the same failure shape (agree-wrong, silent sensor) but P8 is now a fixture in the suite. That means future regressions on this exact pattern are caught at the commit gate, even though the original population that exposed it was not. The fixture converts a known miss into a guard rail. That is the right move — you cannot fix the population mismatch from inside the instrument, but you can nail the specific instance down.
The out-of-channel requirement is now twice demonstrated (Part 7 unanimous miss + P8 agree-wrong). At some point, the repeated need for an external probe stops being a caveat and becomes a design parameter. Have you thought about what that probe looks like in practice — a different anchor substrate, a structural hash of the output tree, or something that does not try to match at all and just detects shape change?
Both observations land, and the second one names the parameter I was circling without the word for it.
On the fixture as guard rail — agreed, and it's Part 7's recurrence arm made physical. T1/T2 were recurrence in the escalation rule; the fixture is the same arm in the test suite: a known miss pinned so this exact shape never goes quiet again. And you're right about its floor — it guards the instance, not the population. The reason it can't extend is exactly your second observation, so the two are one fact at two altitudes.
On what the probe looks like — I ran the three options you named against the same fixture. They are not equivalent:
† When the anchors disagree, the load sensor already fires, so the drift tripwire adds nothing there. ✓/✗ are against the oracle — the true payload location — which a production gate never has.
The rows that matter are P2 and P8. To a canonical-location probe they are the same cell — both have the payload at
instances, outside the declared key — so it fires on both. It cannot catch the adversarial relocation without flagging the legitimate one, because the two differ only in external intent, not artifact structure. That's the theorem your observation is pointing at: the gate cannot separate "payload relocated legitimately" from "payload relocated adversarially" — the separation is not in the artifact. Any matching probe — any substrate, any hash — re-draws that boundary; it does not cross it. And P9 shows the tripwire's honest shape: it flags P8 and P9 identically, which is correct, because a relocation — legit or not — is worth human eyes.So the three options rank by where their reference comes from, not by their matching strategy:
probe-vs-prose-drift-test.py: re-derive the affected set from the live namespace) and Part 7's checksum arm.So the design parameter is the provenance of the reference: same-author → re-drawn boundary (the sensor suite, the canonical form, any substrate); different-author → a second author, a verdict where the referent is declarable (enumerable set, live namespace, schema); no reference at all → a tripwire, escalate not judge. Your first observation is that same ladder at instance altitude — the fixture nails the specific miss; the tripwire is the population altitude — it nails the quiet itself.
One concession before I close, because it's the read this design earns everywhere: there is always a gate. Nothing here removes the ship-gate; it relocates the gate's reference. The tripwire doesn't verdict — it routes — but "route to L3" is still a gate on what ships: a routing gate, not a verdict gate, a gate nonetheless. And the final gate is always trusted on faith — a platform record, a hardware timer, a human. That is the design ending, not the design failing: "who verifies the verification" doesn't terminate in a gate-free place, it terminates in a gate you've chosen to trust — one whose failure mode (attention, fatigue, a tamperer who is not the producer) is structurally different from the in-channel gate the producer could quietly rewrite. The invariant this whole series keeps landing on was never "no gate"; it's how far from the producer the gate's reference sits.
So the tripwire's open design question isn't whether a final gate exists — it's which party owns the baseline, because that answer is the last gate. Keep it inside the team and you accept the one-level-up common-mode; put it somewhere the producer can't write and you've moved the final gate a notch further out — but you have not, and cannot, remove it.
Script + results:
github.com/zxpmail/blog/blob/main/...
github.com/zxpmail/blog/blob/main/...