2016-17 Prizm

• G-001 SINGLE-SOURCE TIER, AND A DISAGREEMENT IN COUNTS. tcdb's Inserts.cfm Parallel Sets section heading reads "Parallel Sets (14)" and lists 14 rows including "Fifth Anniversary Mojo" at sid 276315, whose own page heading is "2016-17 Panini Prizm - Fifth Anniversary Mojo" with "Total Cards: 300" and SN25 on all 170 rows read. cardboardconnection's base-parallel list carries 13 tiers and does NOT include it - it lists "Fifth Anniversary #/5" only. The sid is also a far outlier (276315 against 140534 and 140666-140685 for every other tier), consistent with a late tcdb addition. The row is written from tcdb alone at source_confidence=single. Not resolved: whether this is a real fifteenth base tier, a later-recognised variant, or a tcdb duplicate of another tier. https://www.tcdb.com/Inserts.cfm/sid/135667/2016-17-Panini-Prizm ; https://www.tcdb.com/Checklist.cfm/sid/276315/2016-17-Panini-Prizm-Fifth-Anniversary-Mojo ; https://www.cardboardconnection.com/2016-17-panini-prizm-basketball-cards
• G-002 print_run=unnumbered on these four rests on a WITHIN-RENDERER positive discriminative test, not on a source statement. Checklist.cfm emits a serial token on every rendered row of the other ten base tiers and no token on any rendered row of these four, and a second differently-varied fetch (ViewSet.cfm under a different slug) agrees on all four per CAV-042. cardboardconnection lists all four by name and prints no figure beside them, which is an OMISSION and not a statement of fact (EXTRACTION_SPEC 2.1) - so source_confidence is single, not multi, on the unnumbered claim even though both sources carry the tier. A source stating in words that these cards carry no serial number was not found.
• G-003 THE ENUMERATION IS NOT COMPLETE TO EVERY ROW AND THE DENOMINATORS ARE STATED RATHER THAN HIDDEN. Each 300-card base tier was probed on Checklist.cfm PageIndex 1, 2 and 3, which between them rendered: Black 141, Blue Wave 160, Fifth Anniversary Mojo 170, Fifth Anniversary Prizms 137, Gold 170, Green 150, Mojo 160, Orange 140, Orange Wave 154, Purple 185, Ruby Wave 150, Silver 150, Starburst 137, Teal Wave 167 - of 300 rows each. Every tier returned exactly ONE distinct token (or none) across all three number blocks 1-100, 101-200 and 201-300, so 0 of 14 are per-card variable on the rows read; a token confined entirely to the 110-160 unread rows of a tier cannot be excluded. CAV-046's number-span tell fired repeatedly: e.g. Silver page 1 rendered 50 rows spanning card numbers 1-70, Green page 3 rendered 30 rows spanning 201-270 - interior rows dropped, not tail cuts.
• G-004 CONTRADICTION FOUND AND RESOLVED AGAINST THE PAGE'S OWN COLUMN. The parent's Inserts.cfm renders one Notes column across two sections and the two sections mean different things. Its Parallel Sets section is the textbook Prizm shape - 10 annotated, 4 blank, both directions confirmed by row-level probe. Its Insert Sets section is worthless: the Blue Wave, Mojo, Orange Wave and Purple tiers of Explosion, First Step, Go Hard Or Go Home and Sky's The Limit (16 rows) plus Rookie Jerseys Orange Wave and Veteran Signatures Blue Prizms all carry a BLANK or non-serial Notes cell and are PROVABLY serial numbered on their own pages (SN99, SN25, SN25, SN75, MEM+SN25, AU+SN49). Veteran Signatures Blue Prizms' cell contains the bare token "AU", which is a flag token, not a serial statement. Parsing that column would have written unnumbered on eighteen provably numbered tiers. Every print run in this release came from a per-sid row-level sweep instead. This reproduces the Donruss per-section finding recorded in CAV-036 on a new line and a new season.
• G-005 Only one row in the release carries a sourced channel: Teal Wave Prizms (base-set), from tcdb's Inserts.cfm Notes cell "Serial numbered to 25. Retail exclusive.", re-read character for character on a second differently-slugged fetch. cardboardconnection's product page carries no channel-exclusivity sentence anywhere - asked directly, twice, on two differently-parameterised fetches. The statement was deliberately NOT inherited onto the Teal Wave tiers of the five insert sets, whose own Notes cells read "Serial numbered to 25" with no channel clause. channel_basis is empty on every UNKNOWN row per EXTRACTION_SPEC 2.3.
• G-006 NO FLOOR IS CLAIMED AND NONE SHOULD BE INFERRED. The 2016-17 scope memo section 3 records 2015-16 Panini Prizm at tcdb sid 118884 and 2014-15 Panini Prizm at sid 99820 in tcdb's own season indexes, so the Prizm line runs at least two seasons below this one. Nothing about depth below 2014-15 was investigated and the STUDIO LESSON (memo 3b) says absence from adjacent indexes would not settle it anyway. Incidental finding only, not chased.
• G-007 https://www.tcdb.com/Errors.cfm/sid/135667/2016-17-Panini-Prizm renders "No errors or variations have been added for this set yet." Per CAV-020 that sentence is returned identically on sets that provably DO have errata, so NOTHING is concluded from it here. What does survive independently: the 300-row base enumeration is contiguous 1-300 with no duplicate number and no b-suffixed row on any of the seven Checklist.cfm and Gallery.cfm pages that built it, and ?PageIndex=4 renders zero rows. Whether a photo/base-variation layer exists for this release is UNRESOLVED, not disproved.
• G-008 COUNT AND NUMBERING RECONCILE BUT THE SHAPE IS UNUSUAL AND IS RECORDED RATHER THAN SMOOTHED. tcdb states "Total Cards: 97" and the rendered numbering runs from 2 to 100 - card 1 is rendered by neither Checklist.cfm nor Gallery.cfm on the base sid or on either of its unnumbered parallels, card 81 is absent, and card 82 is a SECOND Brandon Ingram row (Ingram is also card 2). 99 slots minus 2 unrendered = 97, which reconciles the header exactly, but the identity of the missing numbers is not sourced. The card-level question belongs to the CHASE_CHECKLIST_SPEC pass. https://www.tcdb.com/Checklist.cfm/sid/140530/2016-17-Panini-Prizm-Rookie-Jerseys?sort=0
• G-009 base_print_run=unnumbered with basis=assumed, NOT sourced. The evidence is strong and indirect: Checklist.cfm renders SN1/SN5/SN10/SN25/SN49/SN75/SN99 on ten of the fourteen base-parallel sids and renders NO serial token on any of the 300 base rows across PageIndex 1-3 plus seven Gallery pages. Per EXTRACTION_SPEC 2.1 that is exactly the case the spec names as assumed - a source stating in words that the base cards carry no serial number was not found on tcdb or cardboardconnection.
• G-010 tcdb renders the Rookie Signatures hyper tier "Rookie Signatures Prizms Hyper" and the Veteran Signatures one "Veteran Signatures Hyper Prizms" - the same finish under two word orders inside one parent page. Both are written as the source prints them rather than normalised to one form (CLAUDE.md prohibition 3), and both are cross-flagged in ambiguous_with. A resolver matching on name alone will not join them.
• G-011 DERIVED VALUE THAT LOOKS WRONG, WRITTEN ANYWAY BECAUSE THE RULE IS ITS OWN PROVENANCE (CAV-019 second series, CAV-039). family_of() from pipeline/fix_schema.py was AST-lifted and applied unmodified. It returns Prizm (plain) for the base tier "Black Prizms" and other for the set-scope tier "Black" of the same colour in the same release, because the ordered FAMILIES list has a Prizm pattern and no Black, Gold, Green, Orange, Purple or Silver pattern. 22 rows land on other for that reason. NO entry was added to fix_schema.py. A corpus-wide check of the kind CAV-019 demands was not run, because no new pattern is proposed - this is the existing rule's output, not a defect in it.
• G-012 PROBABLE FLAG-COLUMN DROP, RECORDED RATHER THAN WRITTEN AROUND. https://www.tcdb.com/Checklist.cfm/sid/140687/2016-17-Panini-Prizm-Veteran-Signatures-Hyper-Prizms renders row 1 as "1 Kevin Durant SN10 Golden State Warriors" with no AU token, while its sibling Blue Prizms tier renders "1 Kevin Durant AU, SN49 Golden State Warriors" and the base Veteran Signatures set renders AU on all 46 rows. Per CAV-042 an absent token is evidence of nothing; no claim about signing is written off this row, and print_run=10 rests on the SN10 token that IS rendered.
• G-013 NOT ATTEMPTED. Every print run and every set count in this release rests on tcdb plus, for the base ladder and the nine set counts, cardboardconnection. No eBay, goldin, comc or pristineauction listing was fetched for any tier. 2016-17 is the Simmons/Ingram/Hield/Brown rookie year and the raw material exists; the 2016-17 scope memo section 9 records that marketplace corroboration has not been tested once on this season, so this release does not change that.
• G-014 ONE EDITORIAL LINEAGE ONLY. cardboardconnection is the sole non-tcdb source used. checklistcenter, checklistinsider, sportscardchecklist and waxstat were not swept; per CAV-037 a constructed checklistcenter URL that 404s is evidence of nothing, so none was constructed. Beckett is confirmed 302ing to a maintenance page (CAV-033) and was not budgeted for. blog.paniniamerica.net has a first-look post for Prizm per the scope memo section 7.6 and was NOT opened by this build. Where this release says multi it means tcdb plus cardboardconnection, and no independence test was run between them on this product.
• G-015 The 2017-18 Prizm parent https://www.tcdb.com/Inserts.cfm/sid/157371/2017-18-Panini-Prizm was asked directly whether any row has a name beginning "2016-17" or containing "Update": answer No, over sections headed "Insert Sets (50)" and "Parallel Sets (25)". So no 2016-17 Prizm Update block is filed under the next season's parent. Recorded because the 2016-17 scope memo section 9 lists this check as never having been run on this season. Equally, this parent's own Inserts.cfm carries NO prior-season or foreign-product rows - all 88 listed rows are named "2016-17 Panini Prizm - ..." - unlike 2016-17 National Treasures, which carries 68 of them.
• G-016 93 of its 100 rows were read (Checklist.cfm rows 1-73, Gallery.cfm PageIndex 9 and 10 for 81-100). Cards 74-80 were not rendered by any fetch made. All 93 read rows carry AU, SN25 and nothing else. Also recorded as a method finding: on the sibling Autographs Black sid, ?sort=0 returned 76 rows where the default sort returned 83 - CAV-046's statement that ?sort=0 is not a dependable remedy, reproduced on this release.

If you know a source that answers one of these, tell us — name the question's label and where to look.