WASM-002 Claude QA Reconciliation Log — Pass 2

Claude showed that the Pass 1 multi-Store MAP decision created a silent Store-disappearance path. If a current shared MAP contains Store A and Store B, and a later operation publishes a successor from an older historical MAP containing only Store A, the new shared MAP can become current without Store B. A routine materialization of Store B's source can then establish another Store B with a new RID. That recreates the silent-fork class of failure F-03 was intended to eliminate.

One Store MAP file represents exactly one Store lineage.

• A Store lineage is permanently identified by one exact governed rid_filename.
• Every row in one valid Store MAP belongs to that same lineage and therefore carries that same exact rid_filename.
• Every materialized COL row in that Store MAP carries one common exact source_filename.
• A valid Store MAP must not contain rows for a second rid_filename.
• A valid Store MAP must not mix source filenames within the Store lineage.
• Different Stores in the same Suitcase use different Store MAP files.
• A Store MAP may still contain many rows because one Store may have many governed COL bindings. One Store per MAP does not mean one row per MAP.

• The redundant store_source_filename field remains unnecessary for the intended WASM-002 Store MAP profile.
• The Store source identity is the one common exact source_filename carried by the Store's materialized COL rows.
• An explicitly named Store MAP identifies and authorizes continuation of only that Store lineage.
• Work Order SOURCE must exactly equal the Store MAP's common source_filename before materialization may continue.
• Matching source identity does not bypass the F-04 existing-Store cardinality gate.
• Equal row count never authorizes a different source file to enter the Store lineage.
• WASM-002 therefore has no implicit positional-join escape.

Each Store lineage has its own chronological history of immutable Store MAP snapshots.

Store A: A1 → A2 → A3
Store B: B1 → B2

• Publishing A3 may change the current governed state of Store A.
• Publishing A3 does not add, remove, supersede, invalidate, or alter B2.
• Current-state selection for one Store is performed only among eligible Store MAPs belonging to that Store's exact rid_filename lineage.
• There is no Suitcase-wide current Store MAP carrying every Store.
• Independent Store histories coexist in the same flat Suitcase.

• An analyst may explicitly select an eligible historical Store MAP for Store A as input state for a later governed operation on Store A.
• A successor produced from historical Store A state remains in Store A's chronological MAP history.
• If that successor becomes Store A's latest eligible MAP under the ordinary chronology rules, it becomes Store A's current state.
• The operation has no effect on Store B or any other Store lineage.

• If no eligible Store lineage matches the exact Work Order SOURCE filename, materialization may establish a new Store and new RID under the separately frozen Store-creation rules.
• If exactly one eligible Store lineage matches, Data Sculptor uses that lineage's current eligible Store MAP as the inheritance base.
• If more than one distinct Store lineage is eligible for the same exact source filename, automatic routing refuses rather than guessing.
• The analyst must explicitly identify the intended valid Store MAP when source filename alone is ambiguous.

Cross-Store relationships are not encoded by putting several Store lineages into one Store MAP. A future join-specific artifact, such as a Join MAP or equivalent, remains a proposal outside WASM-002. Its class, schema, syntax, lifecycle, and acceptance rules are not frozen here.

Store MAPs describe individual Stores; future join-specific artifacts describe explicit relationships among Stores.

• One-lineage invariant: a Store MAP containing two distinct rid_filename values is invalid for WASM-002.
• Single-source invariant: rows in one Store MAP that disagree on source_filename are invalid.
• Independent histories: publishing a successor MAP for Store A must leave Store B's current-state resolution unchanged.
• Historical A successor: publishing from historical Store A state must not remove or change Store B state.
• Compatible explicit MAP: SOURCE matches the Store MAP source; execution may proceed to F-04 cardinality checking.
• Different source: SOURCE differs; the Run refuses before materialization.
• No positional escape: different sources with equal row counts still cannot enter the same RID lineage.

• Reconcile W002-STOR-010.1, W002-STOR-019.1, W002-STOR-019.2, W002-STOR-019.9, W002-WKO-012.3, and W002-UI-ACC-016 with one Store lineage per Store MAP.
• Rewrite Pass 1 F-05 integration notes and examples so one Store MAP never contains multiple Store lineages.
• Remove the Pass 1 acceptance fixture requiring multiple Stores in one MAP.
• Retain the single-source compatibility predicate and no-positional-join gates.
• Define current Store MAP as current within one exact Store lineage, never as one Suitcase-wide Store-state artifact.
• Keep future cross-Store Join MAP design outside WASM-002.

• Every saved or executable WASM-002 Work Order must contain exactly one WORK ORDER AS "<alias>" clause.
• The decoded alias must be non-empty.
• An unaliased WKO is not valid for WASM-002.
• The alias is governed human-facing orientation and WKO-registry metadata only.
• The immutable governed WKO filename/UUID remains the physical Work Order identity and execution identity.
• Alias text does not alter analytical semantics.
• Revision BL requirements and acceptance fixtures that permit, require, or illustrate a saved/executable WKO without WORK ORDER AS are superseded by this decision.
• Pass 1 F-02 language that relies on a valid unaliased WKO is likewise superseded and must be removed during integration.

Mandatory aliases do not make alias strings permanent or globally unique forever.

