Only 1 of 21 vote channels is reachable from the pooled runner, and it casts no votes: the full run's Stage D route is NOT ESTABLISHED

[WilfordGrimley]

What

The pipeline coverage composition audit (PR #616, docs-only) established that only 1 of the 21 vote channels is reachable from the pooled cohort runner, and that one channel casts no votes.

run_image_evidence_cohort — the runner the monolith is being built on — is Stage-C-only. It extracts evidence. It does not invoke any calculator. The other 20 channels are reachable only from local_calculate_verdicts (Stage D), from local_identify_printing_tags.run_pilot, or from the Stage E streaming conveyor (stage_e_dispatch).

Why it matters

The stated plan is: measurability first, then stand up the monolith (Stage 0 + pilot's relevant features + Stage C + D + E + fidelity gates), see what falls out. If the monolith's spine is the pooled runner, then on a full run Stage D reaches the catalog by one of two routes and it has not been established which one the planned run uses:

• (a) The pooled → conveyor post_save echo. Production has STAGE_E_STREAMING_ENABLED = True (master's default is False). If Stage D arrives only via that echo, the run's calculator coverage is whatever the streaming conveyor casts — and per Streaming Stage D casts only the 4 printing-identity calculators; evidence-derived tag/artist votes go stale after a re-extraction pass #530 the streaming Stage D casts only the 4 printing-identity calculators, so evidence-derived tag and artist votes would not be recast at all.
• (b) An explicit local_calculate_verdicts invocation as a second phase of the run.

These two produce materially different vote coverage for the same input cohort. The difference is not a performance detail; it decides which of the 21 channels produce rows.

THIS MUST BE ANSWERED BEFORE ANY FULL RUN

A run executed without knowing which route Stage D takes produces a reading that cannot be interpreted: a zero-row channel afterwards would be indistinguishable between "the channel is broken" and "the run never invoked it". That destroys the value of the first monolith reading, which is the entire point of the sequence.

Note the standing ruling: a zero-row channel is evidence we never ran it, not evidence it is unnecessary. Nothing is culled without a positive reason. This issue exists so the run's own topology is known in advance, not reconstructed from the wreckage.

What would close it

1. A written statement — in docs/identification-pipeline.md or the monolith's run doc — of the exact Stage D invocation route the full run uses, with the file/line of the call.
2. If route (a): an explicit note that streaming Stage D covers only the 4 printing-identity calculators (Streaming Stage D casts only the 4 printing-identity calculators; evidence-derived tag/artist votes go stale after a re-extraction pass #530), and a decision on whether that is acceptable for the first reading.
3. If route (b): the sequence and the flags, in the runbook.
4. Ideally, the per-channel measurability harness (priority-1 work item, filed separately) reports the invocation route per run so this is self-evidencing rather than documented-once.

LIVE vs LATENT

LIVE as a planning defect — it blocks the next full run. It is not a production bug: production is currently ~14 merges behind master and no full run has been executed.

Refs

• Established by the PR Audit: does the pipeline still catch what it aims to? The composition check #616 audit.
• Related: Streaming Stage D casts only the 4 printing-identity calculators; evidence-derived tag/artist votes go stale after a re-extraction pass #530 (streaming Stage D casts only 4 calculators), Make the calculator roster a checkable contract: declare which tables each calculator writes, then verify it produces rows #577 (calculator roster as a checkable contract).

[WilfordGrimley]

Owner ruling, 2026-07-30 — this issue's open question is answered, and the framing was wrong.

"i don't understand issue 4, but everything in the conveyor should be running in the monolith. 1click."

The question this issue left open was whether a full run reaches Stage D via the pooled runner's post_save echo into the conveyor, or by invoking local_calculate_verdicts explicitly. That is a false choice. It assumed the monolith would be assembled out of the two existing engines and would therefore have to pick one's dispatch semantics.

The monolith invokes everything itself, in one command. There is no echo to rely on and no ambiguity to resolve: Stage 0 → the pilot's carried features → Stage C → Stage D → Stage E's envelope and gates, all explicit, all in one run. "1 click."

What that changes about the finding above: the measured fact stands — run_image_evidence_cohort reaches exactly one channel (evidence-transfer-v1) and it writes no votes, so the pooled runner is Stage-C-only. That is still the gap. But the fix is not "wire the pooled runner to Stage D"; it is "the monolith calls Stage D directly", which also removes the post_save echo as a load-bearing mechanism rather than leaving it as an implicit dependency.

The requirement this settles into: everything reachable from the conveyor today must be reachable from the monolith. That includes the attribute-chip casters wired by PR #654, local_layout_class_cast, and every Stage D calculator. channel_report (PR #646) is how we verify it rather than assume it — a channel the conveyor could reach and the monolith cannot will show as silent.

Related: #628/#646 (per-channel report), #645 (run-scoped Stage C), #654 (chip casters), #651 (optional per-source scope), #658 (bleed_diff_mm as a monolith line item).

[WilfordGrimley]

Ruling rehomed, corrections to this issue's premises

The standing zero-row ruling this issue quotes ("a zero-row channel is evidence we never ran it, not evidence it is unnecessary. Nothing is culled without a positive reason") is proposed for rehoming into docs/identification-pipeline.md's new "Reading a zero-row channel" section, with two corollaries, in #720. This issue closes once #720 merges, not before — until then the ruling exists only here.

Three of this issue's premises no longer hold and are corrected below, each verified directly rather than relayed:

"No full run has been executed" — FALSE. PilotRunLedger has 9,757 rows with run_id prefixed stage-e-fullcat-b25-, all status=completed, most recently 2026-08-05 22:39:11 UTC. Full-catalog streaming passes have run.

"21 vote channels" — now 28. The 21 figure comes from docs/reports/2026-07-29-pipeline-coverage-composition-audit.md, which predates PR #654 by a day. Verified today via cardpicker.channel_roster.derive_roster() — a pure AST scan (only ast/pathlib/dataclasses/typing, no Django import, no DB query; this is not a pipeline run) — which returns exactly 28 vote channels (len(roster.vote) == 28) as of current master.

The Stage D route is now established, and it's neither option this issue poses. Traced directly in code:

run_pipeline.Command.handle()
  → _run_streaming_stages()          (management/commands/run_pipeline.py:645)
    → stage_e_dispatch.dispatch_micro_batch()   (stage_e_dispatch.py:1448), called synchronously per chunk
      → _run_stage_d()               (stage_e_dispatch.py:1223)
      → _run_attribute_chip_casters()  (stage_e_dispatch.py:1161)

Not (a) the pooled→conveyor post_save echo, and not a bare (b) — it's run_pipeline calling the streaming dispatcher directly, in-process, per micro-batch, as its own documented sequencing (run_pipeline.py's own module comment: "STAGE C: run_stage_e_streaming... STAGE D: join-key -> fallback -> illustration -> slow-path, then the border / frame / bleed chips"). Not a bulk local_calculate_verdicts call either — that command is a separate, standalone invocation this route doesn't use.

The #530 cross-ref is stale. #530 says "streaming Stage D casts only the 4 printing-identity calculators." Verified against current code: _run_stage_d calls the 4 printing calculators (join-key, fallback, illustration, slow-path-routing), and _run_attribute_chip_casters (added 2026-07-30, closing the 2026-07-29 audit's §1 Q1 items) additionally calls run_layout_class_cast and run_attribute_chip_cast — 6 call sites now, reaching 10 of the 28 vote channels in one full pass:

• stage-d-join-key-v1 (CardPrintingTag)
• stage-d-fallback-v1 (CardPrintingTag)
• stage-d-illustration-v2 (CardPrintingTag)
• stage-d-illustration-v2 (CardIllustrationVote — same identity, different vote model, a distinct channel)
• layout-class-cast-v1 × 4 tag-grained channels (Black Border, Borderless, Silver Border, White Border)
• frame-style-cast-v1
• bleed-edge-cast-v1

The other 18 channels (ai-art-detector-v1, the artist/residual/harvest/lands calculators, local-fallback-v1's now-superseded tag declarations, art-edge-continuity-v1, etc.) are reachable only from their own standalone management commands, not from a full run_pipeline pass. A zero on any of those 18 after a full run is exactly this issue's own point: evidence the command wasn't invoked, not evidence the channel is broken.