Repository navigation
Two consecutive non-passing plan quorums on a must-carry ticket must escalate automatically — #3452 sat through four #3562
Description
Process defect, measured on the 0.69 critical path. #3452 (the PP-QUANT-001 M1 plan) has been through four plan-quorum rounds — 0/3, 1/3, 1/3, 1/3 — and is still "awaiting a ruling". The operator's rule on #3421 is no code before 3/3, so the must-carry lane (#3452 → #3420 → #3430 → #3447 → #3446) has been idle the whole time, and 06x-release-schedule.md §1.1a makes slice M the row T-0 waits for. The train cannot cut, and nothing in the rest of the milestone changes that.
Four rounds is three rounds of information and one round of hope. A quorum that has not converged twice is telling you the plan needs a decision, not another vote — and re-running it is cheaper than escalating, which is exactly why it keeps happening.
Ask: after two consecutive non-passing plan quorums on a ticket that is §1.5 must-carry (or has an andon raised against it), the harness escalates automatically — raises the ruling to the operator with the disputed points named, and stops spending quorum rounds.
Acceptance:
- A fixture ticket with two recorded non-passing rounds produces an escalation artifact naming the unresolved decision; a third round on it is refused.
- A fixture with one non-passing round does not escalate (the rule must discriminate, not just fire).
- The escalation names what the lanes did not dispute, so the ruling is scoped to the actual fork. PMAT-3430: M1 plan + quorum history (0/3, 1/3, 1/3, 1/3) — draft, no code, awaiting a ruling #3452 is the worked example: target, home crate (
aprender-quant, derived fromcargo metadata), Table E after v1 and X1 ordering were undisputed in all four rounds — the ruling needed is narrower than the plan.
Related finding that should not be lost with the ruling: #3452's re-runs surfaced two facts independent of the decision — core's GgufTensor::byte_size sizes Q4_1 at 18 bytes/block where upstream is 20, and Q8_1 is 36 by ggml's C static_assert but 40 in gguf-py at the pinned sha, so #3430's falsifier cannot be met as worded. A ticket whose falsifier is unsatisfiable is not blocked on a quorum; it is blocked on a re-worded falsifier. That is part of the ruling.
Activity
noahgift commentedon Sep 20, 2026
Refinement, measured: the rule as written would escalate on transport flake
This issue proposes escalating after two consecutive non-passing plan quorums. Live data from #3581's AD-04 quorum shows the rule needs a discriminator, or it will fire on the wrong thing:
UNAVAILABLE (503)while carrying PASS text — correctly not countedstatus=SUCCESSNo lane has returned FAIL or named a single finding in any round. Three rounds lost, zero of them to the diff.
Under this issue's rule as written, that would have escalated to the operator after round 2 — presenting a transport problem as a design dispute, and asking for a ruling on a plan nobody has objected to. That is the inverse of #3452, where four rounds did carry a real objection and no escalation came.
So the discriminator is the verdict's kind, not the round count:
Fail/ a named finding — counts toward escalation. Two of these means the plan is disputed and needs a ruling.Unknown{LaneUnavailable},Unknown{NoVerdictObject},Unknown{LaneTimeout}— does not count. It is a re-run, and it should be visible as one, not laundered into either a pass or a dispute.This is doctrine 4 (three-valued verdicts) applied to the quorum itself: a lane that crashed, timed out, or answered with no verdict object did not vote. Counting a non-vote as a non-pass is the same error as counting it as a pass — both read a silence as information.
Two further asks that fall out of the measurement:
status=SUCCESSwith no verdict object is its own failure mode and should be named — a successful exit with nothing to say is exactly the "crash rendered as silence" class (claude --json-schemataking a path, the arbiter lanes at 0/3), and it is whySchemaInvalid-style named refusals matter here too.Refs #3080, #3452, #3581
noahgift commentedon Sep 20, 2026
Addendum (operator): two of the three round failures are parser defects, not transport
The discriminator holds —
Unknown{...}is not a vote, onlyFailwith a named finding counts toward escalation. But the classification of the three lost rounds needs correcting, and it sharpens what the lane must fix:UNAVAILABLE (503)while carrying PASS textPASSout of a 503 body. The transport failed honestly; the lane string-matched a verdict out of an error pagestatus=SUCCESSwith no verdict objectUnknown{LaneTimeout}, correctlySo the lane must parse an object, or refuse.
Unknown{NoVerdictObject}is the verdict when the payload is not a verdict object — never a substring search forPASSorFAILin whatever text arrived.This is the
"LANDED" in cell.upper()defect again (#3573 /spec_conformance.py:803): a substring test standing in for a parse. There it made the §12 andon clear on the word rather than the work; here it would have counted a 503 error page as a passing vote. Same mechanism, different blast radius — and the second one decides whether code merges.Added to the asks:
Unknown{NoVerdictObject}, never string-matched;PASSmust produceUnknown, never a vote. That control is cheap and it is exactly the case that occurred.PMAT-3430: quorum verdict 3/3 on 9bbcaa4 (AD-04)
PMAT-3430 Phases 3-4: quorum verdict 3/3 on 5420b7e (AD-04)
noahgift commentedon Sep 25, 2026
Parked by APR-EPIC-001: over E1 budget (rank 18/93). Reopen = pull. Applied by aprender-d1: claude+agy both said close, apr shadow row recorded (handoff/close-quorum-2026-09-25.json).
PMAT-3430 M1: one ggml tensor-type table, extracted from upstream rat…
PMAT-3430 Phases 3-4: three ggml enums become one (M1 complete) (paim…