• A current alias may be deliberately replaced under the frozen F-02 lifecycle.
• Replacing an alias target creates a new immutable WKO and a successor WKO MAP.
• The prior WKO remains immutable historical evidence and becomes DEPRECATED in registry authority when the replacement commits.
• At most one current WKO may hold a given non-empty alias in the current WKO MAP.

Outside a double-quoted string, the first # on a physical line begins a comment that continues through that line's LF terminator.

• Whole-line comments are permitted.
• Trailing comments are permitted.
• A # inside a double-quoted string is ordinary string content and does not begin a comment.
• Comment text has no execution semantics and is ignored after lexical recognition.
• Comments remain part of the exact saved immutable WKO bytes.
• Changing, adding, or removing only a comment therefore requires saving a new immutable WKO identity even when analytical semantics are unchanged.
• WASM-002 defines no block-comment syntax.

Ignoring blank lines and comments after lexical recognition, the WASM-002 materialization Work Order form contains, in enforced order:

1. exactly one SUITCASE: . clause;
2. exactly one WORK ORDER AS "<alias>" clause;
3. exactly one SOURCE "..." clause;
4. exactly one KEEP clause;
5. one or more valid selector lines belonging to that KEEP block; and
6. exactly one terminal MATERIALIZE clause.

Duplicate structural clauses refuse. An empty KEEP refuses. After MATERIALIZE, only blank lines or comments may follow. A trailing comment on the physical MATERIALIZE line is permitted because the comment is removed from the semantic token stream.

The mandatory alias rule applies to every saved or executable WASM-002 Work Order operation, not only materialization. Operation-specific grammar still requires separate structure tables during integration, but none of those forms may omit WORK ORDER AS.

Examples include governed Work Orders for INVENTORY, UPDATE ALIASES, REPAIR MAP, REPAIR WORK ORDER REGISTRY, and CONVERT.

• Alias mandatory: a saved/executable WKO without WORK ORDER AS refuses validation.
• Empty alias: WORK ORDER AS "" refuses.
• Exactly one alias: duplicate WORK ORDER AS clauses refuse.
• Trailing comment: a valid clause followed by # comment parses identically to the same clause without the comment.
• Whole-line comment: a physical line whose first non-whitespace character is # has no execution semantics.
• Quoted hash: # inside a double-quoted string remains string content.
• Identity: changing only comment bytes or alias bytes requires a new immutable WKO physical identity.

• Rewrite W002-STEPS-001.1 so WORK ORDER AS is mandatory, exactly once, and non-empty.
• Preserve the trailing-comment semantics of W002-STEPS-001.2.
• Rewrite W002-MAT-ACC-002.3 to remove the unaliased-WKO fixture and instead prove refusal of a missing alias.
• Retain and align W002-MAT-ACC-002.4 with whole-line and trailing-comment acceptance.
• Remove F-02 reconciliation clauses that treat an unaliased valid WKO as a special registry case.
• During the separate F-08 integration work, every operation-specific structure table must include exactly one mandatory WORK ORDER AS clause.

The repair-bootstrap Work Order is still an ordinary visible immutable WKO TXT artifact. It is not an ungoverned browser action and it is not an unsaved draft.

SUITCASE: .
WORK ORDER AS "Repair Work Order Registry"
REPAIR WORK ORDER REGISTRY

• The mandatory-alias rule frozen under P2-02 applies: the repair WKO must contain exactly one non-empty WORK ORDER AS.
• The repair WKO is saved under the normal governed WKO filename grammar __DS__WKO__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt.
• The repair WKO remains immutable after save.
• An unsaved draft can never Run.

When the current WKO MAP contains a stale registry reference or is otherwise in the specifically defined registry-repair-required state, the saved repair-only WKO may Run by its exact physical WKO filename even though it is not yet represented in the current WKO MAP.

• The exception applies only when the WKO contains exactly the governed registry-repair operation and no second operation.
• No unregistered MATERIALIZE, INVENTORY, UPDATE ALIASES, REPAIR MAP, CONVERT, or other WKO gains Run eligibility from this exception.
• The exception does not grant alias-based Run authority. The repair WKO is invoked by exact physical WKO filename.
• The exception ends once registry repair successfully publishes the successor WKO MAP.

This is the sole bypass of ordinary current-registry membership for WASM-002 Run eligibility.

1. Data Sculptor validates the repair-only draft under the governed WKO structural-validity rules.
2. It saves the WKO as a new immutable governed WKO TXT artifact.
3. Because the registry is already stale, Save does not claim that the repair WKO has been successfully registered or that a normal successor WKO MAP was committed.
4. The newly saved repair WKO remains visibly unregistered and is eligible only for the bounded bootstrap repair Run by exact physical filename.
5. The repair Run itself performs registry reconciliation and, on success, publishes the successor WKO MAP.

Save therefore does not silently perform the repair operation and does not represent a stale registry as healthy.

REPAIR WORK ORDER REGISTRY reconciles the current WKO MAP against visible WKO artifacts in the Suitcase.

