Red5Sorcery / Data Sculptor

WASM-002 adversarial QA review — Pass 3 erratum gate check

Short gate check of the Pass 3 erratum (P3-01, P3-02), Tuesday 29 September 2026. Findings only; no requirement text has been changed.

Review identity

Audited artifact	`WASM002_Pass2_Reconciliation_Pass3_Erratum_20260929.html`, SHA-256 `F5C2D819C2C88FF8B231B576F1C624BB7C712EBF4F35A79E26F2043408C7EE93`, 79,485 bytes. It matches the supplied sidecar and the hash in T's message.
Source review	Pass 3, SHA-256 `0598550B83CFB3AD37E6D810D95B58A998F0CE4D273EC5E9E91E809F51FC3461`, correctly cited by the erratum and its sidecar
Record integrity	The erratum is append-only. A text diff against the previous Pass 2 log (F564FFC2…E45603) shows only the new section 10 added, with no earlier text changed.
Baseline contract	Revision BL, SHA-256 `828C6A81B2C0A8B97546F728628059C53CC61256FAB23B142E452A8E566E025F`, unchanged
Scope	Whether P3-01 and P3-02 are resolved, and whether the erratum introduces a new blocking contradiction with the six gate decisions, Revision BL or the Pass 1 decisions they rely on. The other Pass 3 findings (P3-03 to P3-10) were not re-audited.

Wording boundary. Nothing here describes WASM-002, Revision BL or any successor PRD as approved, frozen, implemented, built, accepted or ready for implementation. Revision BL is not reported as corrected. The favourable gate below means only that the reconciliation decisions are coherent enough to integrate into a successor PRD revision.

1. The two gate blockers

P3-01Pass 3: BLOCKINGRESOLVED

The optional MAP clause is restored to MATERIALIZE

Evidence

E §10.1 restores MAP "<filename>" with cardinality 0..1, placed immediately after SOURCE and before KEEP. The named MAP may be current or historical but must be structurally valid and belong to exactly one lineage. SOURCE must equal the lineage's common source_filename, or the run refuses.
E When MAP is absent, P2-01 routing applies unchanged (zero / one / more than one). §10.1 names the clause as the governed exit from ambiguous routing and as the selector for historical-state materialization.
E This agrees with Revision BL W002-WKO-012.3 ("an optional MAP "..." supplies the exact historical/current Store-state base") and with W002-STOR-019.1 and 019.2. §10.1 also says it supersedes only the omission from §4.4.

Assessment

I The P2-01 ambiguity exit and the §3.9 "Compatible explicit MAP" and "Different source" acceptance cases can now be written. The contradiction is gone.
I Its position and cardinality are exact, so an independent parser can enforce it. The F-04 cardinality gate and the no-positional-join rule still apply after a MAP is selected (P2-01 §3.3).

Residual. None for the gate. See E-01 and E-02 for two integration items this raises.

P3-02Pass 3: BLOCKINGRESOLVED

The UTF-8 and CSV refusal facts now have fixed positions in the MATERIALIZE Receipt

Evidence

E §10.2 names the Receipt as the durable home. It inserts UTF8_FIRST_INVALID_BYTE_OFFSET and UTF8_STOP_REASON after STAGE1_ELAPSED_MS, and the five CSV_… keys after STAGE2_ELAPSED_MS. All seven are present in every MATERIALIZE Receipt and hold NOT_APPLICABLE when that refusal class did not occur. A worked example is given.
E §10.3 adds UNDEFINED_WINDOWS_1252_BYTE_OFFSET after SOURCE_ENCODING in the CONVERT table: the zero-based absolute offset of the first undefined byte, or NOT_APPLICABLE.
E §10.4 makes NOT_APPLICABLE the authoritative token for these new fields only, and leaves the wider P3-04 refusal matrix as a material obligation.

Assessment

