Frame-style and bleed-edge chips have zero rows: 145,419 votes are derivable from stored evidence with no image fetch

[WilfordGrimley]

What

Frame-style and bleed-edge attribute chips have zero CardTagVote rows, no substitute channel, and no wiring. The audit (PR #616) also measured that the votes are derivable from evidence already stored in the database, with no image fetch at all:

Chip	Derivable votes	Derivation from stored ImageEvidence
Modern Border	133,627	collector_line_collector_number non-empty
Old Border	9,006	illus_anchor_fired true, collector number empty
appropriate-bleed	2,786	bleed_class = "trimmed"
TOTAL	145,419

Cross-check: against ImageEvidence.artbox_frame_class the counts are 142,469 stored vs 142,633 derived. The 164-row gap is artbox_phash's own fetch failures, i.e. the derivation agrees with the independent classifier everywhere the classifier ran.

Why it matters

1. These chips are user-facing filter surfaces with nothing behind them. 145,419 votes' worth of signal is sitting in the DB unread.
2. Border-colour chips survived the same purge only by accident. Two separate identities compute border colour from the same classifier, so culling one left the other. Had that duplication been culled as redundancy, border colour would be at zero rows today too. The purge's selection criterion was not "is this signal available" — it was "does a second copy happen to exist". See OPS-CORR-0008 (identity-vs-channel purge).
3. The only code path that casts these votes is run_pilot (local_identify_printing_tags.py:1790 cast_frame_style_vote, :1807 cast_bleed_edge_vote). Their other caller, image_evidence.extract_card_evidence, has zero production callers — see Border-color vote parity: bulk/streaming extraction paths do not cast the inline Stage C vote #510.

What this needs — and what it must NOT be

It needs an evidence-reading caster, modelled on local_layout_class_cast: read ImageEvidence rows already in the DB, derive the chip, cast the vote.

It must not be the live-fetch pilot. Running run_pilot over the catalog to obtain these votes would re-fetch ~220,000 images to recompute facts that are already stored. That is the wrong instrument for this job.

This may be subsumed by the monolith: the owner's own scope statement includes "the pilot's relevant features", and carrying the pilot's chip casting into the monolith is precisely what re-wires these chips. If the monolith carries it, this issue closes as part of that work rather than as a separate backfill.

DECISION NEEDED (owner)

Authorise the chip re-derivation? It is a WRITE of 145,419 CardTagVote rows into the production database. Options:

• (a) Authorise a standalone evidence-reading caster + dry-run + poll, now.
• (b) Defer, and carry the pilot's chip casting into the monolith so the votes fall out of the first full run.
• (c) Neither — leave the chips at zero, with the consequence stated above.

Standing constraint: prod DB is read-only without an explicit poll.

What would close it

• A caster that reads stored evidence (no fetch) and casts frame_style and bleed_edge votes, with the uniqueness/ignore-conflicts guard the other calculators use;
• a dry-run whose would-cast counts reconcile against the 133,627 / 9,006 / 2,786 figures above;
• an owner-tapped write poll;
• non-zero row counts for all three chips afterwards.

LIVE vs LATENT

LIVE. The chips are at zero rows in production today.

Refs

• Established by the PR Audit: does the pipeline still catch what it aims to? The composition check #616 audit.
• Related: Border-color vote parity: bulk/streaming extraction paths do not cast the inline Stage C vote #510 (border-colour vote parity; extract_card_evidence has no production callers), layout_class (borderless/black/white/silver) is computed by Stage C but never cast as a Tag vote #369 (layout_class computed but never cast — same defect shape, closed), Make the calculator roster a checkable contract: declare which tables each calculator writes, then verify it produces rows #577.

[WilfordGrimley]

This shipped — PR #654 (2026-07-30), closing as already-fixed

Verified against current master (17345a48050cd6734f312d033b6ef1ed4f1af014) and a read-only production query, 2026-08-05.

The evidence-reading caster this issue asked for already exists. PR #654 added MPCAutofill/cardpicker/local_attribute_chip_cast.py, whose run_attribute_chip_cast() (local_attribute_chip_cast.py:254, verdict calculation at calculate_attribute_chip_verdict():143) reads stored ImageEvidence and casts frame/bleed votes with zero image fetches — exactly the "evidence-reading caster, modelled on local_layout_class_cast" this issue's "What this needs" section specified. It reuses local_fallback's FRAME_STYLE_TO_TAG, BLEED_EDGE_TAG_NAME and classify_frame_style() (still defined at local_fallback.py:494 and :477/:634 respectively), but casts under new identities: FRAME_STYLE_CAST_ANONYMOUS_ID = "frame-style-cast-v1", BLEED_EDGE_CAST_ANONYMOUS_ID = "bleed-edge-cast-v1" (local_attribute_chip_cast.py:91-92).

It's wired into the monolith's live execution path: stage_e_dispatch._run_attribute_chip_casters (stage_e_dispatch.py:1161-1220), called from _run_stage_d at stage_e_dispatch.py:1337, which is itself called from dispatch_micro_batch (:1620), called from run_pipeline._run_streaming_stages (:723), called from run_pipeline.handle() (:446). This is run_pipeline's normal path, not a side channel.

Production row counts (read-only Django shell query, 2026-08-05, against the currently-running full-catalog pass — see note on drift below):

Identity	Rows
frame-style-cast-v1	151,161
bleed-edge-cast-v1	2,786
layout-class-cast-v1 (border, for comparison)	228,914
local-fallback-v1 (the retired pilot identity)	0

Tag-level: Modern Border 141,800 · Old Border 9,361 · appropriate-bleed 2,786.

The zero-row illusion (this is the useful part)

This issue's "zero rows" premise was true only for the retired local-fallback-v1 identity — confirmed still at 0 rows above. The superseding caster writes under the two new identities listed above, so any audit that measured the old identity correctly reported zero while hundreds of thousands of real votes existed under different names next to it.

This is the standing ruling from #618 — "a zero-row channel is evidence we never ran it, not evidence it is unnecessary" — in a new form: a zero-row IDENTITY is not a zero-row CHANNEL. A superseding caster that writes under a new identity leaves the old identity at zero forever, permanently, by design; nothing about that zero says the channel (frame style, bleed edge) is dead. This distinction is now written up durably in docs/identification-pipeline.md (see the companion PR against #618).

Citation correction: this issue's citation of local_identify_printing_tags.py :1790/:1807 for cast_frame_style_vote/cast_bleed_edge_vote points at their call sites in that file (confirmed still there, local_identify_printing_tags.py:1995 and :2012 on current master — line numbers have drifted since this issue was filed, but the call sites remain, unchanged in kind). The function definitions are local_fallback.py:502 (cast_frame_style_vote) and local_fallback.py:682 (cast_bleed_edge_vote).

Predicted vs. actual counts

This issue predicted 133,627 / 9,006 / 2,786 (Modern Border / Old Border / appropriate-bleed). Actual: 141,800 / 9,362 / 2,786 (Old Border shown as 9,361 in the query above; both values observed across two read-only queries run seconds apart, consistent with the live full-catalog pass writing rows between reads — see PilotRunLedger run_id prefix stage-e-fullcat-b25-*, currently at 9,759+ rows and counting).

appropriate-bleed matched exactly (2,786 = 2,786). The border counts grew (133,627 → 141,800 Modern; 9,006 → 9,362 Old), most plausibly because evidence coverage increased in the time since the PR #616 audit that produced the prediction — flagging this as expected drift, not a discrepancy worth investigating further.

Closing as shipped.