• Every current-registry row whose referenced physical WKO file is missing is removed from the successor WKO MAP.
• A missing WKO is never reconstructed, inferred, copied from history, or replaced automatically by a deprecated WKO.
• Visible valid WKOs absent from the current WKO MAP are discovered and considered for registration.
• If no surviving CURRENT row owns a discovered WKO's alias, that discovered WKO is registered as CURRENT.
• If a surviving CURRENT row already owns that alias, the discovered WKO is registered as DEPRECATED; existing current authority is not silently displaced.
• If two or more previously unregistered valid WKOs share the same alias and no surviving current owner exists, all such discovered WKOs are registered as DEPRECATED; Data Sculptor does not choose a winner by UTC, filename, UUID, directory order, or discovery order.
• The repair WKO itself participates in discovery and registration like any other visible valid WKO after the repair run succeeds.
• Predecessor WKO MAPs and surviving WKO files remain immutable historical evidence.

A visible WKO is structurally valid for registry purposes only when all of the following hold:

• it is a regular root-level Suitcase file;
• its physical filename conforms exactly to the governed WKO filename grammar;
• its bytes are valid UTF-8;
• LF and CRLF physical line endings are accepted; a lone CR line ending refuses;
• its content parses completely under exactly one defined WASM-002 Work Order operation grammar;
• it contains exactly one mandatory non-empty WORK ORDER AS clause;
• its required common and operation-specific structural clauses are present in their governed order/cardinality;
• unknown syntax or prohibited operation mixing causes invalidity/refusal.

Structural validity is not runtime success. A structurally valid WKO remains a valid governed artifact even when a runtime precondition is currently false, such as a referenced source file being absent. Runtime preconditions are checked at Run.

The Pass 1 three-column lifecycle model remains the intended WKO MAP profile:

wko_status,wko_alias,wko_filename

• UTF-8 without BOM.
• LF record termination.
• wko_status uses exactly CURRENT or DEPRECATED.
• Because P2-02 makes aliases mandatory, every valid WKO MAP row carries a non-empty wko_alias.
• wko_filename is the exact governed physical WKO filename.
• Rows are serialized in ascending UTF-8 byte order of wko_filename.
• Duplicate wko_filename rows are invalid.
• For any exact alias, at most one row in the current WKO MAP may carry wko_status=CURRENT.
• Standard governed CSV quoting applies.

A DEPRECATED WKO remains a valid immutable governed historical artifact. Deprecation changes alias authority, not physical validity.

• Run by human-facing alias resolves only to the sole CURRENT WKO for that alias.
• A registered CURRENT WKO may Run by exact physical WKO filename, subject to ordinary runtime preconditions.
• A registered DEPRECATED WKO may also Run by exact physical WKO filename, subject to ordinary runtime preconditions. This supports deliberate historical reproduction.
• An unregistered WKO may not Run merely because its file is visible, except for the single bounded registry-repair bootstrap rule in Section 5.2.

The canonical Receipt operation token for this governed operation is:

OPERATION: REPAIR_WORK_ORDER_REGISTRY

F-09 remains responsible for freezing the complete Receipt envelope and operation-specific key order. This decision freezes only the canonical operation identity needed to remove the F-02 ambiguity.

• Deadlock escape: with a stale current WKO MAP, a newly saved structurally valid repair-only WKO can Run by exact filename and successfully publish a repaired successor registry.
• No broad bypass: a newly saved unregistered WKO for any other operation remains ineligible to Run.
• Missing reference: repair removes a stale registry row but does not recreate the missing WKO or promote an older WKO automatically.
• Discovered alias, no owner: one discovered valid WKO with an otherwise unowned alias becomes CURRENT.
• Discovered alias collision: a discovered WKO whose alias is already owned by a surviving CURRENT row becomes DEPRECATED.
• Several discovered WKOs, no owner: all become DEPRECATED; no winner is inferred.
• Mandatory alias: no unaliased WKO can be structurally valid.
• Deterministic MAP: repaired successor rows are sorted by ascending UTF-8 byte order of exact wko_filename.
• Historical Run: a registered DEPRECATED WKO can be invoked by exact physical filename but not by alias.
• Receipt identity: a registry-repair Receipt uses REPAIR_WORK_ORDER_REGISTRY as its operation token.

WASM-002 distinguishes two questions that must not be conflated:

1. Is the Store MAP itself structurally valid?
2. What is the health of the Store described by the current structurally valid Store MAP?

A Store MAP remains part of governed Store history when its own bytes, schema, lineage facts, and deterministic structural rules are valid, even if a RID or COL artifact referenced by that MAP later becomes missing or invalid.

Referenced-artifact damage therefore does not make the current Store MAP disappear from lineage authority and does not by itself trigger fallback to an older MAP.

• Current-state selection is performed independently within one exact Store lineage under the P2-01 one-Store-per-Store-MAP model.
• Only structurally valid Store MAP artifacts participate in current-state selection.
• Among structurally valid Store MAPs in that lineage, the ordinary frozen chronology rules determine current state.
• A structurally malformed newer MAP is never current.
• If a newer canonical MAP artifact is structurally malformed, Data Sculptor uses the greatest earlier structurally valid Store MAP in that same lineage, if one exists, and reports the malformed newer artifact through Help/evidence surfaces.
• This fallback applies to structural MAP invalidity only. It does not apply merely because a valid current MAP references a damaged RID or COL.

Store status is evaluated from the current structurally valid Store MAP and the presently visible governed artifacts it references:

• VALID — current Store MAP structurally valid; referenced RID valid; every mapped non-RID COL valid.
• DEGRADED — current Store MAP structurally valid; referenced RID valid; one or more mapped non-RID COL artifacts missing or invalid.
• INVALID — current Store MAP structurally valid, but its referenced RID is missing or invalid.