I The F-06 and F-07 location oracles now appear in a byte-exact artifact, so the §8.15 golden refusal fixtures can be authored. "Exactly this order" and "records these facts" no longer conflict.
I The prefixes (UTF8_, CSV_) avoid any collision with the existing Receipt keys, and the worked example is consistent with the §7.1 definitions. A Stage 1 refusal fills the UTF-8 pair and leaves the CSV five NOT_APPLICABLE; a CSV refusal is the reverse. There is no case where both apply, because Stage 2 never runs after a Stage 1 refusal.
I The STOP_REASON token set remains open (F-07, material), and §10.2 says so rather than inventing tokens. Likewise, the empty-file condition (P3-09) still has no CSV_REFUSAL_CONDITION value. Both were material in Pass 3 and remain so.

Residual. None for the gate. P3-04 and P3-09 carry forward as material.

2. New items from the erratum

Neither item is blocking. Both should be settled when the successor text is written.

E-01CLARITY — fix before copying into the PRD

The corrected structure writes `KEEP:` with a colon; everywhere else it is bare `KEEP`

Evidence

E §10.1's "corrected" canonical block shows KEEP: followed by an indented ....
E Revision BL W002-STEPS-001, Pass 1 log §11.5 and Pass 2 log §4.4 all use the bare keyword KEEP. The string KEEP: appears nowhere else in Revision BL or either reconciliation log. The colon is significant in DS-STEPS elsewhere (SUITCASE: .).
E §10.1: "This erratum supersedes only the omission of MAP from Pass 2 §4.4. It does not withdraw … the other frozen MATERIALIZE ordering/cardinality rules."

Assessment

I The scope sentence settles the question, since the erratum cannot have changed the KEEP keyword, so this is not a contradiction. But this block is labelled "canonical" and is the one most likely to be pasted into W002-STEPS-001. If it goes in as written, every existing Work Order would refuse.

Question / direction for T. Correct the block to bare KEEP in the integration text, or in a one-line addendum if you want the record itself clean.

E-02MATERIAL NON-BLOCKING

Materializing from an explicitly named historical MAP needs two stated rules: whether that MAP must be healthy, and whether the lineage's health gate still applies

Evidence

E §10.1 allows the named MAP to be "the current or a historical structurally valid Store MAP" and says it "binds the materialization run to that exact Store lineage".
E F-03 §6.3–6.5: Store status is evaluated from the lineage's current MAP, and DEGRADED refuses materialization. F-03 §6.9: Data Sculptor must not hide present damage by using an older snapshot.
E A historical MAP can still reference a COL that was later lost and removed from current state by REPAIR MAP.

Assessment

I Read together, the rules imply that a DEGRADED or INVALID lineage still refuses even when the analyst names a clean historical MAP. That follows from the text, but it should be said outright, because "binds the run to the named MAP" invites the opposite reading.
I The open case is a VALID lineage whose named historical MAP references a COL that no longer exists. Copying that binding forward would publish a successor that makes the Store DEGRADED on arrival, or fail publication validation, depending on how W002-STOR-019.10 is rewritten. Nothing decides which.

Question / direction for T. State that the lineage health gate applies whichever MAP is named. Then decide the historical-base case. I recommend refusing when any binding in the named base is currently missing or invalid, with Help naming the affected COLs. The same rule should cover UPDATE ALIASES from a historical MAP (F-21), which has the same exposure.

3. Gate conclusion

READY FOR CANONICAL PRD INTEGRATION

P3-01 and P3-02 are resolved, and the erratum introduces no new blocking contradiction with the six gate decisions, Revision BL or the Pass 1 decisions checked. The reconciliation decisions are coherent enough to integrate into a successor PRD revision.

This conclusion covers the decision record only. Integration still carries every material and clarity obligation listed in the Pass 2 and Pass 3 checklists (including P3-03 to P3-10 and P2-03 to P2-07), plus E-01 and E-02 above. None of them is a precondition for starting integration, but each must be settled in the successor text. The resulting successor PRD will need its own review; this gate says nothing about it.