`evidence/ANALYSIS-2026-08-30.md`

144 lines
# TK-10896 — canonical dw_sku backlog: read-only analysis (2026-08-30)

**Agent:** codex-10896 · **Mode:** read-only, no canonical writes, no minting.
**Source:** Mac2 `dw_unified` mirror via local `/tmp` socket. **NOT canonical** —
Kamatera owns `shopify_products` (split-ownership doctrine). Re-run the scanner on
Kamatera for the authoritative number.

## ⭐ LEDGER-VERIFIED RESULT (supersedes the prefix-guard estimates below)

The reverted-Phase-4 undo ledger (11,725 rows, SHA-256-verified) was joined against
the mirror plan. Its prefix composition **exactly matches** the Phase-4 decision-aid
buckets (DWAG 5921 · DWPR 2899 · DWAX 1429 · DWKN 505 · DWHD 284 · DWTT 64 · DWRW 51 ·
DWCC 25 · DWJS 12 · DWRO 11) — near-conclusive that it is the genuine mint record.

**Decisive finding:** the ledger's Carnegie mints are `DWAG-100001..105921`, but the
current Carnegie blank `sku` values are `DWAG-376000..381921` — a *different range,
absent from the ledger*. So the `DWAG-376xxx` codes are **scraper-native** (self-copy
safe), NOT the reverted mints. The prefix-based greenfield guard was a safe-but-wrong
heuristic that over-blocked ~8k rows. With the verified ledger, **membership of the
exact code** is the sole provenance test.

**Ledger-authoritative segmentation (34,614 blank rows):**

| Path | Rows |
|---|---:|
| self-copy recoverable (DW 18,236 + proven-native 12,475 + source 3,026 + cork 25) | **33,762** |
| confirmed mint-residue → rescrape (in ledger) | **772** |
| bare → rescrape (no sku/mfr) | 65 |
| dedup (collisions → TK-10649) | 9 |
| staging-link | 6 |

True re-scrape need = **~837 rows**, not 8,962 (prefix guard) or 12,589 (memo). The 772
residue reconciles exactly with an independent raw-SQL count (`code IN ledger`), and the
join closes a 268-row gap (DWPR/DWHD residue the prefix buckets missed).

**Codex second-model check (2026-08-30):** confirmed "exact normalized-code membership is
the correct primary provenance test; prefix membership would wrongly condemn legitimate
scraper-native DWAG-376xxx" and the 33,762/772/65 split is "strongly supported" by the
exact 772-row reconciliation + bucket-perfect ledger counts. It flagged one concrete risk —
a *second* mint campaign outside this 11,725-row ledger (the reverted **Romo-491**,
`DWRO-30476..30966`). **Verified empty:** there are ZERO current blank Romo rows carrying
any `DWRO-` code, so that campaign does not intersect the backlog. (The ledger's 11 `DWRO`
entries are the Bucket-A "Romo 11" mint, distinct from the 491.) Other codex-noted guards —
Unicode-dash / case / whitespace normalization — are handled (join upper-cases + trims +
strips unit suffixes); a duplicate-in-ledger guard already fails closed.

**Chain-of-custody caveat (Steve to confirm):** the ledger FILE (`/tmp/TK-10896-phase4-
ledger.jsonl`) is integrity-verified (SHA-256 + row-count + no-dups) and internally
conclusive, but I could not tie it to the canonical Kamatera `sku_repair_p4_20260826`
table from here (prod read blocked). Before any gated apply, confirm it is the authorized
export. It is NOT committed to this repo (unconfirmed provenance); the join is reproducible.

---

## Method

`dwsku-backlog-scan.mjs` runs the deterministic classifier (`classify.mjs`) over
every ACTIVE product with a blank `dw_sku`. The classifier only ever proposes a
candidate `dw_sku` that is **already present on the row** (recovered from `sku` by
pure unit-suffix stripping) — it can never fabricate/mint one. A **provenance guard**
additionally blocks self-copy of reverted Phase-4 mint residue (see below). 24 unit
tests cover the strip rule, collision detection, the no-mint invariant, and the guard.

## Headline segmentation (Mac2 mirror, ~34,600 active-blank rows; live table, counts drift ±)

| Recovery group | Rows | Route |
|---|---:|---|
| recoverable_now_self_copy | 21,555 | self-copy the existing code from `sku` |
| rescrape_program (TK-10900) | 8,962 | 8,897 mint-residue + 65 truly bare |
| **provenance_review (TK-10896) — HELD** | 4,082 | mixed-use Phase-4 prefix; fail-closed pending undo ledger |
| dedup_gated (TK-10649) | 9 | candidate collides w/ a live active code |
| recoverable_now_staging_link | 6 | link `mfr_sku` → vendor `*_catalog.dw_sku` |

By class: `SELF_COPY_DW` 18,504 · `MINT_RESIDUE_RESCRAPE` 8,897 · `PROVENANCE_REVIEW`
4,082 · `SELF_COPY_SOURCE` 3,026 · `RESCRAPE` 65 · `SELF_COPY_CORK` 25 · `STAGING_LINK`
6 · `SELF_COPY_COLLISION` 6 · `SELF_COPY_DW_COLLISION` 3.