There is no fourth ABANDONED status.

VALID, DEGRADED, and INVALID are evaluated Store states. WASM-002 does not write a mutable persisted Store-status flag.

• “INVALID is terminal” is superseded by the more precise rule: while a Store evaluates INVALID, Data Sculptor exposes no governed Store-recovery operation for that Store.
• Data Sculptor never regenerates, substitutes, or infers a replacement RID.
• If the exact original governed RID artifact is externally restored byte-for-byte under its original physical identity and validates again, the Store may evaluate VALID or DEGRADED on the next inspection.
• Such re-evaluation is not RID recovery by Data Sculptor; it is the consequence of the same governed artifact becoming valid/present again.

When a Store evaluates DEGRADED, REPAIR MAP remains the only enabled Store operation.

• Materialization into that Store is refused.
• Extension with new columns is refused.
• Alias mutation is refused.
• Transformations and other Store mutations are refused.
• Read-only Help, Inventory, status, and evidence inspection remain available.

A WASM-002 registry-repair Work Order is not target-free. It must identify the exact current Store MAP:

SUITCASE: .
WORK ORDER AS "Repair Crime Store"
MAP "__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv"
REPAIR MAP

• Exactly one MAP "<filename>" clause is mandatory for REPAIR MAP.
• The MAP value is the exact physical filename of one structurally valid Store MAP.
• The named Store MAP must be the current Store MAP for its lineage at Run time.
• The target Store must currently evaluate DEGRADED.
• A historical Store MAP refuses for REPAIR MAP.
• A WKO MAP, missing MAP, malformed MAP, ambiguous equal-latest current state, or MAP from another unsupported profile refuses.
• No SOURCE, Store alias, RID alias, or COL list is supplied by the analyst for the repair operation.

The analyst selects the Store by exact current Store MAP identity. Data Sculptor determines which non-RID COL bindings are broken.

After target validation, Data Sculptor:

1. confirms that the named MAP is the current structurally valid MAP for exactly one Store lineage;
2. confirms that the referenced RID is valid;
3. identifies each mapped non-RID COL artifact that is currently missing or invalid;
4. preserves every valid COL binding unchanged;
5. removes exactly the broken COL bindings from the successor Store MAP candidate;
6. preserves the exact Store lineage RID identity and remaining Store/RID metadata;
7. validates the complete successor MAP candidate before publication;
8. publishes the successor MAP only if all repair gates succeed.

REPAIR MAP does not read or regenerate the source CSV, does not rematerialize a lost COL, does not regenerate the RID, and does not edit the predecessor MAP in place.

If removing all broken COL bindings would leave the successor Store MAP with zero COL mapping rows, REPAIR MAP must refuse.

• No zero-COL Store MAP is introduced in WASM-002.
• No special Store-anchor row is added to the Store MAP schema.
• No successor MAP is published.
• The Store remains DEGRADED.
• The Store lineage remains visible and anchored by its existing current structurally valid MAP and RID.
• Data Sculptor does not silently erase the lineage, create a replacement Store, or generate a new RID.

Help must explain that structural MAP repair cannot remove every mapped column. If an exact original valid COL artifact is restored externally, status may be re-evaluated and repair may later succeed if at least one valid COL binding remains.

The following distinction is controlling:

• Malformed newer MAP: the MAP itself is structurally invalid, so it never becomes current; use the greatest earlier structurally valid Store MAP in the lineage if one exists.
• Current valid MAP + missing/invalid COL: keep that MAP as current; Store evaluates DEGRADED.
• Current valid MAP + missing/invalid RID: keep that MAP as current; Store evaluates INVALID.

Data Sculptor must not hide present-day damage by silently falling back to an older Store snapshot whose referenced artifacts happen to remain intact.

• If exact SOURCE routing identifies a Store lineage whose current status is DEGRADED, ordinary materialization refuses and directs the analyst to REPAIR MAP.
• If exact SOURCE routing identifies a Store lineage whose current status is INVALID, ordinary materialization refuses. WASM-002 provides no RID-recovery path.
• Neither condition permits Data Sculptor to treat the source as unseen and establish a replacement Store with a new RID.

• Target required: REPAIR MAP without exactly one current Store MAP target refuses.
• Historical target: a structurally valid but non-current historical Store MAP refuses for repair.
• Wrong profile: a WKO MAP supplied as repair target refuses.
• DEGRADED repair: one or more broken COL bindings are removed while every valid binding and the exact RID identity are preserved.
• All COLs broken: repair refuses, publishes no successor MAP, and the Store remains DEGRADED.
• Malformed newest MAP: current-state resolution falls back to the greatest earlier structurally valid MAP in the same lineage and reports the malformed artifact.
• Missing COL in current valid MAP: no fallback; Store is DEGRADED.
• Missing RID in current valid MAP: no fallback; Store is INVALID.
• Exact original RID restored externally: status is re-evaluated without Data Sculptor creating a replacement RID.
• No silent fork: neither DEGRADED nor INVALID allows ordinary materialization to create a replacement Store for the same routed lineage.

Every structural CSV refusal records these governed facts:

