What's That Card / question feed: alignment pass for deduction vote sources (artist + illustration)

[WilfordGrimley]

Context

Two new server-side deduction mechanisms are landing on the vote pipeline:

1. Artist deduction from collector codes (existing deductive-backfill-v1 votes, VoteSource.DEDUCTION).
2. Illustration deduction — a new Stage D calculator that will cast printing votes across all printings sharing a Scryfall illustration_id (full confidence when an artist+card has one illustration; spread at base/N when N illustrations exist). Backend work is phased separately (Phase 1: import illustration_id; Phase 2: calculator).

The question feed / What's That Card game (frontend/src/features/questionFeed/QuestionFeed.tsx, served by GET 2/questionFeed/ → MPCAutofill/cardpicker/question_feed.py) needs a pass to stay consistent with these sources.

Scope

• Question selection: the three-tier ranked union in question_feed.py does not consider deduction coverage. Review whether questions already answered by deduction should be deprioritized/annotated (see open decisions).
• ArtistVotePicker.tsx already supports confidentlyKnownArtistName — verify behavior when the artist is known via DEDUCTION votes rather than indexing.
• Level 2 candidate grid (identify_printing): printings sharing one illustration are visually near-identical. Once illustration_id is imported, consider grouping/annotating candidates by illustration so users aren't asked to distinguish the indistinguishable.
• QueueTagQuestion.tsx / attribute chips: confirm no assumptions break when votes arrive from DEDUCTION sources.
• General QA pass of the game surface (reveal flow, session pill, moderation tab) while in there.

Open decisions (owner)

• Should the feed stop asking questions the deductions already answer (behavior change: question-feed exclusion by illustration group — currently deferred in the backend plan), or only adjust presentation of deduction-sourced state?
• Intent of the game pass: illustration-group answer equivalence (two printings of the same illustration count as the same answer), vote-source display consistency, or general QA only?

Dependencies

Backend illustration work ships in two sequenced PRs. Presentation-only parts of this issue can start once DEDUCTION votes are visible in feed payloads; illustration grouping needs Phase 1 (illustration_id on CanonicalPrintingMetadata).

---

Owner decisions (2026-08-05 review)

Pointer only — this issue's content and state are unchanged.

This issue's remaining scope (question-feed selection considering deduction coverage, per its own "Open decisions" checklist above) is now being carried forward under epic #704 and #716 ("What's That: data-driven question-selection policy (expected information gain per question)", filed 2026-08-05). #716 records the concrete data-driven spec (expected information gain per unit of user effort, given what's already derivable from stored evidence, what the machine abstained on, and what a specific voter has already answered) that generalizes this issue's open deduction-coverage question. See #716 and #704 for the active tracking; no further action needed on this issue for that scope.

[WilfordGrimley]

Owner decisions (2026-07-28):

• Pass intent ratified: align the game with how a user will actually vote. When rejecting a specific printing (e.g. wrong border), the user can still tell us which illustration it is — the flow should capture illustration identity even on printing rejection, not discard it.
• Artist questions should never be needed once illustration identity is knowable (illustration → artist follows automatically). The only remaining artist flows: user adding a new artist, or reporting AI art.
• Show just the art when possible: there will be cases where showing the art crop (we already store art_crop_url on CanonicalPrintingMetadata) is enough to confirm something — no need to render the entire card.
• Scheduling: issue-board only for now; not scheduled for build.

[WilfordGrimley]

Owner-confirmed design (2026-07-28) — this issue is now the spec for the WTC illustration surface

Decision: group the existing identify_printing level-2 candidate grid by illustration. Do NOT add a new question type.