**Steve's rulings folded in (2026-08-30):** (1) Kamatera canonical scan = Steve runs /
authorizes SSH; mirror is advisory. (2) Bucket-A mixed-use prefixes (DWKN/DWTT/DWRW/
DWJS/DWRO/DWCC) **HELD** — the classifier now fails them closed into `PROVENANCE_REVIEW`
(never self-copy, never re-scrape) until the exact reverted-mint undo ledger disambiguates.
`provenance-ledger-join.mjs` is the fail-closed harness that will consume that ledger
(requires a completeness manifest + row-count + SHA-256 before releasing any mixed-prefix
row to `SELF_COPY_DW_PROVEN_NATIVE`). (3) Next read-only step = source the reverted-mint ledger.

## The provenance guard — why 8,897 rows are NOT self-copy-eligible

A first pass (no guard) reported 34,520/34,600 self-copy-recoverable and only 65
needing re-scrape — seemingly contradicting the scope memo's 12,589-rescrape /
Carnegie-5,921 projection. **That was wrong, and here is the verified reason:**

The ticket event log + the `sku-integrity-phase2-phase4` decision aid confirm the
reverted **Phase-4 mint** allocated codes into **"greenfield" vendor prefixes that
had ZERO coded products beforehand** — Carnegie `DWAG-`, Maharam `DWAX-`, CMO Paris
`DWCX-`, Stout `DWST-`, Scalamandre `DWSC-`, Designtex `DWDX-`, Wolf Gordon `DWWG-`.
Steve reverted the 11,725 mints ("rolled back to blank"), but on the **Mac2 mirror**
the minted code persists in `sku`/`variant_sku`. So those `sku` values are **mint
residue, not scraper-native codes** — self-copying them would silently re-instate the
exact numbers Steve reverted (a "never mint" violation). The guard routes any
greenfield-prefix code to `MINT_RESIDUE_RESCRAPE` (→ recover the real mfr code by
re-scrape), never self-copy.

Mint-residue by vendor: Carnegie 5,921 · Maharam 1,429 · Wolf Gordon 419 ·
Scalamandre 418(+22) · CMO Paris 344 · Stout 180 · Designtex 164.

This also **reconciles the mirror-vs-canonical drift**: on canonical Kamatera the
revert cleared these codes → they read as bare/rescrape (matching the memo's 12,589);
the Mac2 mirror still shows the residue in `sku`. The mirror is drifted in this
specific way, and the guard makes the classifier robust to it either way.

## What is safe to conclude now
- Classifier + strip rule are correct and reproducible (24 tests green; validated on
  real sku shapes incl. `-Sample`, `-Yard`, `-Per Yard`, doubled `-Sample-Sample`,
  and non-numeric Elitis `DWEL-RM-…` cores).
- Nothing was written to any database. No code was minted. Within-batch: 1,276
  candidate groups (2,552 rows) share a code, but ALL are **same-pattern** (identical
  title+handle: a pattern's sellable row + its `-Sample` row) → they *correctly* share
  one canonical dw_sku. **True cross-product within-batch collisions = 0** (distinct-
  title groups = 0). `dw_sku` is intentionally non-unique per pattern; a downstream
  apply MUST upsert, not assume per-row uniqueness (scanner reports this under
  `within_batch_shared_candidates`).
- The 9 collisions match the memo's Phase-2 dedup class (Novasuede `DWCC-*-Per Yard`,
  Arte `DWKE-41415-Sample-Sample`) → TK-10649.
- The re-scrape program is real (8,962 rows), dominated by Carnegie 5,921 — vindicating
  the original scope memo, not the naive 65-row figure.

## Residual open items (gated / out of this read-only scope)
1. **Kamatera canonical run** — `DWSKU_PSQL='ssh <kam> psql' node dwsku-backlog-scan.mjs`
   for the authoritative segmentation (the guard means the mirror and canonical should
   now agree on routing even where `sku` residue differs).
2. **Bucket A/C disambiguation (Cody-flagged, quantified)** — greenfield (Bucket B) is
   unambiguous and guarded. Bucket-A prefixes were ALSO in scraper use, so a blank row
   carrying one is *usually* scraper-native — but the Phase-4 decision aid shows ~668
   rows were minted into Bucket A (Knoll 505, Thibaut 64, RebelWalls 51, JS 12, Romo 11,
   Nova 25) + the Romo `DWRO-30476..30966` reverted range. There are **4,084 blank rows
   currently in Bucket-A prefixes** (DWJS 1,689, DWTT 1,517, DWKN 622, DWRW 203, DWCC 53);
   at most ~668 of those could be mint residue, but WHICH ones needs the exact reverted-
   mint number list to separate scraper-native from mint. **Until that ledger is sourced,
   do NOT apply the Bucket-A self-copy subset** — treat those 4,084 as "verify against
   mint ledger first." (Guarding all 4,084 outright would wrongly quarantine ~3,400
   legitimate scraper-native rows, so this is a caveat + a per-vendor pre-apply check,
   not a hard block.) Sourcing the mint ledger is the recommended next read-only step.
3. Any `dw_sku` write is canonical + customer-facing → gated, per-vendor batch, ledgered.