REFUSAL_CONDITION
SOURCE_BYTE_OFFSET
PHYSICAL_LINE
LOGICAL_RECORD
FIELD_ORDINAL

• SOURCE_BYTE_OFFSET is the zero-based absolute byte offset from the first physical byte of the source file. A leading UTF-8 BOM, when present, occupies offsets 0–2 and therefore counts in subsequent absolute byte locations.
• PHYSICAL_LINE is one-based and equals one plus the number of LF bytes strictly before the governed refusal location. LF bytes inside quoted multiline fields still increment physical-line count.
• LOGICAL_RECORD is one-based CSV logical-record ordinal and includes the header as logical record 1. The first data record is therefore logical record 2.
• FIELD_ORDINAL is the one-based field position within that logical record.

These facts describe the same first structural refusal regardless of permitted streaming-window size or boundary placement.

For the WASM-002 CSV grammar, the canonical structural malformed-CSV condition tokens are exactly:

UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD
INVALID_BYTE_AFTER_CLOSING_QUOTE
BARE_CR_OUTSIDE_QUOTED_FIELD
EOF_INSIDE_QUOTED_FIELD
BLANK_LOGICAL_RECORD
TOO_FEW_FIELDS
TOO_MANY_FIELDS

Parser-library names, host exceptions, crate-specific error enums, or localized descriptions must not replace these governed tokens.

• For TOO_FEW_FIELDS, FIELD_ORDINAL is the first missing field ordinal: expected-width position immediately after the last field actually present.
• For TOO_MANY_FIELDS, FIELD_ORDINAL is the first extra field ordinal: header-width + 1.
• For quote/CR/EOF structural conditions, FIELD_ORDINAL is the current field ordinal in which the malformed condition is established.
• For BLANK_LOGICAL_RECORD, FIELD_ORDINAL is 1.

A bare CR outside a quoted field is malformed CSV and refuses with BARE_CR_OUTSIDE_QUOTED_FIELD.

• CR inside a valid quoted field is ordinary field content.
• LF inside a valid quoted field is ordinary field content.
• CRLF inside a valid quoted field is ordinary field content.
• Outside quoted fields, CRLF is one accepted logical-record terminator and LF is one accepted logical-record terminator.
• Outside quoted fields, a CR not immediately followed by LF is malformed.

If EOF is reached while the parser remains inside an open quoted field, the source refuses with EOF_INSIDE_QUOTED_FIELD.

Data Sculptor must not synthesize a closing quote, truncate the field, reinterpret prior bytes as unquoted content, or otherwise repair the source.

Stage 2 evaluates structural CSV input in absolute source-byte order and reports the earliest refusal condition that becomes deterministically established.

• CSV grammar errors take precedence over later row-shape errors.
• BLANK_LOGICAL_RECORD takes precedence over TOO_FEW_FIELDS for a physically blank logical record.
• BARE_CR_OUTSIDE_QUOTED_FIELD takes precedence over INVALID_BYTE_AFTER_CLOSING_QUOTE when the post-quote offending byte is a CR that is not followed by LF.
• At EOF while still inside a quoted field, EOF_INSIDE_QUOTED_FIELD takes precedence over field-count evaluation.

No implementation may choose a different error merely because of parser buffering, window boundaries, library behavior, or host platform.

For the same certified source bytes, changing the permitted Stage 2 input-window size or boundary placement must not change:

• whether the source is accepted or refused;
• the first REFUSAL_CONDITION;
• SOURCE_BYTE_OFFSET;
• PHYSICAL_LINE;
• LOGICAL_RECORD;
• FIELD_ORDINAL.

Acceptance fixtures must force boundaries around commas, opening and closing quotes, doubled-quote pairs, CR/LF pairs, quoted multiline content, empty fields, and already-certified multibyte UTF-8 sequences.

Comma remains the only WASM-002 field delimiter. Automatic delimiter detection is outside the WASM-002 CSV contract.

A file whose rows contain semicolons, tabs, or other non-comma separators may still be valid under the comma-only grammar as a one-column CSV. Data Sculptor must not invent a malformed-CSV refusal merely because another application would treat those bytes as delimiters.

When a requested HEADER cannot be resolved, Help may explain that WASM-002 uses comma as the CSV delimiter and that semicolon/tab exports may therefore be interpreted as one field per row.

The F-06 refusal oracle governs structural CSV failures after the source has passed the applicable encoding-certification boundary.

Invalid UTF-8 remains governed by the separately frozen UTF-8 diagnostic contract. Its zero-based absolute source-byte orientation is intentionally aligned with SOURCE_BYTE_OFFSET so WASM-002 does not have competing byte-coordinate systems.

• An unexpected quote in an unquoted field reports the quote byte and UNEXPECTED_QUOTE_IN_UNQUOTED_FIELD.
• A prohibited byte after a closing quote reports that byte and INVALID_BYTE_AFTER_CLOSING_QUOTE.
• A bare CR outside quoted content reports the CR byte and BARE_CR_OUTSIDE_QUOTED_FIELD.
• CR/LF/CRLF inside quoted values remain field content and do not trigger the bare-CR rule.
• EOF in an open quoted field reports the one-past-end source offset and EOF_INSIDE_QUOTED_FIELD.
• A blank logical record reports BLANK_LOGICAL_RECORD, not TOO_FEW_FIELDS.
• A short record reports the terminator/EOF location and first missing field ordinal.
• A wide record reports the delimiter opening the first extra field and that extra field ordinal.
• All refusal facts remain identical across permitted source-window sizes and boundary placements.
• A semicolon-separated file is not refused solely because it uses semicolons; Help may explain comma-only interpretation when header selection fails.