Rationale beyond size: picking an illustration group IS the illustration answer. Grouping natively produces exactly the fact CardIllustrationVote (#524) will store — a single illustration_id per (card, voter). When #524 lands the surface does not change at all; only the call inside the persistence seam gains a body. A separate question type would build a second way to ask the same question and then need reconciling.

It also improves the data, not only the ergonomics. Today a voter facing N near-identical printings either guesses — producing a full-weight human vote for a possibly wrong printing — or skips. Grouping lets them answer the answerable question and stops asking the unanswerable one, which is this issue's own stated motivation.

Semantics (must hold both before and after #524)

Voter picks illustration group G (illustration_id = X):

• G contains exactly 1 printing → cast the ordinary printing vote through the existing submit path, unchanged.
• G contains N > 1 printings → cast NOTHING on the printing channel. post_submit_printing_tag (views.py:1002) deletes all prior votes for (card, anonymous_id) before creating, so N submissions leave exactly one arbitrary survivor at full human weight. The endpoint cannot express "one of these N".
• Either way → derive a CardArtistVote: source=USER, the voter's own UUID as anonymous_id (so calculator_family() returns None = human), its own distinct vote_surface so the derivation stays auditable. Cast only if the voter has no existing CardArtistVote on that card; if they have one, leave it untouched. Whose vote wins on collision is Unify one-agent contradiction policy: latest-wins vs both-count vs withhold across per-card and group tallies #483 — open, broader than this surface, and deliberately not answered here.
• Either way → the illustration answer goes into a single persistence seam, which is a no-op until Human illustration answers have no vote model (CardIllustrationVote) #524 lands. Do not persist it by any other means: not as a Tag, not as printing votes. Both are lossy re-encodings that would have to be unwound.

Required edge case: illustration_id is NULLABLE

CanonicalPrintingMetadata.illustration_id is not populated for every printing — local_illustration.py:137 filters CanonicalCard.objects.filter(printing_metadata__illustration_id__isnull=False), which only makes sense because nulls exist.

Ungroupable printings must degrade to the current flat, ungrouped presentation alongside the grouped ones — never be dropped from the grid. A candidate silently vanishing because Scryfall has no illustration_id for it would be a correctness regression in the identify_printing question itself. An "ungrouped" bucket is the expected treatment. Requires a test with a mixed candidate set: some printings with illustration_id, some without.

Multi-artist abstain — resolved with a prod census, no further measurement needed

illustration_id -> artist is functional, which is what makes the derived artist vote sound. Combined credits break that dependency, and they are encoded in the artist name string, not as multiple rows (CanonicalCard.artist is a single FK; mtg.py:517 does artist_name = row.artist, taking Scryfall's string verbatim). A count-based test would never catch them.

Census over 2,523 CanonicalArtist rows:

pattern	rows	verdict
' & '	219 (8.7%)	the real combined-credit separator
', '	20 (19 without ' & ')	all false positives — Unfinity-style "age N" credits (Aliya, age 5½, Mark Rosewater, Age 53¾) and Jr./Inc. suffixes (Ken Meyer, Jr., Bad Flip Productions, Inc.)
' with '	1	false positive — Rebecca “Don't Mess with Me” Guay

Test on ' & ' ONLY. A comma test would falsely abstain on 19 legitimate single-artist records. Do not write a generic separator list — some combined credits contain both (Anthony S. Waters & Edward P. Beard, Jr.), so ' & ' must be checked first and independently.

Sequencing

Phase A (art-crop re-frame + external-ip tag rename) → Phase B (not-official-printing vs not-official-art negative split) → Phase C (this). Sequential, same files. C is additionally gated on #524 for persistence only; build the seam with an empty persistence call and do not wait for #524 to start once B lands.

[WilfordGrimley]

Amendment 2026-07-29 — derived-vote rule restated, and the phase split

The derived artist vote rule is EVIDENCE PRECEDENCE, not a #483 sidestep

The earlier spec above said: cast the derived CardArtistVote only if the voter has no existing artist vote on that card, "deliberately sidestepping #483".

That framing was imprecise and is superseded. Stated correctly:

A derived vote never overrides an explicit one.

The voter typed an artist name; they merely IMPLIED one by picking artwork. An implication must not overwrite a statement. The behaviour is unchanged — do not cast when an explicit artist vote already exists — but the REASON matters for anyone reading this later:

• It is not a contradiction policy, so it does not answer Unify one-agent contradiction policy: latest-wins vs both-count vs withhold across per-card and group tallies #483 by implication.
• It is forward-compatible with every Unify one-agent contradiction policy: latest-wins vs both-count vs withhold across per-card and group tallies #483 outcome, because withhold / latest-wins / both-count only engage once two votes of EQUAL STANDING coexist, and this rule prevents that state from arising.
• Whichever way Unify one-agent contradiction policy: latest-wins vs both-count vs withhold across per-card and group tallies #483 rules, this surface needs no revision.

See #483 for the full design conversation, including why "null both votes" (the withhold option) is attractive — it is already the group-level behaviour and would close #525's machine half — but is blocked for humans per-card by delete-then-create making the contradiction unrepresentable.

Split into C1 and C2

C1 — grouping and payload only. NO vote behaviour change. In flight.

• illustrationId added to PrintingCandidate as an OPTIONAL, NULLABLE field. It is cheap: serialise_as_printing_candidate already resolves the printing_metadata sidecar, and illustration_id sits on it. No migration, no new endpoint.
• Candidates sharing an illustrationId render as one group; nulls render in a flat ungrouped bucket and are NEVER dropped.
• Selecting a candidate submits exactly what it submits today, to the same endpoint. Grouping is done client-side from the payload.
• This alone delivers this issue's stated motivation — "so users aren't asked to distinguish the indistinguishable" — and is independently reviewable and mergeable.

C2 — vote semantics. Blocked on the transport decision below.

• G has 1 printing -> ordinary printing vote. G has N>1 -> nothing on the printing channel.
• Derived artist vote per the precedence rule above.
• Persistence seam, a no-op until Human illustration answers have no vote model (CardIllustrationVote) #524.

C2 open decision: where the "no explicit vote exists" check lives

The check is server-side knowledge, and the existing artist-vote submit endpoint does delete-then-create — calling it blindly OVERWRITES, which is precisely what the precedence rule forbids. Options:

1. Add an "only if absent" mode to the existing artist-vote endpoint. Small; scatters the illustration logic.
2. A dedicated endpoint for the illustration answer (recommended). Client sends ONE illustration id; the server derives the artist, checks for an existing explicit vote, and decides whether to write. Matches the stated contract that the client never sends a printing list, and gives Human illustration answers have no vote model (CardIllustrationVote) #524's persistence call a home so nothing moves when it lands.
3. Client-side skip driven by a payload flag. Smallest, but enforces a soundness rule in the browser — the same "enforced only by convention" gap that produced stage-d-illustration-v1 at N>1 casts N full-weight votes for mutually exclusive printings; the /N confidence spread never reaches the tally #525.