• RCP TXT is UTF-8 without BOM.
• Line endings are LF only.
• Every artifact ends with exactly one final LF.
• No serialized line carries trailing spaces.
• No blank physical lines are emitted unless a later frozen artifact grammar explicitly requires them.
• Every ordinary fact is serialized as KEY: VALUE, using one ASCII colon followed by exactly one ASCII space.
• Fixed machine tokens and non-negative decimal integers are unquoted.
• Filenames, aliases, headers, and other free text are double-quoted UTF-8 strings; a literal " is doubled inside the quoted value.
• CR and LF are not permitted inside one serialized value.

Every canonical WASM-002 Receipt begins with the following keys in exactly this order:

1. RECEIPT_VERSION
2. RECEIPT_FILENAME
3. RECEIPT_UTC
4. WORK_ORDER_FILENAME
5. OPERATION
6. RUN_STARTED_UTC
7. RUN_FINISHED_UTC
8. RESULT
9. DIAGNOSTIC_ID
10. IDENTITY_COLLISION_RETRIES

RECEIPT_FILENAME is the exact physical governed RCP filename. RECEIPT_UTC is exactly the canonical UTC timestamp embedded in that filename. It is the Receipt artifact's own identity/publication timestamp and does not replace RUN_STARTED_UTC or RUN_FINISHED_UTC.

IDENTITY_COLLISION_RETRIES is always present and is 0 when no governed filename-allocation retry occurred.

• RESULT uses at minimum SUCCESS or REFUSED.
• DIAGNOSTIC_ID: NONE is used for an ordinary successful run.
• NONE means the fact definitively has no value in the event.
• NOT_RUN means the stage/operation was not executed.
• NOT_AVAILABLE means the fact may or should exist but was unavailable.
• UNKNOWN_OPERATION remains the operation token when parsing/validation fails before a governed operation can be identified.
• A refusal Receipt never fabricates downstream stage facts or publication identities.

Every governed indexed key suffix is one-based decimal with a minimum width of three digits and no maximum width:

001
002
...
999
1000
1001
...
16386

• Indices begin at 1 and increase contiguously with no gaps.
• Indices 1 through 999 are left-padded with ASCII zeroes to three digits.
• Index 1000 and above uses its ordinary full ungrouped decimal form; no truncation, wrap, reset, or upper digit-count limit is permitted.
• The rule applies uniformly to CREATED_ARTIFACT_..., FILE_..., published-COL lists, repair lists, registry-repair lists, fallback-disclosure lists, and any other governed indexed RCP/INV sequence.

After all operation-specific facts and operation-specific indexed lists, every Receipt ends with:

CREATED_ARTIFACT_COUNT: <N>
CREATED_ARTIFACT_001: "..."
...
CREATED_ARTIFACT_N: "..."

• The list contains exact physical governed filenames successfully published by the run, excluding the Receipt itself.
• The number of lines equals CREATED_ARTIFACT_COUNT.
• When the count is zero, no CREATED_ARTIFACT_... lines appear.
• A filename allocated for a candidate, retained scratch evidence, or a failed partial write is not listed as a successfully created artifact unless its class-specific publication contract says it was successfully published.

The six executable WASM-002 operation tokens covered by this Receipt contract are:

MATERIALIZE
INVENTORY
UPDATE_ALIASES
REPAIR_MAP
REPAIR_WORK_ORDER_REGISTRY
CONVERT_WINDOWS_1252_TO_UTF_8

RECOVER_RID is not a valid WASM-002 operation token.

After the common envelope, a MATERIALIZE Receipt serializes these operation-specific facts in exactly this order:

1. SOURCE_FILENAME
2. BASE_MAP_FILENAME
3. RID_FILENAME
4. RID_ACTION
5. STAGE1_UTF8_OUTCOME
6. CERTIFIED_SOURCE_BYTE_COUNT
7. STAGE1_ELAPSED_MS
8. STAGE2_LOGICAL_ROW_COUNT
9. STAGE2_ELAPSED_MS
10. REQUESTED_COLUMN_COUNT
11. RESOLVED_COLUMN_COUNT
12. PUBLISHED_COL_COUNT
13. zero or more PUBLISHED_COL_... lines
14. SUCCESSOR_MAP_FILENAME
15. OPERATIONAL_NAME_FALLBACK_COUNT
16. zero or more fallback-record triplets defined in §8.8

• BASE_MAP_FILENAME: NONE denotes a newly established Store with no predecessor Store MAP.
• RID_ACTION uses CREATED, REUSED, or the applicable absence/not-run token on refusal.
• STAGE1_UTF8_OUTCOME uses the governed Stage 1 outcome token, with NOT_RUN where Stage 1 did not execute.
• Elapsed times are non-negative whole milliseconds encoded as ungrouped ASCII base-10 integers when known.
• PUBLISHED_COL_... entries are exact physical COL filenames in resolved KEEP order.
• SUCCESSOR_MAP_FILENAME is the exact published successor MAP on success or the applicable absence token on refusal.

For a successful Store-establishing materialization, the common created-artifact list is ordered RID first, then newly published COLs in resolved KEEP order, then successor MAP. For a successful existing-Store materialization, the inherited RID is not newly created; the list contains newly published COLs in resolved KEEP order followed by the successor MAP.

Whenever the F-20 operational-name fallback is actually used by MATERIALIZE, the Receipt records one indexed triplet per affected source column:

OPERATIONAL_NAME_FALLBACK_COUNT: 2
OPERATIONAL_NAME_FALLBACK_001_COLUMN_ORDINAL: 7
OPERATIONAL_NAME_FALLBACK_001_ASSIGNED_NAME: "Column G"
OPERATIONAL_NAME_FALLBACK_001_REASON: SOURCE_HEADER_EXCEEDS_1024_SCALARS

• Fallback records are ordered by ascending physical source-column ordinal.
• ..._COLUMN_ORDINAL is the one-based physical source-column ordinal.
• ..._ASSIGNED_NAME is the exact final deterministic operational name after any collision disambiguation.
• ..._REASON is exactly SOURCE_HEADER_EXCEEDS_1024_SCALARS.
• The complete oversized source header is not reproduced merely to document the fallback.

After the common envelope, an INVENTORY Receipt contains:

1. INVENTORY_FILENAME
2. INVENTORY_ENTRY_COUNT

On success, INVENTORY_FILENAME is the exact physical INV artifact identity and the common created-artifact list contains that INV filename. On refusal before INV publication, the filename uses the applicable absence token and no uncommitted candidate is claimed as published.

The INV artifact uses the shared UTF-8/no-BOM/LF and KEY: VALUE rules. Its exact header order is:

1. INVENTORY_VERSION
2. INVENTORY_UTC
3. WORK_ORDER_FILENAME
4. SUITCASE_DECLARATION
5. FILE_COUNT

For WASM-002 the Suitcase declaration is serialized as:

SUITCASE_DECLARATION: "."

Each regular-file entry then contributes exactly three keys:

FILE_001_FILENAME: "example.csv"
FILE_001_BYTE_LENGTH: 12345
FILE_001_LAST_MODIFIED_UTC: 20260929T120000000Z

• Entries are ordered by ascending exact physical filename UTF-8 byte sequence.
• FILE_n_FILENAME is the exact visible filename.
• FILE_n_BYTE_LENGTH is the exact non-negative byte length reported by the host file object.
• FILE_n_LAST_MODIFIED_UTC is the host/browser-reported last-modified value in canonical UTC millisecond form when usable; otherwise NOT_AVAILABLE.
• The current INV artifact describes the pre-publication Suitcase snapshot and therefore excludes itself; any older INV already present at snapshot time is listed normally.
• No blank lines appear between entries in the actual artifact.

The previously frozen operation-specific facts remain, in exactly this order:

1. BASE_MAP_FILENAME
2. SUCCESSOR_MAP_FILENAME

If no successor MAP is successfully published, SUCCESSOR_MAP_FILENAME uses the applicable absence token.

After the common envelope, a REPAIR_MAP Receipt serializes:

1. TARGET_MAP_FILENAME
2. RID_FILENAME
3. BROKEN_COL_COUNT
4. zero or more BROKEN_COL_..._FILENAME lines
5. RETAINED_COL_COUNT
6. SUCCESSOR_MAP_FILENAME

• Broken COL filenames are serialized in ascending exact UTF-8 filename-byte order.
• RETAINED_COL_COUNT is the number of valid mapped non-RID COL bindings preserved in the candidate/resulting Store state.
• On the all-COLs-broken refusal frozen under F-03, SUCCESSOR_MAP_FILENAME: NONE; no zero-COL successor MAP is claimed.

The exact operation token is REPAIR_WORK_ORDER_REGISTRY. Its operation-specific facts are:

1. BASE_WKO_MAP_FILENAME
2. REMOVED_STALE_ROW_COUNT
3. zero or more REMOVED_STALE_WKO_..._FILENAME lines
4. REGISTERED_CURRENT_COUNT
5. zero or more REGISTERED_CURRENT_WKO_..._FILENAME lines
6. REGISTERED_DEPRECATED_COUNT
7. zero or more REGISTERED_DEPRECATED_WKO_..._FILENAME lines
8. SUCCESSOR_WKO_MAP_FILENAME

• Each filename list is independently sorted by ascending exact UTF-8 filename bytes.
• If the bootstrap repair WKO is newly discovered and registered, it is represented in the appropriate registered list according to the F-02 reconciliation rules.
• A refused registry repair never claims a successor WKO MAP that was not successfully published.

The F-10 conversion contract remains unchanged. After the common envelope, conversion serializes:

1. SOURCE_FILENAME
2. SOURCE_ENCODING
3. MATERIALIZED_ENCODING
4. TRANSCODING
5. SOURCE_CHANGED
6. OUTPUT_FILENAME

The governed operation token remains:

CONVERT_WINDOWS_1252_TO_UTF_8

Canonical PRD integration must provide byte-exact golden Receipt fixtures sufficient to prove serialization for all six executable operations:

• MATERIALIZE
• INVENTORY
• UPDATE_ALIASES
• REPAIR_MAP
• REPAIR_WORK_ORDER_REGISTRY
• CONVERT_WINDOWS_1252_TO_UTF_8

Fixtures must cover successful execution and any refusal form needed to exercise absence/not-run semantics for that operation. Canonical integration must also carry at least one byte-exact INV artifact fixture.

Acceptance compares emitted bytes directly, including UTF-8/no-BOM, LF placement, final LF, key spelling, key order, quoting, doubled-quote escaping, absence tokens, decimal formatting, index width, and deterministic list ordering.

• Every RCP proves the exact RCP filename, RCP filename UTC, WKO lineage, run start/finish UTCs, result, diagnostic identity, and collision retry count.
• A forced UUID/name collision increments IDENTITY_COLLISION_RETRIES without mutating the pre-existing artifact.
• A maximum-width 16,384-column Store-establishing materialization can serialize all 16,386 created artifacts without index overflow.
• MATERIALIZE Receipts preserve COL publication order independently from the all-artifact tail.
• Inventory records exact filename, byte length and last-modified metadata for each regular file, plus generating WKO and Suitcase declaration.
• REPAIR_MAP and registry-repair Receipts expose deterministic repair evidence rather than relying only on transient Help text.
• Oversized-header fallback is auditable without copying the oversized original header into the Receipt.
• Receipt publication never converts candidate allocation into a false successful-publication claim.

The canonical WASM-002 MATERIALIZE Work Order structure is corrected to:

SUITCASE: .
WORK ORDER AS "<alias>"
SOURCE "<filename>"
[MAP "<exact Store MAP filename>"]
KEEP:
  ...
MATERIALIZE

• MAP "<filename>" is optional with cardinality 0..1.
• If present, the MAP clause occurs immediately after SOURCE and before KEEP.
• The MAP value names one exact physical governed Store MAP filename.
• The named MAP may be the current or a historical structurally valid Store MAP for exactly one Store lineage.
• The named MAP binds the materialization run to that exact Store lineage.
• The Work Order's exact SOURCE filename must equal the lineage's common source_filename; otherwise the run refuses.
• If MAP is absent, P2-01 automatic exact-source routing applies: zero matching lineages may establish a new Store, one matching lineage routes to that Store, and more than one matching lineage refuses and requires explicit MAP selection.
• This clause is the governed exit for ambiguous exact-source routing and the governed selector for eligible historical Store-state materialization.

This erratum supersedes only the omission of MAP from Pass 2 §4.4. It does not withdraw the mandatory WORK ORDER AS rule, trailing-comment rule, or the other frozen MATERIALIZE ordering/cardinality rules.

The canonical RCP is the durable serialized home for the governed UTF-8 and CSV refusal facts used by MATERIALIZE.

In the exact MATERIALIZE Receipt key order frozen under F-09 §8.7, insert these two keys immediately after STAGE1_ELAPSED_MS:

UTF8_FIRST_INVALID_BYTE_OFFSET
UTF8_STOP_REASON

Then insert these five keys immediately after STAGE2_ELAPSED_MS:

CSV_REFUSAL_CONDITION
CSV_SOURCE_BYTE_OFFSET
CSV_PHYSICAL_LINE
CSV_LOGICAL_RECORD
CSV_FIELD_ORDINAL

• These seven keys occupy their frozen positions in every canonical MATERIALIZE Receipt.
• When the applicable refusal occurred and the fact is known, the governed value is serialized.
• When that refusal class did not occur, the value is exactly NOT_APPLICABLE.
• UTF8_FIRST_INVALID_BYTE_OFFSET carries the F-07 zero-based absolute first-invalid source-byte offset.
• UTF8_STOP_REASON carries the governed F-07 stop-reason token. The complete STOP_REASON token set remains a material integration obligation and is not invented by this erratum.
• The five CSV_... keys carry the exact F-06 refusal condition and location oracle.
• Receipt field names are intentionally prefixed to distinguish the durable RCP serialization from diagnostic-fact key naming in other surfaces.

Example — malformed CSV after successful UTF-8 certification:

UTF8_FIRST_INVALID_BYTE_OFFSET: NOT_APPLICABLE
UTF8_STOP_REASON: NOT_APPLICABLE
CSV_REFUSAL_CONDITION: BARE_CR_OUTSIDE_QUOTED_FIELD
CSV_SOURCE_BYTE_OFFSET: 1842
CSV_PHYSICAL_LINE: 27
CSV_LOGICAL_RECORD: 24
CSV_FIELD_ORDINAL: 6

For a Stage 1 UTF-8 refusal, the two UTF-8 keys are populated and all five CSV keys are NOT_APPLICABLE.

The CONVERT_WINDOWS_1252_TO_UTF_8 Receipt table is amended by inserting the following key immediately after SOURCE_ENCODING:

UNDEFINED_WINDOWS_1252_BYTE_OFFSET

• It is the zero-based absolute source-byte offset of the first undefined Windows-1252 byte encountered under the frozen compatibility mapping.
• If no undefined Windows-1252 byte caused refusal, the value is NOT_APPLICABLE.
• This does not change the frozen Windows-1252 mapping or the explicit separate conversion-operation boundary.

NOT_APPLICABLE is the authoritative absence token for the new fixed-position refusal fields when the corresponding refusal class or condition does not apply to the run. This erratum does not attempt the broader P3-04 refusal-matrix cleanup, which remains an integration-stage material obligation.