Data Sculptor WASM-002 — Revision BM Day 060 H-31 — FROZEN Focused Cut

Every persistent project or analytical artifact intentionally created by Data Sculptor must be written into the visible, user-controlled Suitcase. Data Sculptor must not intentionally persist user data, analytical state, scratch state, logs, recovery state, or project metadata in hidden AppData-style locations or browser-private persistence such as OPFS. Incidental browser/OS runtime caches outside Data Sculptor control are explicitly outside this contract.

F-24 browser-session persistence boundary: WASM-002 must not use IndexedDB, localStorage, OPFS, another browser-private database, or an equivalent hidden Data Sculptor-controlled persistence surface to remember a Suitcase directory handle, unsaved WIP text, project truth, analytical state, or live UI preferences between application instances. A later build may deliberately define a user-visible preferences or continuity mechanism, but WASM-002 does not create one implicitly. Volatile in-memory runtime state within the current application instance is permitted.

Data Sculptor does not create scratch/cache subfolders inside the Suitcase. Logical organization is expressed by the flat filename grammar, open metadata, Store MAP, and human-facing aliases.

Every artifact that Data Sculptor creates or intentionally interprets as one of its governed artifacts must use the exact visible prefix __DS__. The prefix identifies participation in the Data Sculptor namespace; it does not imply that the artifact is temporary, scratch-only, or automatically generated.

An analyst or external source file must not be renamed into __DS__ merely because Data Sculptor reads, fingerprints, certifies, or references it. If Data Sculptor creates a new governed derivative—such as an explicit converted source—the new artifact enters the __DS__ namespace under its semantic class.

F-26 SOURCE boundary: a Suitcase-root file whose exact filename begins with the reserved prefix __DS__ is not treated as an analyst-owned source merely because it has a CSV-like extension or CSV-like bytes. It participates in the reserved Data Sculptor namespace and must satisfy the applicable governed-artifact contract before any governed role is granted.

The token immediately following __DS__ must be an exact three-uppercase-letter semantic artifact class. The governed class tokens currently reserved by this PRD are:

WASM-002 emission boundary. DGN, RCV, BRD, and LCK are registered/reserved classes but are not emitted by WASM-002. Registration alone does not create a producer, serialization contract, validity contract, lifecycle, or acceptance surface. A later build that activates one of these classes must define those contracts explicitly before the class becomes emitted product behavior.

The class states semantic role rather than serialization format. WIP is not an artifact class; it is the editable non-executable Work Order lifecycle state. The Flight Recorder defined by W002-STOR-012 is a derived chronological view of governed RCP artifacts and is not an additional semantic artifact class. Existing class tokens must not be silently reassigned to different meanings. A new class requires an explicit PRD revision.

Filename extensions such as .toml, .html, .csv, .bin, and .txt describe physical serialization only and must not be used as semantic artifact classes. A governed HLP serialized as .html remains an HLP, and a governed WKO serialized as .txt remains a WKO. Any future BRD serialization must obey the same class-versus-format separation, but its format is not frozen by WASM-002.

Renaming an arbitrary file to resemble a __DS__ artifact must not make it authoritative. Before treating a governed artifact as valid, Data Sculptor must validate the applicable filename grammar plus the content, provenance, fingerprint, lineage, or other evidence required by that artifact's contract.

F-14/F-33 publication distinction: SCR-to-final promotion under W002-STOR-023 proves only that the artifact satisfied its class-specific publication predicate. It does not manufacture broader authority. In particular, WKO alias authority still comes from the committed WKO MAP, Store authority comes from the committed Store MAP, and CAT is orientation only. Retained SCR failure evidence remains non-authoritative, and the reserved RCV class is not emitted by WASM-002.

F-26 SOURCE authority: a governed CVT is eligible as a WASM-002 SOURCE only when its exact canonical CVT identity and the publication predicate governed by W002-CONV-004 and W002-STOR-023 are satisfied. Filename resemblance, a .csv extension, or copied bytes alone do not confer CVT source authority.

If WASM-002 encounters a syntactically valid __DS__ artifact whose three-letter semantic class is not allocated in the current registry, or whose class is a registered-but-not-emitted WASM-002 class (DGN, RCV, BRD, or LCK), Data Sculptor must preserve the physical file unchanged. It must not trust, execute, mutate, delete, rename, or reinterpret that file as a known emitted artifact merely because the filename has governed form.

Unknown class does not mean invalid data; it means this build has no authority to interpret that class. A known-but-not-emitted class is likewise not an instruction to activate a dormant producer or lifecycle.

Whenever a WASM-002 operation performs the governed Suitcase scan/enumeration relevant to such a file, the condition must be surfaced through a canonical INFO diagnostic rather than being silently ignored. INVENTORY must include the physical file under its existing metadata-only contract; if an existing classification field is rendered, an unknown class is identified as unknown/unrecognized and a known-but-not-emitted class is identified as reserved/not emitted without guessing additional semantics. F-33 adds no new Inventory schema field and does not pull the governed DIR feature into WASM-002.

Data Sculptor-generated names must use exact uppercase __DS__ and exact uppercase three-letter class tokens. Data Sculptor must not silently normalize variant namespace/class spellings into canonical governed artifacts. This rule applies even on case-insensitive filesystems.

F-15 governed comparison rule: unless a requirement explicitly defines a different domain-specific comparison, WASM-002 semantic equality and textual reference resolution compare decoded strings by exact Unicode scalar-value sequence. Data Sculptor performs no case folding, locale folding, Unicode normalization, trimming, or host-filesystem equivalence before the comparison. Thus differently cased strings and canonically equivalent-but-differently-encoded Unicode strings remain distinct governed values. If a host filesystem cannot safely publish two physical names that the governed semantics distinguish, publication must refuse rather than merge or reinterpret the governed identities.

Data Sculptor must never overwrite, rename, truncate, or mutate an existing artifact merely because a newly generated governed filename collides with it.

For an ordinary immutable artifact using the governed UTC+UUID identity grammar, Data Sculptor must keep the originally established canonical UTC millisecond creation timestamp, generate a new canonical lowercase hyphenated UUID v4, reconstruct the candidate filename, and try creation again. Collision retry must not advance or falsify the artifact creation timestamp merely to obtain a different sort position.

This retry may repeat until an unused valid identity is obtained. If UUID generation fails, the host cannot safely test/create the target, or another filesystem error prevents safe allocation, creation must refuse through the canonical diagnostic path rather than risk overwrite. Collision retry changes only the not-yet-created artifact's UUID. UUID is never used as a chronology field.

The filename must help humans and Data Sculptor identify the artifact's intended semantic role and route it to the correct validator. The artifact's governed content, lineage, receipt, fingerprint, provenance, and other required evidence establish what is actually true.

The exact default filename grammar for an ordinary immutable Data Sculptor-governed artifact is:

__DS__CCC__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.<extension>

CCC is the governed semantic artifact class. YYYYMMDDTHHMMSSmmmZ is the artifact's governed UTC creation/publication timestamp at millisecond precision: four-digit year, two-digit month/day/hour/minute/second, exactly three millisecond digits, and literal T/Z. <uuid-v4> is a canonical lowercase hyphenated UUID v4. The extension is governed by the artifact's serialization contract.

The token order is normative: namespace, semantic class, UTC timestamp, UUID, extension. UTC precedes UUID for every ordinary immutable class. Canonical UTC tokens with different values sort chronologically within the same class. UUID provides uniqueness and physical identity only; it must not be interpreted as a chronology tie-breaker when two artifacts share the same timestamp.

When one governed all-or-refuse Store-state publication transaction creates multiple new analytical state artifacts, Data Sculptor establishes one canonical UTC millisecond publication-transaction timestamp before final identity allocation and uses that same UTC token for every newly published RID, COL, and MAP artifact created by that transaction. Each artifact receives its own UUID. Thus a first Store materialization gives the new RID, every newly materialized COL, and the successor MAP one shared transaction UTC; a later materialization gives only its newly created COL artifacts and successor MAP the new transaction UTC while the inherited RID and inherited COL artifacts retain their earlier identities.

The shared transaction UTC is not the Work Order's authoring timestamp and does not require the Receipt filename UTC to match. RCP remains governed by W002-RCP-002 and carries its own receipt creation/publication timestamp. A shared transaction UTC expresses common publication membership, but MAP binding—not timestamp equality—remains authoritative for Store membership/current state.

Source identity, source filename, run identity, parent identity, lineage, hashes, aliases, supersession, column identity, and other relationships must not be appended as ordinary identity tokens merely to make the filename descriptive; those facts belong in governed metadata and provenance.

P2-03 successor-state UTC rule: when an operation will publish a successor Store MAP or successor WKO MAP, the transaction UTC remains a truthful observation of host UTC and must be strictly greater than the applicable chronology predecessor MAP UTC. Data Sculptor must not synthesize, increment, round forward, or otherwise fabricate a later UTC merely to satisfy chronology. UUID remains identity only and is never a chronology tie-breaker.

The first MAP in a genuinely new Store lineage, and the first WKO MAP when no structurally valid WKO MAP exists, has no chronology predecessor and therefore uses the observed host UTC normally.

Within one all-or-refuse Store-state publication transaction, every newly created RID, COL, and MAP final identity must carry the exact same canonical UTC millisecond transaction token and a distinct canonical UUID v4. UUID collision retry under PB-STOR-011 changes only the affected not-yet-created artifact UUID; it must not advance or alter the shared transaction UTC.

Artifacts merely inherited or referenced by the transaction are not renamed, retimestamped, or assigned replacement UUIDs. A valid MAP may therefore bind artifacts created under several earlier transaction timestamps. Timestamp equality is evidence that artifacts were newly published by the same transaction; timestamp inequality is not evidence that artifacts belong to different Stores.

P2-03 publication guard: for a successor Store-state transaction, the shared transaction UTC is established from truthful observed host UTC and is checked against the Store lineage's chronology predecessor before any newly created RID/COL/MAP artifact is promoted into its final governed class. If the observed transaction UTC is less than or equal to the chronology predecessor UTC, the publication refuses; the prior current MAP remains authoritative and no successor Store state commits.

Each logical Store has exactly one visible, deterministic RID artifact representing 1..N in governed logical CSV-record order. The header is excluded. Physical line count is not row identity: embedded newlines inside quoted fields remain inside one logical record.

The RID is created when the first successful materialization establishes the Store and remains stable for the life of that Store. Every same-Store materialized or later aligned result column must contain exactly N data records in the same RID order. Multiple Stores may coexist in one Suitcase, and their RID values are unrelated; the meaningful row identity is therefore the pair (Store, RID).

Materialized columns preserve governed values in permanent row alignment. Materialization stores facts for reuse; it does not decide which rows are analytically interesting.

The durable WASM-002 project model must not require semantic per-store subfolders. A logical store is represented by governed relationships among artifacts and metadata inside a flat project folder.

Every Data Sculptor Core-managed artifact must use the reserved __DS__ prefix. The prefix is deliberately visually distinctive and mechanically simple so Core artifacts cluster together under ordinary filename sorting in a mixed flat folder.

The class token must be exactly three uppercase ASCII letters A through Z, giving the fixed physical range AAA through ZZZ, and must immediately follow the reserved namespace within the frozen filename grammar.

Ordinary lexical filename sorting therefore preserves the governed class order.

WASM-002 does not reserve semantic meaning by numeric interval, lexical neighborhood, or implied class range. Any syntactically possible three-letter token that is not listed in the governed registry is unassigned for this build.

A future artifact class may be allocated only by explicit PRD revision. Existing class meanings must never be shifted, renumbered, or reassigned merely to make room for later families.

The exact WASM-002 artifact-class table is the registry in PB-STOR-006. It is no longer a separate open storage freeze item. No additional reserved class ranges are defined by WASM-002.

DGN, RCV, BRD, and LCK remain registered/reserved but are not emitted by WASM-002. Their presence in the registry does not create a WASM-002 producer, serialization contract, validity contract, lifecycle, or acceptance surface.

Independent adversarial review must verify that every WASM-002-generated governed artifact uses a listed class that this build actually emits, that WIP remains a lifecycle state rather than a class, and that unknown/unallocated classes plus known-but-not-emitted classes are preserved and reported under PB-STOR-009 rather than silently interpreted or activated.

The default Core physical naming model for immutable governed artifacts is __DS__<CLASS>__<UTC>__<UUID>.<ext>. CLASS, UTC, and UUID are governed identity tokens. Human semantic labels are excluded from the physical identity envelope. A separately frozen artifact contract may define a well-known current-state singleton filename when that artifact must be updated in place and discovered by a stable name.

Every governed Core artifact type must have a canonical filename shape and total filename length so that a parser, browser host, native host, QA tool, or LLM can recognize malformed physical identity without interpreting variable human language.

Under the Revision AH default immutable grammar, the canonical UTC token YYYYMMDDTHHMMSSmmmZ is exactly 19 ASCII characters and the canonical lowercase hyphenated UUID v4 token is exactly 36 ASCII characters. Class precedes UTC and UTC precedes UUID.

UUID identifies the governed artifact instance. SHA-256 records or verifies the exact bytes. The system must not overload one field to serve both identity and integrity.

Physical filename collisions are expected to be rare but must be handled explicitly. Data Sculptor must never silently overwrite an existing governed artifact because a generated physical name already exists.

If governed identity allocation encounters one or more filename collisions before successfully allocating a non-colliding UUID identity, the canonical run Receipt must record that a collision retry occurred and the number of retries when the run reaches receipt publication.

If identity allocation ultimately refuses, the refusal Receipt and diagnostic evidence must preserve the collision-failure fact without overwriting or mutating any pre-existing artifact.

Source files and analyst documents may retain their original filenames. Data Sculptor must not rename every input merely to fit the governed __DS__ namespace.

For an ordinary WASM-002 analytical run, continuity between certification and materialization is established by the run-local source-binding contract, not by pretending a mutable source filename is permanent byte identity. Durable cross-run exact-byte verification requires separately governed integrity evidence such as the later V1 FINGERPRINT operation.

The Store MAP must provide the machine-readable relationship between governed physical artifacts and their logical meaning, including the fields required by the frozen schema for store identity, column identity, source reference/binding, run/materialization identity, row counts, status, lineage, supersession, and related provenance.

Cryptographic hashes are recorded when a requirement or explicit operation actually produces them; the Store MAP contract must not imply that every source or artifact is automatically hashed during ordinary WASM-002 execution.

For WASM-002, human-facing orientation is provided by aliases exposed from governed Store MAP state and related governed artifacts. Aliases may help analysts navigate by meaning while preserving exact physical identities.

WASM-002 does not publish or maintain a separate Store Index artifact. Richer directory/index presentation is carried by the governed DIR surface in WASM-003.

For WASM-002, the Store MAP profile of the governed MAP artifact class is the Store metadata snapshot. It records the Store's human-facing alias, Store-establishing source filename, exact RID artifact binding, RID alias, and the complete current materialized-column mappings and aliases governed by W002-STOR-019 through W002-STOR-019.12.

WASM-002 must not create a second hidden or separately named Store-metadata file merely to bind the Store to its RID or aliases. The visible immutable __DS__MAP__...csv artifact is the authoritative governed Store MAP for this build.

Same-row derived columns and later aligned Boolean selection/filter columns remain within the same logical Store when row identity, row order, and cardinality are preserved. A future filter that evaluates every existing RID and writes one aligned two-valued Boolean result per RID does not by itself create a new row universe or a new logical Store. The canonical future selection tokens are 0 for FALSE and 1 for TRUE under PB-OPS-003 and PB-OPS-003.1.

A new row universe is created only when a later governed operation actually changes which rows exist or their order—for example by building/exporting only selected rows, deduplicating rows, or otherwise materializing a different row set. Such an operation creates a new logical Store identity under the frozen row-identity contract.

Filtering remains deferred from executable WASM-002 scope; this requirement freezes only the Store/RID compatibility rule that later filtering will rely upon.

Current Store orientation is represented by the applicable immutable MAP snapshot, while execution history is preserved by immutable RCP Receipts. For WASM-002, the Flight Recorder is the logical chronological view of published canonical RCP artifacts from actual Run invocations of saved immutable WKO Work Orders. It is not separately persisted and has no separate artifact class. Successful and refused runs contribute when Receipt publication succeeds; Receipt-publication failure is governed by W002-RCP-010 and must not be silently reconstructed as original evidence. Any Flight Recorder presentation is derived and regenerable from the authoritative Receipts.

Durable project artifacts should use documented open formats such as CSV, HTML, TXT, TOML, or other explicitly governed representations so that the Suitcase remains inspectable and portable outside Data Sculptor.

The storage grammar, class table, Store MAP schema, current-state selection rule, and alias semantics must be documented clearly enough that an LLM collaborator can distinguish physical identity, logical meaning, integrity evidence, current state, and history without guessing.

This is a documentation/readability principle for the Product Backlog PRD and related public product documentation. It does not create a new governed Suitcase artifact, require a new public-documentation file or publication operation, or add a separate WASM-002 acceptance deliverable beyond keeping the governing contract explicit and internally consistent.

The current WASM-002 storage design preserves the resolved semantic artifact-class registry, canonical UTC millisecond rendering, class → UTC → UUID token order, UUID rendering/version, default immutable identity grammar, collision retry behavior, immutable one-Store-per-MAP versioning, Store-aware automatic MAP inheritance, complete-snapshot semantics, the exact eight-column Store MAP schema, deterministic Store/RID/COL alias defaults, rematerialization alias continuity, deterministic Store-MAP CSV serialization, Store-MAP eligibility/publication validation, materialization-coupled AS alias semantics, standalone alias maintenance using UPDATE ALIASES, explicit alias clearing with CLEAR ... ALIAS, deterministic default restoration with RESET ... ALIAS, exact historical Store-MAP selection using MAP "<exact Store MAP filename>", canonical one-column COL serialization, the all-or-refuse materialization publication boundary, SCR-to-final-class host rename promotion, complete-set validation before promotion, new-Store RID-first promotion, inherited-RID reuse for existing-Store work, deterministic COL promotion, successor-MAP construction/validation as SCR, successor-MAP rename last as the Store-state commit point, rollback/recovery treatment for uncommitted promoted artifacts, the canonical RID CSV contract, the seven-operation Work Order execution surface, the canonical automatic TXT Receipt contract including exact WKO lineage, the Receipt-backed Flight Recorder, the governed HTML Suitcase Validation Certificate, the Work Order alias/comment contract plus WKO-MAP alias-registry profile, and the LCK reservation for explicit later-V1 FINGERPRINT evidence without automatic hashing in ordinary WASM-002.

RID reconstruction/replacement is deliberately not part of the WASM-002 executable surface; RECOVER RID requirements are deferred to V1-BACKLOG. The Help-report provenance boundary is resolved: WASM-002 records governed HLP identity and lineage but does not automatically SHA-256 HLP bytes or create/refresh LCK evidence; exact-byte HLP integrity remains the later explicit FINGERPRINT/LCK workflow. Future branded Receipt rendering/Brand-Manifest integration remains outside the WASM-002 TXT-only Receipt contract.

P2-04 closure: WASM-002 Store governance now has a complete two-tier artifact-validation model. Tier 1 supplies bounded Store-health checks for non-content-consuming paths; Tier 2 supplies full streaming RID/COL validation for content-consuming paths, candidate commit, and REPAIR MAP. The eight-column Store MAP remains unchanged and ordinary Store health makes no cryptographic claim of historical-byte identity.

When the analyst invokes Run on a saved immutable WKO, Data Sculptor must automatically create one governed run-receipt attempt for that invocation. The Work Order must not require a RECEIPT, SAVE RECEIPT, or equivalent clause.

An editable unsaved WIP is non-executable under the Work Order lifecycle contract and therefore cannot produce an execution Receipt. A saved WKO that is invoked and then refuses during validation or execution still has an execution outcome and must receive a refusal Receipt when receipt publication succeeds.

The physical Receipt filename is:

__DS__RCP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt

The UTC token belongs to the Receipt artifact itself and represents the Receipt's governed creation/publication time under the canonical artifact-identity rules. It must not be copied from the authorizing WKO's filename merely to make the two filenames share a timestamp.

The file is written visibly in the flat Suitcase under the governed RCP artifact class. Data Sculptor chooses the governed filename; the analyst does not supply it.

For WASM-002, the canonical run Receipt is always plain TXT. Browser theme, built-in HTML presentation, Help voice, or other presentation state must not change whether the run Receipt is emitted as TXT or alter its governed facts.

WASM-002 must not emit an HTML Receipt as an alternative to the canonical TXT Receipt. Configurable Brand Manifest behavior is deferred to a future build.

The WASM-002 Receipt is UTF-8 without BOM and uses LF (0x0A) line endings. Every Receipt ends with exactly one final LF. No serialized line carries trailing spaces, and no blank physical lines are emitted unless a later operation-specific grammar explicitly freezes them.

It is a deterministic line-oriented KEY: VALUE document with a frozen core-key order followed by operation-specific fact sections in deterministic order. KEY is an uppercase ASCII field name. The separator is exactly one ASCII colon followed by exactly one ASCII space. KEY=VALUE is not valid canonical Receipt serialization.

Fixed machine tokens and non-negative decimal integers are serialized unquoted. Human-authored text, filenames, aliases, headers, and other free text are serialized as double-quoted UTF-8 strings. Inside a quoted value, a literal double quote is represented by doubling it as "". CR and LF are not permitted inside a single serialized value; each fact remains exactly one physical line.

Enumerated values use the exact uppercase tokens frozen by the applicable requirement. Non-negative integers use ungrouped ASCII base-10 digits. This shared text rule is normative for all Receipt free-text values and is acceptance-tested byte-for-byte.

Every canonical WASM-002 Receipt begins with the following common envelope 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

Day 060 H-02 version freeze: RECEIPT_VERSION is the unquoted integer 1 for the WASM-002 Receipt contract.

RECEIPT_FILENAME is the exact physical governed RCP filename. RECEIPT_UTC is exactly the canonical UTC timestamp embedded in that filename and is distinct from the run start/finish timestamps. WORK_ORDER_FILENAME is the exact physical immutable WKO identity invoked and is the authoritative WKO→RCP lineage link.

Day 060 H-09 / BM-06 truthful run-timestamp semantics

RUN_STARTED_UTC and RUN_FINISHED_UTC are governed truthful host-UTC observations at millisecond precision. They are not decorative labels and are not synthesized from artifact filenames.

• RUN_STARTED_UTC is observed only after the exact saved WKO has been resolved and found eligible to Run, and immediately before operation-specific validation/execution begins. It therefore brackets operation validation, analytical work, publication attempts, refusal processing, and any governed rollback/cleanup performed by that Run.
• RUN_FINISHED_UTC is observed only after the operation has reached its final SUCCESS or REFUSED analytical outcome and all non-Receipt governed effects are settled: successful artifacts are committed, refusal state is established, and required rollback/cleanup or retained non-authoritative evidence classification is complete. Receipt publication begins only after this observation.

For one Run, the truthful temporal invariant is:

WKO_UTC ≤ RUN_STARTED_UTC ≤ each successfully published run-artifact UTC ≤ RUN_FINISHED_UTC ≤ RECEIPT_UTC

where WKO_UTC is the governed UTC token embedded in the exact WORK_ORDER_FILENAME, and “run-artifact UTC” means the governed UTC embedded in each non-Receipt artifact successfully published by that Run, including a shared materialization transaction UTC where applicable. An operation that publishes no non-Receipt artifact simply has no middle artifact-UTC comparison.

Equality is permitted because the canonical timestamp precision is milliseconds. Data Sculptor must not fabricate, increment, decrement, or reorder UTC values merely to make this invariant appear true. Receipt fixtures and retained acceptance evidence must use physically possible timelines under this rule.

The existing rule that WKO and Receipt filename timestamps are not required to match remains unchanged: they are distinct events, but a WKO invoked by a Run must already exist as a governed artifact before that Run begins.

RESULT is a closed WASM-002 vocabulary containing exactly SUCCESS and REFUSED. No other RESULT token is valid. DIAGNOSTIC_ID: NONE is used for an ordinary successful run; a refused run carries the exact governed diagnostic identity.

The shared governed absence-state vocabulary is closed to these four tokens, with these exact meanings:

• NONE — the fact is applicable and definitively has no value in this event;
• NOT_RUN — the owning stage or operation was not executed;
• NOT_AVAILABLE — the fact is applicable or potentially applicable, but its value could not be obtained;
• NOT_APPLICABLE — the fact does not apply to this event, diagnostic, operation, or artifact.

These states are semantically distinct and must not be substituted for one another. A count that was actually established as zero is serialized as the integer 0, never as an absence token.

The refusal-serialization matrix for every present operation-specific key is deterministic:

For this contract, a fact is established only when its owning validation/stage has deterministically fixed the value and later execution cannot revise that fact. Candidate allocation, partial bytes, or an uncommitted publication does not establish a published-artifact identity.

If parsing/validation refuses before one of the seven governed WASM-002 operations can be identified, the Receipt uses OPERATION: UNKNOWN_OPERATION, RESULT: REFUSED, and the applicable DIAGNOSTIC_ID. After the common envelope there is no operation-specific section; the Receipt proceeds directly to CREATED_ARTIFACT_COUNT: 0. UNKNOWN_OPERATION is not an executable operation.

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

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

The created-artifact list contains only exact physical governed filenames successfully published by the run, excluding the Receipt itself. For this accounting, an artifact is successfully published only if it remains a committed governed artifact when the Run finishes; an artifact promoted and then rolled back, or left only as non-authoritative failure residue under All-or-Refuse, is excluded from CREATED_ARTIFACT_COUNT and its indexed list. Indexed suffixes are one-based decimal with a minimum width of three digits and no maximum width: 001 through 999 are zero-padded and 1000 onward uses the ordinary full ungrouped decimal form. When a count is zero, no indexed lines for that list appear.

IDENTITY_COLLISION_RETRIES is always present and is 0 when no governed filename-allocation retry occurred. Receipt/WKO filename timestamps are not required to match. One immutable WKO may be run multiple times, each producing a distinct Receipt that points back to the same exact WORK_ORDER_FILENAME.

F-08 DS-STEPS / Receipt token separation. Human-authored Work Orders use the readable terminal clauses below; the Receipt serializes the corresponding machine token in OPERATION. The two columns are not interchangeable spellings:

For example, REPAIR_MAP is not valid DS-STEPS syntax and REPAIR MAP is not the serialized Receipt token. UNKNOWN_OPERATION remains a refusal-only Receipt value when validation cannot identify one of these seven operations; it is not an executable operation.

For a WASM-002 MATERIALIZE run, after the common envelope the Receipt serializes these operation-specific keys 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. UTF8_FIRST_INVALID_BYTE_OFFSET
9. UTF8_STOP_REASON
10. WINDOWS_1252_COMPATIBILITY_OUTCOME
11. WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET
12. STAGE2_LOGICAL_ROW_COUNT
13. STAGE2_ELAPSED_MS
14. CSV_REFUSAL_CONDITION
15. CSV_SOURCE_BYTE_OFFSET
16. CSV_PHYSICAL_LINE
17. CSV_LOGICAL_RECORD
18. CSV_FIELD_ORDINAL
19. REQUESTED_COLUMN_COUNT
20. RESOLVED_COLUMN_COUNT
21. PUBLISHED_COL_COUNT
22. zero or more indexed published-COL filename lines whose exact key form is PUBLISHED_COL_<INDEX>_FILENAME (for example PUBLISHED_COL_001_FILENAME, PUBLISHED_COL_002_FILENAME)
23. SUCCESSOR_MAP_FILENAME
24. OPERATIONAL_NAME_FALLBACK_COUNT
25. zero or more indexed fallback triplets: OPERATIONAL_NAME_FALLBACK_001_COLUMN_ORDINAL, OPERATIONAL_NAME_FALLBACK_001_ASSIGNED_NAME, OPERATIONAL_NAME_FALLBACK_001_REASON, continuing under the common indexed-key rule.

BASE_MAP_FILENAME: NONE denotes a newly established Store with no predecessor Store MAP.

Day 060 H-11 / BM-08 RID_ACTION ownership and establishment

RID_ACTION is a governed execution fact describing what this Run actually established for the Store RID path. It is never an intention, plan, or prediction.

• RID_ACTION: REUSED is established when routing has selected an existing Store, the exact inherited RID filename is known, and that inherited RID has passed the validation required to proceed. Because the RID already exists, this fact may be established before Stage 1 or Stage 2 completes.
• RID_ACTION: CREATED is established only when a new-Store RID candidate has successfully completed governed promotion into its final RID identity. Merely planning, allocating, writing, closing, validating, or naming an SCR candidate does not establish CREATED.
• Until either of those facts is established, the common refusal matrix governs RID_ACTION. For a new-Store path that refuses before successful RID promotion, RID_ACTION is NOT_RUN. If an existing-Store route is identified but the required inherited RID fact cannot be validly established, RID_ACTION is NOT_AVAILABLE.

RID_FILENAME is a separate fact:

• for REUSED, it is the exact already-published inherited RID filename as soon as reuse is established;
• for CREATED, it is the exact governed final RID filename only after successful RID promotion;
• before new-RID promotion succeeds, no candidate/SCR filename may be serialized as though it were a published RID.

With RID_ACTION: CREATED, RID_FILENAME records the RID identity successfully promoted during the Run even if that RID is later rolled back under All-or-Refuse; rollback does not erase the already-established RID_ACTION/RID_FILENAME execution facts.

The refusal-boundary matrix is therefore:

A refusal Receipt that says RID_ACTION: CREATED while RID_FILENAME is NONE or NOT_RUN and no RID was successfully promoted is invalid evidence.

STAGE1_UTF8_OUTCOME has exactly two completed Stage-1 values: PASS and FAIL. If Stage 1 never ran, the value is NOT_RUN. If Stage 1 began but a separate failure prevented a governed PASS/FAIL determination, the value is NOT_AVAILABLE. NOT_APPLICABLE is not valid for this key.

UTF8_FIRST_INVALID_BYTE_OFFSET and UTF8_STOP_REASON are refusal-only Stage-1 evidence. On STAGE1_UTF8_OUTCOME: FAIL, the offset is mandatory and is the exact zero-based absolute physical source-byte offset of the first byte of the invalid sequence, and the stop reason is mandatory and exactly INVALID_UTF8_SEQUENCE. Neither field may be NOT_AVAILABLE when the Stage-1 outcome is FAIL. On PASS, both fields are NOT_APPLICABLE. If Stage 1 never ran, both are NOT_RUN. If Stage 1 began but no UTF-8 PASS/FAIL conclusion was established because of a separate failure, both refusal-only fields are NOT_APPLICABLE.

WINDOWS_1252_COMPATIBILITY_OUTCOME and WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET are the governed F-16 follow-on facts. They are evaluated only after STAGE1_UTF8_OUTCOME: FAIL. When the complete second pass reaches EOF with every byte mappable, the outcome is COMPATIBLE and the offset is NOT_APPLICABLE. When the pass encounters one of the undefined bytes frozen in W002-CONV-002.4, the outcome is INCOMPATIBLE and the offset is the exact zero-based absolute physical source-byte offset of the first such byte. If the pass begins but an independent failure prevents a conclusion, both fields are NOT_AVAILABLE. If Stage 1 did not conclude FAIL, the compatibility pass does not run and both fields are NOT_RUN.

The five exact CSV refusal keys CSV_REFUSAL_CONDITION, CSV_SOURCE_BYTE_OFFSET, CSV_PHYSICAL_LINE, CSV_LOGICAL_RECORD, and CSV_FIELD_ORDINAL carry the exact structural CSV refusal condition and location oracle frozen in W002-MAT-002.8. If Stage 2 never ran, all five are NOT_RUN; if Stage 2 completed without an applicable CSV refusal, all five are NOT_APPLICABLE; on a CSV refusal, each established location fact is serialized and any applicable fact that could not be obtained is NOT_AVAILABLE.

The MATERIALIZE refusal-stage matrix is:

Day 060 H-24 / BM-08 publication-boundary split: these two MATERIALIZE publication-refusal rows apply the common W002-RCP-006 ownership rule to the successor-MAP publication stage. NOT_RUN means that stage was never entered; NONE means it was entered but no successor MAP successfully published. The early boundary is exercised by the RID identity-allocation exhaustion fixture; the later boundary has its own byte-exact golden fixture.

OPERATIONAL_NAME_FALLBACK_COUNT is NOT_RUN until operational-name resolution has run; afterward it is the established non-negative count, including literal 0. Fallback records are ordered by ascending physical source-column ordinal. the exact fallback key OPERATIONAL_NAME_FALLBACK_<INDEX>_REASON is exactly SOURCE_HEADER_EXCEEDS_1024_SCALARS.

For successful Store-establishing materialization, the common created-artifact list is ordered RID first, newly published COLs in resolved KEEP order, then successor MAP. For 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.

P3-09 Receipt oracle: when Stage 2 refuses because the certified source contains no logical CSV record, the five CSV refusal fields must serialize exactly as CSV_REFUSAL_CONDITION: NO_HEADER_RECORD, CSV_SOURCE_BYTE_OFFSET: <exact source byte length>, CSV_PHYSICAL_LINE: 1, CSV_LOGICAL_RECORD: 1, and CSV_FIELD_ORDINAL: 1.

Day 060 H-13 / BM-10 clarification: within those five governed CSV refusal fields, the zero-byte and UTF-8-BOM-only cases differ only in CSV_SOURCE_BYTE_OFFSET: 0 versus 3. Their complete Receipt bytes also differ wherever the underlying source identity, certified source byte count, Work Order identity, run/Receipt timestamps, Receipt filename/UUID, or other fixture-specific governed facts differ. The complete Receipts must never be described as differing only by one field.

F-20 operational-name Receipt oracle: OPERATIONAL_NAME_FALLBACK_COUNT counts selected/materialized columns whose exact source header exceeded 1,024 Unicode scalar values. Each corresponding ..._ASSIGNED_NAME stores the final deterministic operational/default-alias name after any permitted fallback collision disambiguation; ..._REASON remains exactly SOURCE_HEADER_EXCEEDS_1024_SCALARS. The Receipt does not copy the oversized exact source header merely to explain the fallback.

The common indexed-key rule from W002-RCP-006 applies without a maximum width. A full-width KEEP is therefore representable through PUBLISHED_COL_16384_FILENAME (and corresponding fallback indexes when applicable); the three-digit examples are a minimum-width convention, not a 999-item ceiling.

The same common envelope, closed RESULT/absence vocabulary, refusal matrix, created-artifact tail, and indexed-key rule apply to the other executable WASM-002 operations. Their operation-specific key tables are closed as follows.

INVENTORY

1. INVENTORY_FILENAME
2. INVENTORY_ENTRY_COUNT

UPDATE_ALIASES

1. BASE_MAP_FILENAME
2. SUCCESSOR_MAP_FILENAME

REPAIR_MAP

1. TARGET_MAP_FILENAME
2. RID_FILENAME
3. BROKEN_COL_COUNT
4. zero or more indexed broken-COL filename lines using exact key form BROKEN_COL_<INDEX>_FILENAME (for example BROKEN_COL_001_FILENAME, BROKEN_COL_002_FILENAME)
5. RETAINED_COL_COUNT
6. SUCCESSOR_MAP_FILENAME

Broken COL filenames are ordered by ascending exact UTF-8 filename bytes. RETAINED_COL_COUNT is the actual count once repair analysis completes, including literal 0.

REPAIR_WORK_ORDER_REGISTRY

1. BASE_WKO_MAP_FILENAME
2. REMOVED_STALE_ROW_COUNT
3. zero or more indexed stale-WKO filename lines using exact key form REMOVED_STALE_WKO_<INDEX>_FILENAME (for example REMOVED_STALE_WKO_001_FILENAME, REMOVED_STALE_WKO_002_FILENAME)
4. REGISTERED_CURRENT_COUNT
5. zero or more indexed current-WKO filename lines using exact key form REGISTERED_CURRENT_WKO_<INDEX>_FILENAME (for example REGISTERED_CURRENT_WKO_001_FILENAME, REGISTERED_CURRENT_WKO_002_FILENAME)
6. REGISTERED_DEPRECATED_COUNT
7. zero or more indexed deprecated-WKO filename lines using exact key form REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME (for example REGISTERED_DEPRECATED_WKO_001_FILENAME, REGISTERED_DEPRECATED_WKO_002_FILENAME)
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 appears in the appropriate registered list under W002-STOR-018.3 and W002-STOR-018.4.

Day 060 H-10 / BM-07 count semantics: REGISTERED_CURRENT_COUNT and REGISTERED_DEPRECATED_COUNT count only previously unregistered structurally valid WKOs that this repair Run newly adds to the successor WKO MAP with the stated status. They do not count surviving pre-existing rows already present in the base registry. The indexed filename lines list exactly the corresponding newly registered WKOs and no others.

If the bootstrap repair WKO is one of those newly registered WKOs, it must appear in exactly one registered list. A successful repair Receipt that omits a newly registered bootstrap repair WKO is invalid evidence.

CONVERT_WINDOWS_1252_TO_UTF_8

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

UNDEFINED_WINDOWS_1252_BYTE_OFFSET is the zero-based absolute physical source-byte offset of the first byte undefined by the frozen Windows-1252 mapping when that refusal occurs. If the compatibility stage never ran it is NOT_RUN; if the stage ran and no undefined-byte refusal occurred it is NOT_APPLICABLE; if the fact applies but could not be obtained it is NOT_AVAILABLE.

Day 060 H-14 / BM-11 undefined-Windows-1252-byte refusal oracle

For CONVERT WINDOWS-1252 TO UTF-8, an undefined Windows-1252 byte is detected during the complete pre-transcoding compatibility assessment. Transcoding has not begun when this refusal is established.

When the complete compatibility assessment encounters the first undefined byte, the Receipt must serialize these exact operation facts:

SOURCE_ENCODING: WINDOWS-1252-INCOMPATIBLE
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: <exact zero-based absolute physical source-byte offset>
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE

WINDOWS-1252-INCOMPATIBLE is the exact SOURCE_ENCODING token for this governed CONVERT refusal. OUTPUT_FILENAME: NONE means the operation definitively established that no CVT was published for the event. No CVT candidate may be reported as output.

The compatibility scan reports the first undefined byte only. Later undefined bytes do not replace that offset. Permitted changes in scan buffer/window size or boundary placement must not change the reported absolute offset.

SOURCE_ENCODING: UTF-8
UNDEFINED_WINDOWS_1252_BYTE_OFFSET: NOT_RUN
MATERIALIZED_ENCODING: NOT_RUN
TRANSCODING: NOT_RUN
SOURCE_CHANGED: NO
OUTPUT_FILENAME: NONE

CATALOG_STORES

1. CATALOG_ENTRY_COUNT
2. CATALOG_FILENAME

On success, CATALOG_ENTRY_COUNT equals the number of data rows in the published CAT. CAT itself is the only new non-Receipt governed artifact produced by the operation.

RECOVER RID / RECOVER_RID is not a valid executable WASM-002 operation in Revision BM.

The Receipt records what Data Sculptor actually attempted, observed, refused, and successfully published. It must not reinterpret the analyst's WKO, replace the Store MAP, or become a second analytical command surface.

The WKO remains the durable authorization record; Store MAP/RID/COL artifacts remain the governed analytical state; diagnostic events remain the refusal/help truth; the Receipt cross-references those facts as the durable run ledger. The body of published canonical RCP artifacts is the authoritative evidence substrate for the Flight Recorder logical view defined in W002-STOR-012.

Data Sculptor must never claim that a durable Receipt exists until the RCP file has been successfully written and closed in the Suitcase. If host or filesystem failure prevents Receipt publication, the browser must surface a canonical diagnostic through the Help Engine stating that receipt evidence could not be persisted.

A receipt-publication failure does not retroactively falsify analytical artifacts that were already successfully committed under their own publication contracts, but the user-facing run summary must clearly distinguish analytical outcome from receipt-persistence failure. Data Sculptor must not invent, backdate, or silently reconstruct a Receipt and present it as the original run artifact.

F-14 publication path, reconciled by F-33: the RCP itself is first written as the corresponding SCR candidate under W002-STOR-023.1, closed, reopened and validated against the exact Receipt serialization/key contract before the class-token rename to RCP. If final RCP promotion fails, the candidate remains non-authoritative SCR evidence. Help may identify the exact retained SCR filename when that fact was established, but it must still state that the canonical Receipt was not persisted. WASM-002 does not emit an RCV artifact for this failure.

A Store-establishing materialization fixture must run one saved WKO, publish exactly one canonical TXT RCP, and prove that the Receipt identifies the exact WKO through WORK_ORDER_FILENAME, source, RID_ACTION: CREATED, new RID, Stage 1 result/bytes/time, Stage 2 row count/time, all requested COL artifacts in resolved KEEP order, successor Store MAP, published-artifact count, timestamps, and RESULT: SUCCESS. The RCP filename UTC must represent the Receipt artifact's own creation/publication event and must not be required to equal the WKO filename UTC.

The same immutable WKO must then be executable again in an appropriate fixture, producing a second distinct RCP with its own Receipt/run timestamps while both Receipts contain the same exact WORK_ORDER_FILENAME. A later same-Store materialization fixture must additionally prove RID_ACTION: REUSED and the original RID filename.

The Store-establishing fixture must also prove that the newly created RID, every newly created COL, and the successor MAP carry one identical publication-transaction UTC token while each has a distinct UUID; the RCP filename UTC remains its own Receipt publication timestamp and is not required to equal that analytical transaction UTC. A later same-Store materialization must prove that newly created COLs and its successor MAP share the later transaction UTC while the inherited RID retains its original timestamp/UUID.

F-07 Stage-1 success fixture: a successful materialization Receipt must serialize STAGE1_UTF8_OUTCOME: PASS, with UTF8_FIRST_INVALID_BYTE_OFFSET: NOT_APPLICABLE and UTF8_STOP_REASON: NOT_APPLICABLE. Separate refusal fixtures under W002-RCP-ACC-002 must prove FAIL plus the mandatory exact offset and INVALID_UTF8_SEQUENCE.

F-20 maximum-width Receipt acceptance: a successful full-width materialization fixture must prove that published-COL indexed keys continue through PUBLISHED_COL_16384_FILENAME using the minimum-three-digit/no-maximum suffix rule. Oversized-header fixtures must prove the exact fallback count, source ordinal, assigned operational name, and SOURCE_HEADER_EXCEEDS_1024_SCALARS reason without embedding the oversized source-header text in the Receipt merely as fallback evidence.

F-23 additional successful-Receipt coverage: acceptance must include a successful INVENTORY run whose RCP carries the exact governed INVENTORY operation-specific facts and a successful UPDATE_ALIASES run whose RCP carries the exact BASE_MAP_FILENAME and SUCCESSOR_MAP_FILENAME while reporting only actually published artifacts in the common created-artifact tail.

F-23 UUID-collision seam: using a controlled UUID sequence, acceptance must force one or more governed filename collisions before successful allocation. Every pre-existing colliding artifact must remain byte-for-byte unchanged; allocation must retain the originally established governed UTC context while changing only the not-yet-created UUID as permitted; and the published Receipt must report the exact retry count in IDENTITY_COLLISION_RETRIES.

Day 060 H-09 success-timeline acceptance

Every retained successful Receipt fixture must satisfy the W002-RCP-006 temporal invariant using its actual embedded UTC tokens. Acceptance must mechanically prove:

• the invoked WKO UTC is less than or equal to RUN_STARTED_UTC;
• every non-Receipt governed artifact successfully published by that Run has a governed artifact/transaction UTC between RUN_STARTED_UTC and RUN_FINISHED_UTC, inclusive;
• RUN_FINISHED_UTC is less than or equal to the Receipt filename/RECEIPT_UTC; and
• no fixture relies on an artifact timestamp that occurs after the Receipt that claims it, or before the Run that created it.

A controlled-clock acceptance seam may be used to make equality and strict-order cases deterministic, but the fixture generator must not alter timestamps after the fact merely to satisfy the checker.

Day 060 H-11 successful RID_ACTION acceptance

A successful new-Store materialization Receipt may report RID_ACTION: CREATED only because the RID was actually promoted into its final governed RID identity during that Run. A successful existing-Store materialization Receipt reports RID_ACTION: REUSED and the exact inherited RID filename; no new RID candidate is created for that Run.

A saved WKO that is actually Run and deterministically refuses must still produce one canonical TXT Receipt when Receipt publication itself remains available. The emitted bytes must conform to the closed RESULT vocabulary, the four governed absence tokens, the exact operation-specific key spelling/order, and the refusal matrix in W002-RCP-006 through W002-RCP-008.

Acceptance must include byte-exact golden Receipt fixtures for every distinct refusal-boundary row required to exercise the serialization matrix for each of the seven executable WASM-002 operations: MATERIALIZE, INVENTORY, UPDATE_ALIASES, REPAIR_MAP, REPAIR_WORK_ORDER_REGISTRY, CONVERT_WINDOWS_1252_TO_UTF_8, and CATALOG_STORES. Multiple Diagnostic IDs that map to the same refusal boundary and the same serialization row do not require duplicate byte fixtures merely because the Diagnostic ID differs.

Acceptance must additionally include one byte-exact UNKNOWN_OPERATION refusal fixture proving the common envelope, OPERATION: UNKNOWN_OPERATION, RESULT: REFUSED, the exact diagnostic ID, absence of any operation-specific section, and immediate CREATED_ARTIFACT_COUNT: 0.

Fixtures must prove that NONE, NOT_RUN, NOT_AVAILABLE, and NOT_APPLICABLE retain distinct meanings; an established zero count is serialized as 0; no candidate filename is reported as a published identity; and every indexed key uses its complete frozen name and the minimum-three-digit/no-maximum suffix rule.

An unsaved WIP must be proven unable to Run and therefore must not create an execution Receipt.

F-16 materialization-refusal fixtures: byte-exact MATERIALIZE refusal Receipts must exercise the new compatibility pair in all four applicable states: NOT_RUN when Stage 1 did not fail; COMPATIBLE plus NOT_APPLICABLE offset; INCOMPATIBLE plus the exact first undefined-byte offset; and NOT_AVAILABLE / NOT_AVAILABLE when an independent compatibility-read failure prevents a conclusion.

F-23 Receipt-publication failure fixture, reconciled by F-33: a controlled filesystem-fault seam must make canonical RCP publication fail after the underlying analytical/refusal outcome has been established. Acceptance must prove the W002-RCP-010 boundary exactly: no final RCP is fabricated or claimed, any retained candidate evidence follows the governed SCR retention/non-authority rules in W002-STOR-023.1, no RCV artifact is emitted, the user-facing diagnostic distinguishes analytical outcome from Receipt-persistence failure, and already committed analytical artifacts are not retroactively falsified solely because RCP persistence failed.

F-23 ultimate identity-allocation failure fixture: with Receipt publication itself still available, a controlled identity-allocation seam must force a governed operation artifact to exhaust/fail safe allocation. The operation must refuse without overwriting or mutating any colliding pre-existing artifact, and the refusal Receipt/diagnostic evidence must preserve the established collision/allocation-failure facts under PB-STOR-011 and W002-STOR-007.3.

Day 060 H-02 fixture binding: the retained golden corpus must use RECEIPT_VERSION: 1 and the fixture-pinned diagnostic allocations in W002-HELP-001.8. The corpus must contain one success Receipt for each of the seven executable operations, one refusal Receipt for every distinct refusal-boundary row in W002-RCP-007/W002-RCP-008, the three additional Stage-1 compatibility variants needed to cover COMPATIBLE, INCOMPATIBLE, and NOT_AVAILABLE after UTF-8 failure, and one UNKNOWN_OPERATION Receipt. Publication-refusal fixtures may use the operation-specific H-02 publication diagnostic and a non-zero IDENTITY_COLLISION_RETRIES value to satisfy the ultimate identity-allocation-failure acceptance boundary without inventing a second diagnostic solely for the same serialization row.

Day 060 H-09 refusal-timeline acceptance

Every retained refusal Receipt fixture must also satisfy the W002-RCP-006 temporal invariant. For a refusal with no successfully published non-Receipt artifact, acceptance proves WKO_UTC ≤ RUN_STARTED_UTC ≤ RUN_FINISHED_UTC ≤ RECEIPT_UTC. If a refusal legitimately leaves one or more successfully committed non-Receipt artifacts from an already-completed stage, each such artifact UTC must fall between Run start and Run finish and must be listed truthfully under the governing created-artifact rules.

Day 060 H-11 / BM-08 RID_ACTION refusal acceptance

Byte-exact MATERIALIZE refusal acceptance must distinguish new-Store and existing-Store RID paths:

• new-Store validation, Stage 1, Stage 2, and post-Stage-2 gate refusals before successful RID promotion serialize RID_ACTION: NOT_RUN and do not serialize a candidate as a published RID;
• a controlled new-Store refusal after RID promotion has successfully completed may serialize RID_ACTION: CREATED together with the exact published RID filename, but only if that RID was actually promoted and the remaining refusal/rollback evidence is truthful under the publication rules;
• an existing-Store refusal after the inherited RID has been selected and validated serializes RID_ACTION: REUSED and the exact inherited RID filename even when Stage 1, Stage 2, a later gate, or publication subsequently refuses;
• an existing lineage whose required inherited RID cannot be validly established serializes RID_ACTION: NOT_AVAILABLE and RID_FILENAME: NOT_AVAILABLE rather than claiming reuse.

Acceptance must specifically reject the historical H-02 fixture pattern that reported RID_ACTION: CREATED while no RID existed and CREATED_ARTIFACT_COUNT: 0.

Day 060 H-12 H-02 publication-diagnostic scope

The H-02 operation-specific publication diagnostics whose required facts are artifact_class and collision_retry_count are acceptance pins for governed filename identity-allocation collision exhaustion. They are not catch-all Diagnostic IDs for unrelated publication failures such as chronology guards, write/close/rename failures, or malformed predecessor state. Those distinct conditions use their own registry allocations; DS-UTC-001 is independently frozen for the strict monotonic-UTC guard.

Day 060 H-13 / BM-10 zero-byte and BOM-only NO_HEADER_RECORD Receipt fixtures

The retained golden corpus must contain two distinct byte-exact MATERIALIZE refusal Receipts for the P3-09 no-header boundary:

• Zero-byte source: the bound source has exact certified byte count 0; Stage 1 passes; Stage 2 refuses with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD; CSV_SOURCE_BYTE_OFFSET: 0; CSV_PHYSICAL_LINE: 1; CSV_LOGICAL_RECORD: 1; and CSV_FIELD_ORDINAL: 1.
• UTF-8-BOM-only source: the bound source consists exactly of bytes EF BB BF and has exact certified byte count 3; Stage 1 passes; Stage 2 refuses with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD; CSV_SOURCE_BYTE_OFFSET: 3; CSV_PHYSICAL_LINE: 1; CSV_LOGICAL_RECORD: 1; and CSV_FIELD_ORDINAL: 1.

These two Receipt fixtures must carry their own truthful source filenames, Work Order identities, run timestamps, Receipt identities, and other governed facts. Only the five-field CSV refusal tuple has the narrower relationship stated in W002-RCP-007; the complete Receipt files are not otherwise required to be byte-identical.

Day 060 H-14 / BM-11 CONVERT undefined-byte Receipt binding

The coordinated golden Receipt corpus must include the byte-exact CONVERT_WINDOWS_1252_TO_UTF_8 refusal fixture from W002-CONV-ACC-002 using source bytes 41 81 42. Its Receipt must carry UNDEFINED_WINDOWS_1252_BYTE_OFFSET: 1 and the exact pre-transcoding refusal values frozen in W002-RCP-008.

The same governed run must be exercised under materially different permitted browser presentation states. In each case the run Receipt must remain an RCP TXT artifact governed by the same receipt serialization and facts. Presentation must not convert it to HTML or alter execution truth in WASM-002.

This acceptance gate does not require a configurable Brand Manifest; that capability is deferred.

The Suitcase is a workspace and may contain zero, one, or multiple logical Stores. Every committed Store state binds exactly one governed current RID artifact. RID values are unique only within their Store row universe; they are not Suitcase-global identifiers.

Ordinary same-row-universe work reuses that RID unchanged. In WASM-002, a missing, unreadable, or invalid current RID makes the Store INVALID; no executable WASM-002 operation regenerates or substitutes that RID. Read-only Help/evidence may explain analyst-owned restoration or lineage-retirement choices, but Data Sculptor does not publish a replacement RID.

The stable logical row reference in WASM-002 is conceptually (Store lineage, RID value); the current physical RID identity is the exact rid_filename bound by the authoritative MAP.

When the first successful materialization establishes a new Store, Data Sculptor must automatically generate that Store's initial RID artifact as part of the same Stage 2 operation and the same all-or-refuse publication boundary. The analyst does not separately request ordinary RID generation.

Before the RID SCR candidate is created, Data Sculptor establishes the materialization publication-transaction UTC under PB-STOR-013/PB-STOR-014 and allocates a RID-specific UUID. The canonical RID byte stream is then written as the visible governed SCR candidate whose filename already carries that exact UTC, UUID, and .csv extension intended for the final RID identity. Requested materialized columns likewise begin as governed SCR candidates whose distinct COL-specific UUIDs are allocated before those candidates are opened under the same transaction UTC. The new RID candidate and all requested COL candidates must reach EOF, reconcile to the same accepted Store row count N, and pass their required final validation before any candidate is promoted.

After complete-set validation, Data Sculptor promotes the RID candidate first by host rename that changes only the three-letter semantic class token from SCR to RID. The candidate bytes, UTC token, UUID, and .csv extension must remain unchanged across that promotion. Requested COL candidates are promoted only after RID promotion succeeds. If later promotion or successor-MAP publication prevents transaction commit, the newly promoted RID is not committed Store state merely because an RID-looking file exists; it must be rolled back where safely possible or retained as attributable recovery evidence under the materialization failure contract.

A first Store-establishing materialization commits exactly one RID regardless of how many requested COLs are materialized. Later ordinary materializations and other same-row-universe WASM-002 operations must reuse that RID unchanged. They must not create a new RID candidate, regenerate, replace, renumber, or silently supersede the inherited RID.

RID reconstruction/replacement is not an executable WASM-002 operation. Any future governed RID-recovery design remains deferred and must be reintroduced by an explicit later PRD freeze.

The physical RID filename must be:

__DS__RID__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv

The filename contains governed physical identity only. A Store name or friendly analyst alias must not be inserted into, substituted for, or used to rename this immutable physical RID filename.

The RID artifact must serialize as a canonical one-column UTF-8 CSV with:

• exactly one UTF-8 BOM at byte zero;
• a structural first logical record exactly N=<value>, where <value> is the canonical unsigned base-10 representation of the Store's total logical data-row count N;
• uppercase N, exactly one equals sign, no spaces, no sign, no leading zeroes except the single digit 0, and no separators or locale formatting;
• LF (0x0A) record terminators on every supported host;
• exactly N data records after the header, containing the consecutive unquoted decimal integers 1 through N in order;
• no zero RID data value, negatives, signs, thousands separators, decimal points, exponent notation, or leading zeroes; and
• a final LF after the last record. For N=0, the canonical bytes are the UTF-8 BOM followed by N=0 and LF, with no data records.

The N=<value> record is structural metadata and does not consume a Store row. The governed RID artifact class/filename and Store MAP binding identify the artifact as a RID; the literal header RID is not used by the frozen WASM-002 serialization.

If a Store RID contains N data records, every governed column claimed to be aligned to that Store must contain exactly N data records in the same RID order. Data Sculptor must not describe a shorter, longer, reordered, duplicated, or row-shifted column as aligned to that Store.

This invariant applies to materialized source columns in WASM-002 and is the stable contract that later calculated, Boolean-selection, verification, or left-join enrichment columns may rely upon.

An operation that changes which rows exist or changes their governed order does not mutate the existing Store RID. It establishes a different row universe and therefore requires a new logical Store identity and a new RID artifact beginning again at 1 for that new Store.

Filtering that is represented only as a same-length aligned Boolean/selection column does not itself change the row universe; building a new reduced/reordered row set later would.

The physical RID artifact remains identified by its immutable governed filename and semantic RID class. Every valid Store MAP records that exact rid_filename and one current human-facing rid_alias.

Changing the RID alias must not rename, rewrite, regenerate, or alter the meaning of the RID artifact. The same Store MAP also records the Store alias and materialized-column aliases, so the analyst-facing names and the physical Store spine remain explicitly connected in one visible governed artifact.

WASM-002 materialization Work Orders specify the analyst's requested source columns and aliases. They must not require or expose a separate instruction such as RID, ROW INDEX, GENERATE RID, or an equivalent switch to create the Store row spine.

Initial RID generation for a new Store is mandatory engine behavior implied by successful MATERIALIZE. WASM-002 must not provide an option to disable it. When ordinary materialization extends an existing Store, the engine must recognize and reuse that Store's existing RID.

If that bound RID is missing or invalid, the Store is INVALID and ordinary Store operations refuse. WASM-002 exposes no RECOVER RID executable syntax. A future explicit recovery design may be considered in V1-BACKLOG, but it is not part of this build contract.

An acceptance fixture with N=5 must prove exact governed bytes equivalent to a UTF-8 BOM followed by:

N=5
1
2
3
4
5

Every record uses LF termination and the file ends with a final LF. A separate N=0 fixture must prove exact bytes equivalent to UTF-8 BOM + N=0 and no data records. The N=5 fixture repeated under different permitted source-window boundaries must produce byte-identical RID content apart from the governed physical filename allocated to the artifact. Full RID validation must also prove that the declared N, the number of following data records, and the exact sequence 1..N agree.

An acceptance fixture must establish at least two Stores with different row counts in the same Suitcase and prove that each Store publishes and retains exactly one distinct governed RID artifact. RID values may overlap numerically across Stores without collision because the Store identity disambiguates them.

An acceptance fixture must establish a Store with an initial materialization, record the physical RID identity and exact RID bytes, then perform a later permitted materialization that adds at least one aligned COL without changing the row universe. The later run must reference and reuse the original RID artifact; no replacement RID may be published and the original RID bytes must remain unchanged.

Acceptance must execute two Store-establishing Work Orders that contain no RID or row-index syntax: one requesting exactly one source column and one requesting multiple source columns. Each successfully committed run must publish exactly one governed RID artifact regardless of the number of requested COL artifacts.

The fixture must prove that RID creation occurs during the same Stage 2 source-record traversal that establishes the Store row count rather than by requiring a second source pass solely to construct RID. The RID row count must reconcile exactly with every requested COL row count and the final accepted Store N.

Before RID candidate creation, acceptance must prove that the publication-transaction UTC and RID-specific UUID are already established, and that the governed SCR filename carries exactly the UTC, UUID, and .csv extension intended for the final RID identity. Before complete-set validation, the RID bytes must exist only as that governed SCR candidate. Acceptance must prove that the RID candidate is promoted by host rename only after the complete RID/COL candidate set validates, that the physical-name change is exactly the class token SCR to RID, that candidate bytes/UTC/UUID/extension are unchanged across promotion, that RID promotion precedes COL promotion, and that the resulting RID is not considered committed Store membership until the successor MAP is successfully promoted and binds that exact RID filename.

The canonical WASM-002 form is:

SUITCASE: .
WORK ORDER AS "Inventory this Suitcase"
INVENTORY

INVENTORY reads the authorized Suitcase directory metadata and creates one governed Suitcase Inventory Snapshot. It is read-only with respect to pre-existing Suitcase files. In WASM-002, an INVENTORY Work Order must not also request materialization, conversion, fingerprinting, another analytical operation, or another Work Order invocation.

F-08 structure freeze: after the common SUITCASE: . / WORK ORDER AS "..." preamble, INVENTORY is the sole semantic operation clause and is terminal. No SOURCE, MAP, KEEP, alias mutation, conversion, repair, catalog, or composition clause is valid in the same WKO.

A successful inventory produces exactly one visible flat TXT artifact whose physical filename is:

__DS__INV__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt

The UTC and UUID tokens follow the existing governed artifact-identity rules. Data Sculptor must not create an inventory subfolder, hidden cache copy, or alternate private persistence.

F-14 publication: the INV body is produced first under the matching W002-STOR-023.1 SCR identity with the same UTC, UUID and .txt extension intended for the final INV. Publication to INV occurs only after the complete scan and deterministic INV serialization validate successfully.

For every regular file present in the authorized flat Suitcase root at snapshot time, the inventory must record:

• the exact visible filename;
• the exact byte length reported by the host file object; and
• the host/browser-reported last-modified value rendered in the canonical UTC millisecond form when available.

WASM-002 must not claim access to a true file-creation timestamp. It must not infer, fabricate, or substitute a creation time from the last-modified value. If usable last-modified metadata is unavailable, the inventory must represent that fact explicitly rather than invent a timestamp.

P3-10 last-modified availability test: host/browser last-modified metadata is usable only when the host supplies a finite, non-negative whole-number millisecond value that can be represented in the canonical UTC millisecond timestamp form. If that test fails, the inventory must serialize the governed unavailable value rather than infer, round, substitute, or fabricate a timestamp.

The lightweight inventory must be produced from directory enumeration and file metadata only. Data Sculptor must not open and stream the contents of each listed file merely to create the inventory, and it must not compute SHA-256 or another content fingerprint as an implicit side effect.

Its cost should therefore scale primarily with the number of directory entries and metadata calls, not with the aggregate byte size of the files. A 7 GB CSV and a 7 KB CSV each contribute one metadata entry rather than requiring their contents to be read.

WASM-002 inventories regular files and immediate child directory entries in the directory denoted by SUITCASE: .. Data Sculptor must not recursively inspect, enumerate, size, hash, or otherwise inventory the contents of a child directory in this build.

Each immediate child directory is recorded as a directory entry by its exact visible name only. Its nested contents and aggregate size are outside the WASM-002 Inventory contract. This rule preserves the flat-Suitcase storage model while making the presence of user-created directories explicit rather than silently omitting them.

F-26 SOURCE distinction: inclusion in an Inventory is evidence that an entry was physically visible to the Inventory operation; it does not make that entry eligible for a Work Order SOURCE. SOURCE eligibility is the narrower contract in W002-WKO-009.1.

The INV artifact is a deterministic human-readable TXT document encoded as UTF-8 without BOM, using LF (0x0A) line endings, the same KEY: VALUE line grammar, and the same quoted-text escaping rule frozen by W002-RCP-005. Every INV ends with exactly one final LF, contains no trailing spaces, and contains no blank physical lines.

The exact V1 Inventory serialization order is:

1. INVENTORY_VERSION
2. INVENTORY_UTC
3. WORK_ORDER_FILENAME
4. SUITCASE
5. ENTRY_COUNT
6. for each regular-file entry in deterministic ascending exact-filename UTF-8 byte order, one contiguous indexed triplet: FILE_<INDEX>, FILE_<INDEX>_BYTE_LENGTH, FILE_<INDEX>_LAST_MODIFIED_UTC
7. DIRECTORY_COUNT
8. exactly DIRECTORY_COUNT directory-name records using contiguous indexed keys DIRECTORY_<INDEX>, ordered by ascending exact-directory-name UTF-8 bytes.

INVENTORY_VERSION is the unquoted integer 1 for this contract. WORK_ORDER_FILENAME, SUITCASE, each FILE_<INDEX> filename, and each DIRECTORY_<INDEX> name use the common double-quoted UTF-8 text serialization. FILE_<INDEX>_BYTE_LENGTH is the exact non-negative ungrouped ASCII base-10 byte length. FILE_<INDEX>_LAST_MODIFIED_UTC is either the exact canonical UTC millisecond token governed by W002-INV-003 or the unquoted governed absence token NOT_AVAILABLE.

Indexed suffixes are one-based decimal with a minimum width of three digits and no maximum width: 001 through 999 are zero-padded and 1000 onward uses the full ungrouped decimal form. When ENTRY_COUNT or DIRECTORY_COUNT is zero, no indexed lines for that list appear.

ENTRY_COUNT remains the regular-file count. Directory records contain the exact immediate child directory name only and do not imply recursive inspection or a computed directory size. Filename and directory-name representations remain unambiguous even when a name contains whitespace, quotes, or delimiter-like characters because the common quote-doubling rule applies.

P3-10 inventory timestamp binding: INVENTORY_UTC must equal the exact canonical UTC token embedded in the final governed __DS__INV__<UTC>__<uuid-v4>.txt filename, just as RECEIPT_UTC is bound to the governed Receipt filename UTC. The INV body and filename therefore cannot claim different capture times.

Data Sculptor must enumerate and fix the inventory snapshot before publishing the new INV artifact. The INV artifact being created is therefore not one of its own listed entries. Any older INV artifact that already existed at snapshot time is an ordinary Suitcase file and is included like any other file.

This pre-publication rule prevents recursive self-reference while preserving an accurate snapshot of the state that existed immediately before the new inventory evidence was added.

Help must explain that an INV snapshot is useful for ordinary closeout and later orientation: it can reveal additions, removals, renames, size changes, or last-modified changes when snapshots or current metadata are compared. For an unexpected cross-session source problem, Help may direct the analyst to the relevant source entry in an earlier INV and ask whether its filename, exact byte length, or last-modified metadata differs.

Help must also state that unchanged filename/size/last-modified metadata does not prove that file contents or row order are identical. When stronger assurance is warranted because files may change unexpectedly, Help may recommend the explicit later/deeper content-fingerprinting workflow; INVENTORY itself must never imply forensic or cryptographic assurance.

An acceptance fixture must place at least one multi-gigabyte file plus several small files in the authorized Suitcase, execute INVENTORY, and prove that the resulting INV records the correct filename, exact byte length, and last-modified metadata without reading the multi-gigabyte file contents.

Evidence must demonstrate that inventory runtime and memory do not scale with the aggregate bytes of the listed files in the way a fingerprinting pass would.

P3-10 metadata determinism: acceptance must include at least one file with usable host last-modified metadata and one test double/fixture in which the last-modified value fails the governed availability test. The first must serialize the exact canonical UTC millisecond value; the second must serialize exactly NOT_AVAILABLE. The accepted INV must also prove that INVENTORY_UTC exactly matches the UTC token in its final INV filename.

Day 060 H-01 byte oracle: acceptance must include at least one byte-exact INV golden fixture using the complete W002-INV-006 key order, indexed suffix rule, quoted-text escaping rule, UTF-8/no-BOM physical form, LF-only line endings, and exactly one final LF. It must include at least two file records so deterministic filename ordering is observable, including one NOT_AVAILABLE last-modified value, and at least one directory record.

Day 060 H-09 reachable-Suitcase INV golden fixture

The byte-exact INV golden fixture used for WASM-002 review must depict a Suitcase state that could actually execute INVENTORY under the current contract rather than an isolated impossible file list.

At minimum, immediately before the Inventory Run begins, the fixture Suitcase contains:

• one valid current Suitcase Validation Certificate (CER) authorizing the root;
• one structurally valid current WKO registry MAP;
• the exact saved immutable INVENTORY WKO referenced by WORK_ORDER_FILENAME, registered as runnable by that current WKO MAP; and
• the ordinary analyst files used to demonstrate inventory metadata, including the controlled last-modified-available and NOT_AVAILABLE cases.

The INV snapshot is taken before publication of the new INV artifact and before its Receipt publication. Therefore the INV being created and the Receipt for that Run do not appear as pre-existing entries in their own inventory snapshot.

For the retained minimal review fixture, the regular-file ENTRY_COUNT and indexed records must include the CER, current WKO MAP, exact INVENTORY WKO, and the two ordinary sample files, for a total of five regular-file rows, serialized in ascending exact-filename UTF-8 byte order. A later implementation fixture may use different exact governed filenames/UUIDs while preserving the same reachable-state requirement and deterministic ordering.

An acceptance fixture must include ordinary analyst files, existing governed __DS__ artifacts, and at least one older INV artifact. The new inventory must include every qualifying pre-existing root file in deterministic order, include the older INV, and exclude only the newly generated INV because it did not exist in the fixed pre-publication snapshot.

Adding an unrelated PDF or ZIP before a later inventory must appear as an added inventory entry and must not be treated as an analytical error.

Acceptance documentation and Help fixtures must demonstrate the limitation of metadata-only continuity. A case in which a file's bytes are changed while the observed filename, byte length, and last-modified metadata are preserved or restored must not be described as detectable by INVENTORY alone.

The product must direct the analyst toward stronger explicit fingerprint evidence when byte-level assurance is required.

When Data Sculptor saves a new Work Order as a WKO, it shall assign the physical TXT filename. The analyst chooses the validated Suitcase but is not asked to choose or edit the WKO filename.

The exact WKO filename shape is __DS__WKO__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt, using UTC at millisecond precision with exactly three millisecond digits and a canonical lowercase hyphenated UUID v4. UTC precedes UUID. If the generated name collides with an existing artifact, PB-STOR-011 governs UUID regeneration and safe retry. The saved WKO thereafter retains that physical identity and remains immutable under W002-STOR-017.

After a Work Order TXT artifact is saved, Data Sculptor shall not edit, overwrite, or rename that saved Work Order in place. Changing analytical instructions requires saving a new Work Order artifact with a new governed physical identity.

A human-facing Work Order name is required immutable Work Order content for every executable/saved WASM-002 WKO, not separately editable browser metadata. The canonical declaration is WORK ORDER AS "<alias>" under W002-STEPS-001.1. The quoted alias must be non-empty UTF-8 text and may contain spaces and ordinary phrase punctuation subject to the governed string-literal rules.

After the WKO TXT artifact is saved, Data Sculptor shall not edit the alias in place. Changing the alias, analytical instructions, or comments means creating and saving a new immutable WKO with a new governed physical identity. The physical WKO filename/UUID remains execution identity; the alias is human-facing metadata for display and governed name resolution.

The browser must not maintain a separate mutable Description field or hidden description store. The alias declared by the WKO is also represented in the current governed WKO MAP under W002-STOR-018.1 through W002-STOR-018.4.

Revision BB does not add a new semantic artifact class. The existing MAP class has two explicitly distinguished governed profiles:

• Store MAP — the existing exact eight-column Store/RID/COL snapshot governed by W002-STOR-019 through W002-STOR-019.12;
• WKO MAP — a complete immutable snapshot that maps saved Work Order aliases and lifecycle status to exact immutable WKO filenames.

Profile classification is determined by the exact CSV header before profile-specific validation. A valid WKO MAP must never be treated as an eligible Store MAP, and a Store MAP must never be treated as a WKO alias registry. Both remain visible flat-Suitcase MAP artifacts under the canonical immutable filename grammar.

The canonical WKO MAP is UTF-8 CSV without BOM, using LF record termination, with exactly this three-field header:

wko_status,wko_alias,wko_filename

Each row identifies one immutable governed WKO represented in that registry snapshot. wko_status is exactly CURRENT or DEPRECATED. wko_alias is the exact mandatory non-empty alias declared by that WKO's WORK ORDER AS clause. wko_filename is the exact governed physical WKO filename.

Rows are written deterministically by ascending exact UTF-8 byte order of wko_filename. Duplicate wko_filename rows are invalid. Standard governed CSV quoting applies.

For any exact wko_alias value, at most one row may have wko_status=CURRENT; zero or more older rows for that same alias may have wko_status=DEPRECATED. Alias resolution uses the CURRENT row only. A WKO represented by a DEPRECATED row remains immutable historical evidence and is not renamed, rewritten, or deleted merely because its alias target was superseded. A WKO MAP containing more than one CURRENT row for the same exact alias is structurally invalid.

Saving a new immutable WKO begins from the current structurally valid WKO MAP in the Suitcase, or an empty WKO registry if no structurally valid WKO MAP exists. Data Sculptor validates the draft, including its mandatory non-empty WORK ORDER AS alias and comment syntax, and checks the governed alias/lifecycle constraints before commit.

F-02 alias-lifecycle decision: if no CURRENT row in the predecessor WKO MAP uses the new WKO's exact alias, the successor registry adds the new WKO as CURRENT. If exactly one CURRENT row already owns that exact alias, Data Sculptor must present exactly two analyst choices before registry commit: Replace alias target or Cancel. Replace alias target constructs the successor WKO MAP by changing the former owner's row to DEPRECATED and adding the newly saved WKO as the sole CURRENT row for that alias; any older DEPRECATED rows remain unchanged. Cancel leaves the predecessor WKO MAP authoritative and does not commit the pending WKO/WKO-MAP pair as a registry update. Data Sculptor must not silently replace the alias target, auto-suffix the alias, or choose between competing owners. A predecessor WKO MAP with more than one CURRENT row for the same alias is structurally invalid under W002-STOR-018.2 and cannot be used as save authority.

The former CURRENT WKO and every prior WKO MAP remain byte-for-byte immutable after replacement. Supersession changes only the lifecycle metadata represented in the newly published successor WKO MAP; it does not edit, rename, delete, or rewrite the historical WKO artifact.

F-14 WKO publication predicate: the new immutable Work Order is first written under the W002-STOR-023.1 SCR identity using the UTC, UUID and .txt extension intended for its final WKO identity. The complete candidate is closed, reopened and validated as a saved WKO: required common preamble, exactly one non-whitespace WORK ORDER AS alias, governed lexical/comment rules, and complete parse under exactly one current WASM-002 executable operation grammar. Only then may the candidate be renamed from SCR to WKO. Save-time current-registry, alias-lifecycle and lifecycle gates remain transaction preconditions. A valid promoted WKO is not yet alias-registry authority; the successor WKO MAP promotion remains the save-transaction commit point.

The WKO is persisted as a new immutable governed WKO artifact and the complete successor WKO MAP is constructed under SCR, closed, reopened, and validated for WKO MAP structural validity: exact profile/schema, exact governed serialization, filename/profile rules, lifecycle-row constraints, and internal row constraints. Whether every referenced physical WKO file is presently visible is a separate registry-health/publication check and is not part of WKO MAP structural validity. For an ordinary successful save transaction, every WKO referenced by the successor registry must be present at publication.

The successor WKO MAP is promoted to MAP last; that successful MAP promotion is the alias-registry commit point for the save transaction. The WKO and successor WKO MAP created by one successful save transaction use one shared canonical transaction UTC while retaining distinct UUIDs.

If successor WKO-MAP structural validation, referenced-file publication checking, or publication itself fails, the save must not be represented as a successfully committed alias-registry update. Data Sculptor must roll back the new WKO out of committed WKO state where safely possible or retain visible non-authoritative SCR failure evidence and report the failure through Help.

F-02 repair-only bootstrap and stale-registry Save boundary

When the current WKO registry is repair-required under W002-STOR-018.4, Data Sculptor may save one ordinary visible immutable WKO whose sole semantic operation is exactly REPAIR WORK ORDER REGISTRY. That 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 WKO must be structurally valid under the predicate below, must contain exactly one mandatory non-empty WORK ORDER AS, and must contain exactly the governed registry-repair operation and no second operation.
• The exception does not grant alias-based Run authority. The repair WKO is invoked only by exact physical WKO filename.
• No other visible but unregistered WKO gains Run eligibility from this exception.
• The exception ends once registry repair successfully publishes the successor WKO MAP.
• This is the sole WASM-002 bypass of ordinary current-registry membership for Run eligibility.

Because the registry is already stale, Save of the repair-only WKO does not claim that the WKO has been registered, does not commit an ordinary successor WKO MAP, and does not represent the stale registry as healthy. The new immutable WKO remains visibly unregistered until the repair operation successfully publishes the successor WKO MAP containing its row. Save does not silently perform registry repair.

F-02 governed WKO structural-validity predicate

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 executable Work Order 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; and
• 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.

P3-10 repair-bootstrap timing: during REPAIR WORK ORDER REGISTRY, the saved repair-only WKO participates in the bounded discovery performed by that repair run. It is not first “discovered after success.” Its governed registration becomes durable only when the complete successor WKO MAP containing that WKO row is successfully committed. Discovery during the run and registration in the committed successor registry are distinct events.

P2-03 WKO-registry chronology guard: before a save or registry-repair transaction publishes a successor WKO MAP, Data Sculptor establishes the truthful observed transaction UTC and compares it with the chronology predecessor defined by W002-STOR-018.4. The observed UTC must be strictly greater. Equal or earlier UTC refuses before the new WKO/WKO-MAP pair is committed; Data Sculptor must not fabricate a later timestamp, silently wait/retry, skip the predecessor, or select an older registry merely to make publication succeed.

F-13 single-writer pre-commit guard: immediately before the successor WKO MAP promotion that would commit the alias-registry update, Data Sculptor re-resolves the current WKO-registry authority and compares the relevant governing state with the state from which this transaction was derived. If another writing context or external filesystem action has changed that relevant authority, the transaction refuses publication. It must not overwrite the newer registry, silently rebase the pending save, or choose an older registry to make the commit succeed. The existing rollback / attributable SCR recovery-evidence rules apply to any WKO or candidate bytes already produced.

If the save later refuses and an SCR candidate or other attributable staged evidence cannot be safely removed/restored, W002-STOR-023.1 governs retained SCR evidence and its non-authority boundary; WASM-002 does not emit RCV. An unregistered final WKO left by a failure is a valid immutable WKO artifact but does not become current registry authority merely by existing; the WKO MAP remains authoritative.

WKO MAP structural validity is distinct from registry health. A WKO MAP is structurally valid when the MAP artifact itself satisfies the governed WKO MAP profile/schema, serialization, filename/profile rules, lifecycle-row constraints, and internal row constraints. The present existence of every physical WKO file named by its rows is not part of WKO MAP structural validity.

Only structurally valid WKO MAP artifacts participate in current-registry selection. Among structurally valid WKO MAPs, the one with the greatest canonical UTC millisecond timestamp is the current WKO MAP snapshot and therefore the current governed Work Order alias registry. If two or more structurally valid WKO MAPs share that greatest timestamp, current-registry selection must refuse rather than break the tie by UUID, discovery order, filesystem modified time, or directory order.

Registry-snapshot authority is distinct from alias-target status inside that snapshot. After the current WKO MAP snapshot is selected, an alias resolves only to its exact row whose wko_status is CURRENT. Rows marked DEPRECATED remain visible historical registry evidence but are not alias-resolution targets. The registry must never use the greatest WKO filename UTC, filesystem modified time, or discovery order to choose between rows for an alias. More than one CURRENT row for the same exact alias makes that WKO MAP structurally invalid under W002-STOR-018.2.

If a newer WKO MAP artifact is structurally malformed, it never becomes current. Data Sculptor uses the greatest earlier structurally valid WKO MAP, if one exists, and reports the malformed newer artifact through Help/evidence surfaces. A malformed newer WKO MAP does not itself make the selected earlier registry repair-required.

The current WKO registry is repair-required exactly when the current structurally valid WKO MAP contains one or more rows whose referenced physical WKO files are missing from the Suitcase. Such a MAP remains current; Data Sculptor must not silently fall back to an older WKO MAP merely because a referenced WKO is missing. This preserves the latest registry authority while making the damage explicit and reachable through the governed REPAIR WORK ORDER REGISTRY path.

F-02 deterministic registry reconciliation

REPAIR WORK ORDER REGISTRY reconciles the current WKO MAP against visible WKO artifacts in the Suitcase and constructs one complete successor WKO MAP deterministically:

1. Remove every row from the successor whose referenced physical WKO file is missing. A missing WKO is never reconstructed, inferred, copied from history, or replaced automatically by a deprecated WKO.
2. Discover visible structurally valid WKOs that are absent from the current WKO MAP.
3. If no surviving CURRENT row owns a discovered WKO's exact alias, register that discovered WKO as CURRENT.
4. If a surviving CURRENT row already owns that exact alias, register the discovered WKO as DEPRECATED; existing current authority is not silently displaced.
5. If two or more previously unregistered structurally valid WKOs share the same alias and no surviving CURRENT owner exists, register all of those discovered WKOs as DEPRECATED. Data Sculptor must not choose a winner by UTC, filename, UUID, directory order, discovery order, or filesystem modified time.
6. The repair WKO itself participates in the same discovery and registration process during the repair run. Its registration becomes durable only when the complete successor WKO MAP is committed.

Predecessor WKO MAPs and surviving WKO files remain immutable historical evidence. Successor rows remain serialized in ascending exact UTF-8 byte order of wko_filename under W002-STOR-018.2.

Day 060 H-10 / BM-07 registry-repair change-set counts

The registry-repair operation distinguishes the successor registry state from the change set produced by this repair Run. The Receipt's REGISTERED_CURRENT_* and REGISTERED_DEPRECATED_* fields describe only the latter.

• REGISTERED_CURRENT_COUNT is the exact number of previously unregistered structurally valid WKO files newly added by this repair Run with wko_status=CURRENT.
• REGISTERED_CURRENT_WKO_<INDEX>_FILENAME lists exactly those newly registered CURRENT WKOs, ordered by ascending exact UTF-8 filename bytes.
• REGISTERED_DEPRECATED_COUNT is the exact number of previously unregistered structurally valid WKO files newly added by this repair Run with wko_status=DEPRECATED.
• REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME lists exactly those newly registered DEPRECATED WKOs, ordered by ascending exact UTF-8 filename bytes.
• Surviving rows that were already present in the base WKO MAP are not counted in either REGISTERED_* total, even though they appear in the successor WKO MAP.
• Rows removed because their referenced WKO is missing are represented only by REMOVED_STALE_ROW_COUNT and the corresponding stale-WKO filename list; they are not also reflected in either registered count.
• The bootstrap repair WKO participates exactly like any other newly discovered structurally valid unregistered WKO. If the repair commits it, that exact WKO must appear in one and only one of the two registered filename lists according to the ordinary alias-ownership rules.

These counts therefore answer “what did this repair register?” rather than “how many CURRENT/DEPRECATED rows exist in the resulting registry?”.

F-02 Run eligibility and alias authority

• 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, to support deliberate historical reproduction.
• An unregistered WKO may not Run merely because its file is visible, except for the single bounded repair-only bootstrap in W002-STOR-018.3.

The browser may use the current structurally valid WKO MAP to show human-facing Work Order aliases together with read-only CURRENT/DEPRECATED lifecycle state while keeping exact physical WKO filenames visible/inspectable. Future Work Order composition may use the same registry to resolve a non-empty alias to exactly one immutable WKO artifact through its sole CURRENT row. This requirement does not pull deferred Work Order invocation/orchestration grammar into WASM-002; it establishes the governed alias-registry selection, lifecycle, and repair boundary that later composition can depend on.

F-08 REPAIR WORK ORDER REGISTRY Work Order structure:

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

After the common preamble, REPAIR WORK ORDER REGISTRY is the sole semantic operation clause and is terminal. It takes no analyst-supplied SOURCE, Store MAP, alias-mutation list, column selector, conversion source, or catalog clause. Its bounded unregistered-repair bootstrap remains governed by W002-STOR-018.3. The DS-STEPS phrase is distinct from the Receipt operation token REPAIR_WORK_ORDER_REGISTRY.

P2-03 chronology predecessor: for any WKO-registry successor publication, the chronology predecessor is the unique current structurally valid WKO MAP immediately before that publication transaction. It is the MAP selected by the current-registry rule above, not an older registry used for inspection and not a filesystem-modified-time surrogate. If no structurally valid WKO MAP exists and the operation is legitimately establishing the first governed registry state, there is no predecessor UTC.

Future-dated current WKO MAP: a structurally valid current WKO MAP whose governed UTC is later than truthful observed host UTC remains the current registry; the timestamp conflict does not by itself make the MAP malformed or repair-required. Successor WKO-MAP publication is blocked until the monotonic UTC precondition can be satisfied. Help must identify the exact blocking WKO MAP and explain the analyst-owned exits: correct an incorrect host clock; wait/rerun after truthful time advances beyond the predecessor; or, when the analyst deliberately determines that the active future-dated WKO MAP should no longer govern the Suitcase, move that exact MAP out of the active Suitcase root and reopen/rescan. That filesystem action is not a Data Sculptor repair operation. It may expose an older structurally valid WKO MAP as current, and restoring the moved future-dated MAP to the active Suitcase may make it current again under the ordinary greatest-UTC rule.

Each valid WASM-002 MAP is one complete immutable Store snapshot in the same flat Suitcase. Store state is not stored in hidden browser persistence and is not represented by a mutable well-known singleton.

Each successful Store-establishing materialization or later governed Store-metadata/materialized-column update publishes a new immutable MAP under the canonical __DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv identity grammar. Earlier MAP artifacts remain visible history and are not overwritten or deleted merely because a newer Store state is created.

Day 057 CAT reconciliation: the one-Store-per-MAP invariant is unchanged. A collection of independently MAP-governed Stores may additionally be summarized by a governed CAT Store Catalog for collection-level discovery and orientation. CAT does not govern Store semantics, lineage, health, repair, inheritance, or current-MAP selection. MAP remains authoritative for each Store.

Each governed Work Order may explicitly identify at most one valid immutable Store MAP as its Store/inheritance base. If more than one MAP is explicitly specified, Data Sculptor must refuse before Store resolution, alias resolution, materialization, or mutation.

An explicitly named valid MAP binds the run to exactly the Store identified by that MAP's rid_filename and overrides automatic Store-MAP discovery even when newer MAPs for that Store or other Stores exist.

If a materializing Work Order does not explicitly identify a MAP, Data Sculptor must compare the exact Work Order SOURCE filename with the one common exact source_filename carried by every row of each routable Store lineage's structurally valid Store MAP. That common source_filename is the Store lineage's source identity for WASM-002 routing. The redundant ninth Store-source field from the superseded profile is not part of the canonical Store MAP.

P3-07 routing term: for automatic source routing, a routable Store lineage is a Store lineage for which at least one structurally valid Store MAP exists, regardless of whether the lineage currently evaluates VALID, DEGRADED, or INVALID. Routing discovery must use this term rather than the ambiguous word eligible. Store health is evaluated only after the lineage has been discovered.

• If no routable Store lineage exists for the exact source filename, Data Sculptor may establish a new Store with a new RID and first Store MAP only if the active Suitcase contains no structurally malformed Store-MAP-class artifact.
• If exactly one routable Store lineage exists, Data Sculptor routes to that lineage. If its current state permits materialization, the current governed Store MAP is the inheritance base; if its current state is DEGRADED or INVALID, ordinary materialization refuses under the damaged-lineage rules below.
• If more than one distinct routable Store lineage exists for the same exact source filename, automatic inheritance must refuse rather than guess which Store the analyst intended. The analyst must explicitly select one permitted MAP.

All-Store-MAPs-damaged guard: if exact-SOURCE routing finds no routable Store lineage but one or more structurally malformed Store-MAP-class artifacts are present in the active Suitcase, ordinary materialization must refuse before creating a new Store or RID. Data Sculptor must not infer that the absence of a structurally valid Store MAP proves that no prior Store lineage existed. Help must identify the malformed Store MAP artifact or artifacts that caused this guard. A damaged MAP therefore cannot silently turn Store damage into permission to create a replacement lineage.

Store lineages are distinguished by their governed lineage identity. Current-MAP selection and Store-health evaluation are separate governed questions under this requirement and W002-STOR-019.10. If two or more structurally valid current MAP candidates for the one routed Store share the greatest canonical UTC millisecond timestamp, automatic inheritance must refuse rather than infer chronology from UUID, directory order, filesystem modified time, or discovery order.

F-03 canonical evaluated Store-health states

Store health is evaluated from the current structurally valid Store MAP and the presently visible governed artifacts it references, using the applicable validation tier in W002-STOR-019.10. WASM-002 has exactly three evaluated Store-health states:

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

There is no fourth ABANDONED Store-health status in WASM-002.

F-03 status is evaluated, not persisted

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

While a Store evaluates INVALID, Data Sculptor exposes no governed Store-recovery operation for that Store and never regenerates, substitutes, or infers a replacement RID. If the exact governed RID physical identity becomes visible again through analyst-owned external restoration and passes the validation tier required by the next operation, the Store is re-evaluated from the visible governed artifacts and may become VALID or DEGRADED. That is re-evaluation, not RID recovery by Data Sculptor.

F-03 strict DEGRADED operation gate

When a Store evaluates DEGRADED, REPAIR MAP is the only enabled Store mutation operation for that lineage.

• ordinary materialization into that Store refuses;
• extension with new columns refuses;
• alias mutation refuses;
• transformations and other Store mutations refuse;
• read-only Help, Inventory, status/orientation surfaces, CAT orientation, and evidence inspection remain available subject to their own contracts.

F-03 no damaged-lineage fork

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

Damaged-lineage routing: exact SOURCE routing must not treat a known damaged lineage as unseen merely because its current Store state cannot accept ordinary materialization. If routing identifies a DEGRADED or INVALID lineage, ordinary materialization refuses rather than silently creating a replacement Store for that same routed lineage.

Help duty for an all-COLs-broken DEGRADED lineage: when the current structurally valid Store MAP references a valid RID but every mapped non-RID COL is missing or invalid, REPAIR MAP cannot publish a zero-COL successor and must refuse. Help must identify the exact blocked Store lineage and current MAP, then explain these analyst-owned exits: (1) externally restore at least one governed COL artifact under its original physical filename; Data Sculptor then applies the governed validation tier required by the next operation before the artifact can re-enter use, so Store health can be re-evaluated and REPAIR MAP may become available; (2) rename the analyst-owned source and materialize the renamed source to deliberately begin a new Store lineage with a new RID, without repairing, replacing, or erasing the damaged lineage; or (3) retire the damaged lineage from active Suitcase routing by moving all Store MAP artifacts belonging to that lineage out of the Suitcase root. Help must warn that moving only the latest MAP is insufficient because an older structurally valid MAP could otherwise become current.

Help duty for an INVALID lineage: when the current structurally valid Store MAP references a missing or invalid RID, Help must identify the exact blocked Store lineage and current MAP, state that WASM-002 does not silently regenerate or substitute a RID as part of ordinary materialization, and explain these analyst-owned exits: (1) externally restore a governed RID artifact under its original physical filename; Data Sculptor then applies the governed validation tier required by the next operation before the artifact can re-enter use, so Store health can be re-evaluated; (2) rename the analyst-owned source and materialize the renamed source to deliberately begin a new Store lineage with a new RID while leaving the damaged lineage untouched; or (3) retire the damaged lineage from active Suitcase routing by moving all Store MAP artifacts belonging to that lineage out of the Suitcase root, again warning that moving only the latest MAP is insufficient.

Renaming the source and retiring a lineage are distinct analyst choices. Renaming preserves the damaged lineage in the Suitcase and creates a separate lineage under a different source identity. Moving all lineage MAPs out removes that lineage from active routing while preserving the moved artifacts wherever the analyst chooses to keep them. These are analyst filesystem actions, not new Data Sculptor recovery operations.

Assurance boundary: exact source-filename matching in this rule is a Store-routing/orientation mechanism, not proof that an analyst-owned source has identical bytes or row order across separate sessions. Ordinary WASM-002 materialization must not silently represent that filename equality as cryptographic continuity.

P3-08 CVT source-identity boundary: a governed CVT is a new immutable source artifact whose Store-routing source identity is its exact physical CVT filename. Two different CVT filenames are different source identities even when both conversions began from analyst-owned files having the same original filename. WASM-002 does not carry the analyst-owned pre-conversion filename forward as hidden Store-lineage identity and does not infer continuity between separate CVT artifacts. First materialization of a CVT therefore establishes or routes only by that exact CVT filename under the normal rules above.

P2-03 current Store-MAP chronology: within one routable Store lineage, the current structurally valid Store MAP is the unique structurally valid MAP carrying the greatest canonical UTC millisecond timestamp. If two or more structurally valid MAPs share that greatest timestamp, current authority is ambiguous and selection refuses rather than using UUID or discovery order. This current MAP is also the lineage's chronology predecessor for any new successor publication, even when the operation explicitly derives its requested new state from an older historical MAP.

F-15 exact-source comparison and routing domain: the Work Order SOURCE value and each Store MAP's common source_filename are compared by exact Unicode scalar-value sequence under PB-STOR-010, with no case folding or Unicode normalization. Automatic routing compares only routable Store lineages whose structurally valid Store MAPs participate in that exact-source routing decision. Unrelated Suitcase files, non-Store artifact classes, filesystem enumeration order, and arrival order are outside the routing comparison domain and cannot create or remove a source match.

A governed Store-aware Work Order may explicitly identify any one structurally valid immutable Store MAP present in the Suitcase, including an older snapshot when newer MAPs for that Store also exist. The canonical clause is:

MAP "__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv"

The quoted value must be the exact physical filename of one valid Store MAP. A WKO MAP profile, missing file, malformed MAP, or other MAP profile is invalid for this clause. Data Sculptor uses exactly the named Store MAP rather than silently substituting a later one.

For materialization, SOURCE "..." remains required to identify the source file being read; the optional MAP "..." clause occurs immediately after SOURCE and before KEEP, overrides automatic Store-MAP inheritance, and supplies the exact Store-state base. The Work Order's exact SOURCE filename must match the selected lineage's governed source identity under the frozen source/Store compatibility rules or validation refuses. For an alias-only UPDATE ALIASES Work Order, MAP "..." may itself be the Store-state selector and no source-data read is required.

Historical-MAP health gate. Explicit selection of a current or historical Store MAP never bypasses current Store-lineage health. The selected lineage must currently evaluate VALID, and every RID/COL binding referenced by the named MAP must currently be present and valid. If either condition fails, Data Sculptor refuses the operation. An older MAP cannot be used to hide present lineage damage. The same rule applies when UPDATE ALIASES uses a historical Store MAP as its base.

Once selected, the exact MAP identity, Store RID binding, Store alias, RID alias, and materialized-column mapping state remain fixed for the governed run. The MAP filename is execution input, not a friendly alias.

P2-03 base-versus-predecessor distinction: an explicitly selected historical MAP is the operation's base MAP—the Store snapshot from which requested new state is derived. It does not become the chronology predecessor merely because it was selected. If the operation publishes a new Store MAP, the chronology predecessor remains the Store lineage's current structurally valid MAP immediately before publication. The new transaction UTC must be strictly greater than that current MAP UTC. This preserves one chronological MAP history rather than creating a branch from the historical base.

F-21 current-state consequence: merely selecting or validating a historical Store MAP does not change Store authority. If the governed run refuses or otherwise publishes no successor Store MAP, the lineage's pre-run current MAP remains current. If the run successfully publishes a successor derived from a historical base, that new MAP enters the same single chronological history and ordinary greatest-governed-UTC current-state selection applies. Because successor publication already requires a truthful transaction UTC strictly greater than the pre-publication chronology predecessor, the successfully published successor becomes current. The explicitly selected historical base and the formerly current MAP both remain immutable historical evidence.

This behavior is deliberate state derivation, not a branch, rollback-in-place, overwrite, or mutation of prior MAPs. The operation base records which Store snapshot supplied the requested starting state; chronology records when the new governed state was published. Those are distinct facts.

Each valid Store MAP represents one complete usable Store metadata and materialized-column mapping state for that version. It must not require replaying a chain of earlier MAP files merely to reconstruct the Store's current RID binding, aliases, or materialized-column mappings.

A newer MAP created from an inherited older MAP contains the complete resulting Store snapshot after applying the governed Work Order's successful changes.

When a governed Work Order materializes one or more columns or requests governed Store/RID/COL alias changes, Data Sculptor begins from the applicable governed Store-state base. Ordinary materialization uses the explicitly selected MAP or Store-aware automatic inheritance under W002-STOR-019.2. A new Store begins from newly established Store/RID metadata plus an empty materialized-column mapping set before requested materialization is applied.

All successful updates in that Work Order are applied to one in-memory complete Store snapshot. The complete deterministic successor-MAP bytes must first be written under a governed SCR candidate identity, closed successfully, reopened, and fully validated while still an SCR candidate. Only a complete validated candidate may be promoted by host rename into one new immutable MAP artifact.

The inherited MAP remains unchanged. The successful SCR-to-MAP rename is the Store-state commit point. A failed run must not create a valid successor MAP; a malformed, incomplete, or unpromoted MAP candidate remains visible non-authoritative SCR evidence rather than Store state.

RID reconstruction/replacement is not a WASM-002 Store-mutation path.

P2-03 successor publication precondition: before any final RID/COL/MAP promotion for a successor Store-state transaction, Data Sculptor identifies the lineage's chronology predecessor and establishes one truthful observed host transaction UTC. For an existing lineage, that UTC must be strictly greater than the current structurally valid Store MAP UTC, regardless of whether the Work Order's base MAP is current or historical. Equal or earlier observed UTC refuses publication; no artificial +1 ms, sleep-and-retry loop, UUID tie-break, older-predecessor fallback, or branch chronology is permitted. The chronology predecessor remains current and unchanged.

Future-dated current Store MAP: a structurally valid current MAP with a governed UTC later than truthful observed host UTC is a clock-order conflict, not by itself Store corruption. It remains current and successor publication is blocked. Help must identify the exact blocking MAP and explain the analyst-owned exits: correct an incorrect host clock; wait/rerun after truthful time advances beyond the predecessor; or deliberately move that exact future-dated current Store MAP out of the active Suitcase root and reopen/rescan. Moving it is an analyst filesystem action, not a governed Data Sculptor mutation. An older structurally valid MAP may then become current; returning the future-dated MAP may restore its authority under the ordinary greatest-UTC rule.

F-13 single-writer pre-commit guard: immediately before the final successor Store-MAP promotion, Data Sculptor re-resolves the relevant current Store authority and exact-source routing state on which the transaction depended. For an existing lineage, the current chronology predecessor must still be the authority against which the transaction was prepared; for a new-Store transaction, no newly established routable lineage may have appeared that changes the routing decision. If relevant governed state changed while the transaction was in flight, publication refuses. Data Sculptor must not overwrite the newer authority, silently rebase onto it, create a competing branch, or report success. Any RID/COL/candidate artifacts already produced are handled by the existing rollback / attributable recovery-evidence rules and do not become committed Store membership without the final valid MAP binding.

F-21 historical-base publication rule: when the applicable Store-state base is a valid historical MAP rather than the pre-run current MAP, the complete successor snapshot is still derived from that explicitly selected base plus the current Work Order's requested changes. Publication does not silently merge later state from the formerly current MAP back into the successor. Therefore mappings or aliases introduced only after the selected historical base may be absent from the new successor when the requested operation does not recreate them. That is the deliberate consequence of using the historical base, not data loss caused by an implicit merge.

The pre-run current MAP remains the chronology predecessor solely for monotonic publication ordering and stale-authority protection. Successful publication leaves both the historical base and the formerly current MAP byte-for-byte unchanged, publishes one new immutable successor MAP in the same lineage, and makes that successor current under the ordinary chronology rule. No branch identifier, hidden branch state, overwrite, in-place rollback, or automatic rebase is created.

The canonical WASM-002 Store MAP is a CSV whose header row is exactly:

store_alias,rid_filename,rid_alias,source_filename,source_column_number,source_header,alias,column_filename

Each data row describes one current logical materialized-column mapping:

• store_alias — current human-facing Store name;
• rid_filename — exact immutable governed RID artifact filename that physically anchors this Store lineage;
• rid_alias — current human-facing RID name;
• source_filename — exact visible source filename common to every row in this one-Store MAP and therefore the Store source identity;
• source_column_number — 1-based source-column ordinal;
• source_header — exact decoded CSV header value after governed parsing;
• alias — current human-facing COL name; and
• column_filename — exact physical governed COL artifact filename represented by the row.

Every row in one valid Store MAP must carry the same exact rid_filename and the same exact source_filename. A MAP that mixes RID lineages or source filenames is invalid. The logical source-column key for COL alias continuity remains the exact triple (source_filename, source_column_number, source_header). The Store is physically identified by the repeated exact rid_filename, not by mutable aliases.

F-05/P2-01 reconciliation: the superseded redundant Store-source column is removed. One Store MAP represents exactly one Store lineage and exactly one source identity, so the common source_filename supplies the required source identity without a second Store-source field.

P3-06 identity-evidence boundary: this eight-column MAP profile intentionally records governed physical filenames and mapping metadata, not per-artifact byte lengths, row counts, digests, or historical-content fingerprints. A MAP therefore cannot prove that a same-named RID or COL restored later is byte-for-byte identical to the earlier artifact. WASM-002 must not make that claim unless separate authoritative fingerprint evidence exists outside this MAP profile.

P2-04 schema consequence: no byte-length, RID-N, digest, or per-artifact fingerprint columns are added to the eight-column Store MAP to close restoration validation. The MAP remains compact relationship/state metadata. Stronger byte-identity assurance remains the responsibility of explicit fingerprint evidence outside ordinary WASM-002 Store governance.

When a logical source column is materialized and its exact logical key does not already exist in the inherited Store MAP, its default COL alias is its operational column name. For an exact decoded source_header of at most 1,024 Unicode scalar values, the operational name is that exact header text. For an exact decoded source_header longer than 1,024 scalar values, the operational name begins as Column <LETTERS> from the column's 1-based physical source ordinal (for example Column A, Column Z, Column AA, through Column XFD).

The exact source_header remains unchanged in the Store MAP and physical COL header; the operational name exists only to provide a bounded human-facing/default-alias value. HEADER selection continues to match the exact decoded source header under W002-STEPS-002.

If an oversized-header base fallback Column <LETTERS> would collide in the complete successor alias namespace, Data Sculptor deterministically tries Column <LETTERS> [<ordinal>]; if that also collides, it appends -2, -3, and so on until the first available exact value is found. This is the only automatic alias-suffix rule in WASM-002. A short exact source-header default that is empty or collides still refuses unless the Work Order supplies an explicit valid alias; Data Sculptor must not suffix or rewrite it.

If the same Work Order supplies an explicit alias for a newly materialized column, the explicit governed alias overrides the operational default and must pass the ordinary exact uniqueness/shadowing rules without automatic suffix repair.

For a previously materialized COL, RESET COL "<reference>" ALIAS restores this same deterministic operational default from the exact recorded source_header and physical source ordinal. An oversized recorded header therefore restores its deterministic fallback/disambiguated operational name rather than inserting the potentially very long exact header into the alias field. A short empty/colliding source-header default still refuses rather than inventing a substitute.

If a newly materialized column's exact logical key already exists in the inherited Store MAP, Data Sculptor must preserve that row's current COL alias unless the Work Order explicitly changes it. The successor MAP replaces only that logical row's column_filename with the newly created physical COL artifact filename.

Ordinary rematerialization must preserve the inherited Store's exact common source_filename and rid_filename. It must not silently create a different Store, replace the Store RID, revert a user-facing Store/RID alias, or revert a COL alias to its source header. Every row in the successor MAP continues to carry that same common Store source_filename.

WASM-002 has no executable operation that replaces rid_filename while preserving the same Store lineage. A different RID filename therefore cannot be introduced as ordinary successor-state continuity in this build.

Store MAP CSV files are encoded as UTF-8 without BOM and use LF (0x0A) record termination. The exact eight-field header in W002-STOR-019.6 is written once as the first row. Fields use standard CSV quoting semantics: a field containing comma, double quote, CR, or LF is enclosed in double quotes, and embedded double quotes are doubled. No locale-dependent formatting is permitted.

Every data row in one MAP must contain byte-for-byte identical values for store_alias, rid_filename, rid_alias, and source_filename. Mapping rows are written deterministically by ascending numeric source_column_number, then ascending UTF-8 byte order of source_header. Because one valid Store MAP has exactly one common source_filename, that field is not needed as a leading row-sort discriminator. Two rows with the same logical source-column key (source_filename, source_column_number, source_header) are invalid.

A canonical MAP filename alone does not make a file a structurally valid Store MAP. For Store-MAP structural validity, the MAP artifact itself must be readable as complete UTF-8, have the exact eight-column schema, parse deterministically, satisfy Store-level consistency, lineage, deterministic row-order, mapping-key, and alias constraints, and carry structurally valid governed RID/COL filename bindings. The present health of the referenced RID/COL artifacts is a separate question and does not determine whether the MAP itself is structurally valid.

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 referenced RID or COL later becomes missing or invalid. Referenced-artifact damage therefore does not make the current structurally valid Store MAP disappear and does not by itself cause fallback to an older MAP.

F-03 current Store MAP selection

Current-state selection is performed independently within one exact Store lineage. Only structurally valid Store MAP artifacts participate. Among those MAPs, the ordinary frozen chronology rule selects the unique structurally valid MAP with the greatest canonical UTC millisecond timestamp.

• 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 governed Help/evidence surfaces.
• This fallback applies to structural MAP invalidity only. It does not apply merely because a structurally valid current MAP references a damaged RID or COL.
• If two or more structurally valid MAPs share the greatest canonical UTC millisecond timestamp, current authority is ambiguous and selection refuses rather than breaking the tie by UUID, discovery order, directory order, or filesystem modified time.

P3-07 routing distinction: Store-MAP inheritance eligibility is stricter than lineage discovery. A Store lineage participates in exact-SOURCE routing when at least one Store MAP in that lineage is structurally valid, even if the current Store later evaluates DEGRADED or INVALID. Referenced RID/COL health is evaluated after routing and may cause refusal; it must not make an already discoverable lineage disappear.

For successor publication, after the required RID/COL physical promotions have succeeded, Data Sculptor uses the already-established publication-transaction UTC and allocates a MAP-specific UUID before opening the complete deterministic MAP CSV under its governed SCR candidate identity. The SCR filename therefore already carries the exact UTC, UUID, and .csv extension intended for the final MAP identity. The candidate is closed successfully, reopened, and validated for bytes, schema, Store-level consistency, aliases, RID binding, COL bindings, deterministic row order, and all other MAP eligibility rules while it remains SCR.

Only after that validation succeeds may Data Sculptor promote the candidate by host rename that changes only the three-letter semantic class token from SCR to MAP. The candidate bytes, UTC, UUID, and extension must remain unchanged across promotion. The successful rename is the publication/commit point. If validation or rename fails, no successor MAP becomes eligible/current; the candidate remains or is retained as visible non-authoritative SCR evidence. Store-aware automatic selection therefore continues to use the greatest earlier valid MAP in the same Store lineage, if one exists, while Help reports the failed candidate/publication rather than silently treating it as current state.

P3-06 governed artifact-validation tiers. Store-health status and full content validity are distinct assurances. The following two tiers are normative for WASM-002:

• Tier 1 — Store-health structural validation. Used for routine Store status, source routing, historical-MAP health gates, inheritance decisions that do not consume analytical artifact contents, and alias-only maintenance. The selected Store MAP itself is fully parsed and structurally validated because it is the compact authority for the snapshot. A referenced RID passes Tier 1 only when the exact MAP-bound governed RID filename is present and readable, the bytes begin with exactly one UTF-8 BOM, the first logical record is a canonical N=<value> header, the final byte is LF, and the physical byte length equals the deterministic length implied by the canonical RID representation for that declared N. Tier 1 does not rescan every RID data record merely to perform routine status or alias work. A referenced COL passes Tier 1 only when the exact MAP-bound governed COL filename is present and readable, begins with exactly one UTF-8 BOM, exposes the canonical one-column CSV header whose decoded value exactly equals the MAP row's recorded source_header, and ends with LF. Tier 1 does not stream every COL value merely to establish routine Store health.
• Tier 2 — full artifact validation. Used whenever an operation actually consumes RID/COL contents, for complete validation of newly created candidates before commit, and by REPAIR MAP after the repair operation has been validly entered. A RID passes Tier 2 only when a full stream proves the canonical N=<value> header, exactly N data records, and exact ordered values 1..N. A COL passes Tier 2 only when a full stream proves canonical one-column CSV encoding/serialization, the exact expected header, and exactly N logical data records aligned to the Store RID.

VALID, DEGRADED, and INVALID are Store-health states evaluated from the governed current snapshot using the required validation tier; they are not claims of cryptographic historical identity. When REPAIR MAP is validly invoked, it must perform Tier 2 validation of the RID and every mapped COL that would survive into the successor. The deterministic repair result removes exactly the mapped COL bindings that fail that Tier 2 check, subject to the separately frozen refusal when no mapped COL would remain. Two implementations presented with the same bytes must therefore identify the same repair set.

External restoration boundary: a file placed back under an original governed RID/COL physical filename may re-enter use only when it passes the validation tier required by the operation. Filename equality plus governed validation is sufficient for operation eligibility under this WASM-002 boundary; it is not proof that the restored bytes are the historical original bytes. Stronger historical-byte identity requires separate authoritative fingerprint evidence.

P3-10 terminology boundary: Store-state repair is REPAIR MAP. Work Order alias-registry repair is REPAIR WORK ORDER REGISTRY. These are distinct governed operations and the integrated specification must not describe a Store REPAIR MAP Work Order as a “registry-repair Work Order.” This corrects wording only; it does not change either operation's frozen semantics.

F-08 / F-03 REPAIR MAP Work Order structure and target precondition:

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

Exactly one MAP "<filename>" clause is mandatory. It names the exact physical filename of one structurally valid Store MAP. At Run time, that named MAP must be the current structurally valid Store MAP for exactly one lineage and the target Store must currently evaluate DEGRADED. A historical Store MAP, WKO MAP, missing MAP, malformed MAP, ambiguous equal-latest current state, MAP from an unsupported profile, or target Store that does not evaluate DEGRADED refuses.

No SOURCE, Store/RID/COL alias selector or mutation, KEEP, materialization, conversion, Inventory, registry repair, cataloging, or composition clause is supplied in the same WKO. The analyst selects the Store by exact current Store MAP identity; Data Sculptor determines which mapped non-RID COL bindings are broken. The terminal DS-STEPS clause is REPAIR MAP; the Receipt operation token is separately REPAIR_MAP.

P2-03 monotonic eligibility boundary: structural validity/eligibility and chronology are separate. A structurally valid future-dated Store MAP remains a structurally valid MAP and participates in current-state selection. It is not demoted merely because the host clock is presently earlier. The monotonic guard applies when publishing a successor: truthful observed transaction UTC must be strictly greater than the chronology predecessor UTC before any successor state may commit.

P2-04 closure — validation depth is now complete. The Tier-1/Tier-2 rules in this requirement are the complete WASM-002 oracle for deciding whether a MAP-bound RID/COL is sufficiently valid for the operation being attempted. Tier 1 is intentionally bounded and is used only by operations that do not consume RID/COL analytical contents. Tier 2 is a full streaming validation and is mandatory before an operation relies on RID/COL contents, for newly created candidates before commit, and for REPAIR MAP.

REPAIR MAP determinism. Once a valid REPAIR MAP operation is entered, Data Sculptor performs Tier 2 on the Store RID and on every mapped COL. The repair successor removes exactly those mapped COL bindings whose physical COL artifacts fail Tier 2, preserves exactly those that pass Tier 2, and still refuses if zero mapped COL bindings would remain. No shallower Tier-1 result may decide the repair set.

F-03 repair semantics: after target validation, Data Sculptor confirms the named MAP is current for exactly one Store lineage, confirms the referenced RID is valid, identifies every mapped non-RID COL that is missing or invalid under the required repair validation tier, preserves every valid COL binding unchanged, removes exactly the broken COL bindings from the successor candidate, preserves the exact Store lineage RID identity and remaining Store/RID metadata, validates the complete successor MAP candidate, and publishes the successor only if every repair gate succeeds. REPAIR MAP does not reread or regenerate the source CSV, rematerialize a lost COL, regenerate the RID, or edit the predecessor MAP in place.

F-03 all-COLs-broken refusal: if removing the broken bindings would leave zero COL mapping rows, REPAIR MAP refuses. No zero-COL Store MAP is introduced, no special anchor row is invented, no successor MAP is published, and the Store remains DEGRADED. The existing current structurally valid MAP and RID continue to anchor the visible lineage.

Identity boundary. Passing Tier 1 or Tier 2 proves only that the currently visible file under the exact governed filename satisfies the applicable WASM-002 validation contract. It does not prove that those bytes are historically identical to bytes previously present under that filename. Cryptographic historical-byte identity belongs to separately governed fingerprint evidence rather than ordinary Store health.

F-15 reference-bounded eligibility: Store-MAP structural validity and inheritance eligibility are determined from the MAP artifact itself plus the governed artifacts and values that the MAP explicitly binds or that its profile explicitly requires for the validation tier being applied. Unrelated Suitcase files, unrelated Store lineages, WKOs, Receipts, Inventories, CAT/HLP/CER artifacts, analyst-owned files, directory enumeration order, and unrelated-file count cannot by their mere presence or later appearance make an already-published Store MAP eligible or ineligible. Alias-shadowing validation is a successor-publication check under W002-STOR-020; it is not a continuing ambient scan that retroactively invalidates historical MAPs.

For WASM-002, Data Sculptor does not allocate a second permanent Store UUID in addition to governed RID/MAP evidence. The exact governed rid_filename created when the Store is established is the stable physical anchor used to distinguish that Store's MAP lineage from other Stores in the same Suitcase, and every ordinary successor MAP repeats it exactly.

Within any one MAP, every row must repeat the same exact current rid_filename; disagreement is invalid. Across WASM-002 successor MAPs, a different RID filename denotes a different Store row universe and must not be silently treated as same-Store continuation.

A later PRD revision may define an explicit governed recovery transition if Red5Sorcery chooses to support replacement of a damaged RID while preserving logical continuity. No such transition is executable in WASM-002.

When the first successful materialization establishes a Store, its first Store MAP must initialize store_alias to the exact common source_filename and rid_alias to the literal RID.

Those are the deterministic Store and RID default aliases. A later alias-only Work Order may replace them with STORE AS "<alias>" and RID AS "<alias>", clear them with CLEAR STORE ALIAS / CLEAR RID ALIAS, or restore these defaults with RESET STORE ALIAS / RESET RID ALIAS under W002-WKO-012.1 through W002-WKO-012.6. None of those operations changes the common source_filename, rid_filename, RID bytes, COL bytes, or prior MAP history.

WASM-002 shall define CAT as a governed Data Sculptor artifact class for cataloging a collection of CSV Stores inside one active Suitcase. CAT exists to let an analyst orient across many independently governed Stores without opening every MAP individually.

The scaling invariant is: MAP governs locally; CAT orients globally. CAT is an index over governed Store state, not a replacement for MAP and not a second Store authority.

A CAT may contain entries for many Store lineages in the active Suitcase. Every MAP referenced by CAT still governs exactly one Store lineage under the frozen one-Store-per-MAP rule.

CAT must not combine multiple Stores into one MAP, synthesize a shared Store state, or centralize Store semantics that remain governed independently by each Store's MAP lineage.

The WASM-002 Store Catalog has one durable representation: UTF-8 CSV. WASM-002 shall not emit separate HTML and CSV companion CAT artifacts for one catalog snapshot.

Each successful catalog publication creates one immutable governed artifact named exactly __DS__CAT__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv. A later catalog run publishes a new CAT snapshot; earlier CAT artifacts remain visible history and are not overwritten or deleted merely because a newer snapshot exists.

For orientation, the directory may identify the newest structurally valid CAT snapshot by the canonical UTC token. If two or more structurally valid CAT artifacts share the greatest canonical UTC timestamp, the UI must not invent chronology from UUID, discovery order, or filesystem modified time; it must surface the ambiguity and may present the tied CAT artifacts together until a later governed catalog run publishes an unambiguous newer snapshot.

F-14 publication: CAT is first written as __DS__SCR__<UTC>__<UUID>.csv using the UTC/UUID intended for the final CAT. The complete candidate must close, reopen, and validate the exact five-column schema, deterministic row ordering, row count and CSV serialization before the class token may be renamed to CAT. A failed candidate remains SCR/non-authoritative and must not be selected as a catalog snapshot.

The canonical CAT header row is exactly:

store_alias,source_filename,rid_filename,map_filename,store_health

Each data row describes one routable Store lineage using values derived from the authoritative current structurally valid Store MAP selected under the existing Store rules:

• store_alias — current human-facing Store identity;
• source_filename — the one common exact source filename carried by that Store MAP and used for Store routing;
• rid_filename — exact immutable governed RID filename that physically identifies the Store lineage;
• map_filename — exact current structurally valid Store MAP used to derive the row; and
• store_health — the Store health evaluated during this CATALOG STORES run, exactly one of VALID, DEGRADED, or INVALID.

store_health is snapshot orientation metadata, not MAP health and not an independent health authority. If the Suitcase later changes, an older CAT row continues to report the health value observed when that CAT was created.

CAT rows are sorted by ascending exact UTF-8 bytes of map_filename. The header is not part of that ordering.

CAT shall be reconstructible from authoritative Store MAP artifacts and the governed Store-health evaluation applied when CATALOG STORES runs. CAT must never be consulted to decide Store routing, inheritance, Store health, repair eligibility, current MAP selection, RID/COL validity, or whether a new Store may be established.

If a CAT row conflicts with authoritative MAP/Store state, current governed state wins and the CAT is stale/inconsistent. A stale CAT remains an inspectable historical governed artifact but must not be treated as current Store truth.

CAT is not automatically updated by materialization, repair, alias change, or any other Store-changing operation. The analyst creates a fresh catalog explicitly by running a new CATALOG STORES Work Order; success publishes a new immutable CAT snapshot and leaves earlier CAT snapshots visible history.

The canonical WASM-002 Work Order form is:

SUITCASE: .
WORK ORDER AS "Catalog Stores"
CATALOG STORES

CATALOG STORES is one standalone top-level operation. It is initiated only by an explicit analyst Work Order. No materialization, repair, alias update, conversion, or other governed operation automatically creates, rewrites, or refreshes CAT.

The operation scans authoritative governed Store MAP state, evaluates each cataloged Store's current health, and publishes one CAT snapshot plus the normal canonical Receipt. It does not mutate any Store or MAP. It must not also request materialization, conversion, alias mutation, repair, Inventory, Work Order composition, or another consequential operation in the same WKO.

The canonical Receipt operation token is CATALOG_STORES.

The catalog scan shall identify every routable Store lineage using the same structurally-valid-MAP routing definition already frozen for WASM-002. For each routable lineage, Data Sculptor evaluates current Store health exactly under W002-STOR-019.2, using the current structurally valid Store MAP selected under W002-STOR-019.10 and the applicable validation tier, and records exactly one of VALID, DEGRADED, or INVALID. Catalog presence is orientation, not permission to perform another operation.

Exactly one CAT row is emitted for each routable Store lineage, derived from that lineage's authoritative current structurally valid Store MAP and the Store-health result observed during this catalog run. If the complete authoritative collection state cannot be determined unambiguously, the operation must refuse rather than publish a knowingly incomplete or guessed CAT.

CATALOG STORES is read-only with respect to all pre-existing Store, RID, COL, MAP, source, WKO, and other Suitcase artifacts. It does not repair or mutate them.

After the complete deterministic CAT row set is established, publication follows the governed all-or-refuse artifact path: write the candidate under governed scratch, close and reopen it, validate its exact filename, UTF-8/LF CSV structure, exact header, deterministic row count/order, and row references, then promote the final CAT artifact. The CAT is not successfully published until final promotion succeeds.

A publication refusal leaves prior CAT snapshots and all Store/MAP state unchanged. The Receipt records whether the catalog entry count was established and whether a final CAT filename was published.

WASM-002 shall reuse the existing Data Sculptor Suitcase Directory for CAT and MAP discovery and inspection. A separate CAT/MAP browser panel shall not be added.

The newest unambiguous structurally valid CAT snapshot, or any tied newest CAT candidates when chronology is ambiguous, and all Store MAP artifacts shall be surfaced prominently at the top of the existing Suitcase Directory ahead of ordinary Suitcase files. The presentation may be pinned, grouped, or otherwise first-ranked, provided the priority is obvious and deterministic.

The analyst shall be able to select a visible CAT or MAP entry and inspect its contents through the existing read-only HTML UI without first locating or opening the artifact through the operating-system file browser.

The Suitcase Directory may continue to provide read-only filtered views of other Suitcase files. CAT/MAP prominence must not remove, replace, or weaken the existing ability to inspect the rest of the flat Suitcase.

Browsing, sorting, UI filtering, selecting, opening, and viewing Suitcase files are read-only inspection actions and shall not require a Work Order.

Read-only UI filtering is not the same operation as governed SEARCH. Governed SEARCH, ZIP creation, metadata changes, repairs, CAT regeneration, and every other consequential state change remain subject to the applicable Work Order and Receipt discipline.

The Suitcase Directory shall not edit, rename, delete, repair, replace, regenerate, or otherwise mutate CAT, MAP, Store, or Suitcase state through direct GUI manipulation. Consequential changes occur only through explicit governed operations or analyst-owned filesystem actions already permitted by the canonical contract.

The CAT/MAP presentation shall make collections containing dozens or hundreds of Stores practical to inspect. An analyst must be able to understand what Stores exist, which current MAP describes each Store, and which source file each Store governs without manually opening every MAP artifact through the operating-system file browser.

Acceptance must include a MusicBrainz-scale fixture containing 177 routable CSV Store lineages, each with its own authoritative current Store MAP. One explicit analyst-run CATALOG STORES Work Order must publish exactly one CAT snapshot containing exactly 177 data rows under the frozen five-column schema store_alias,source_filename,rid_filename,map_filename,store_health and deterministic MAP-filename ordering.

The fixture must include Stores that evaluate VALID, DEGRADED, and INVALID while retaining structurally valid current MAPs, and the CAT must record the exact health observed for each Store when the catalog run occurs. The CAT must not expose a separate MAP-health field.

The existing Suitcase Directory must surface CAT and MAP artifacts ahead of ordinary files; the analyst must be able to open CAT, inspect the collection, select and view MAP artifacts, sort/filter the directory, and inspect other Suitcase files without a Work Order. No direct GUI mutation path may be exposed.

Acceptance must alter authoritative MAP/Store state after the first CAT publication and prove that the earlier CAT is neither rewritten nor automatically refreshed. It remains visible and becomes stale/inconsistent where appropriate. Only a later explicit CATALOG STORES Work Order may reconstruct the collection and publish a new immutable CAT snapshot.

The linked WASM-003 DIR behavior remains outside the WASM-002 implementation scope: later DIR requirements auto-populate human-readable CAT/MAP descriptions, but those descriptions never become authority over CAT, MAP, or Store semantics.

Aliases are governed human-facing metadata. Creating, changing, clearing, or replacing an alias must not rename or rewrite the underlying artifact. Within one Store MAP, every non-empty COL alias and the non-empty rid_alias must be unambiguous within the row-addressable artifact alias namespace under the exact Unicode scalar-value comparison rule in PB-STOR-010.

F-15 publication-time shadowing boundary: alias uniqueness and physical-name shadowing are validated when a candidate successor Store MAP is being published, against the comparison domain applicable to that one Store snapshot and the then-visible governed physical targets it makes row-addressable. If an alias would exactly collide with another addressable alias or physical filename in that publication domain, publication refuses. After a Store MAP has been validly published, the later appearance, disappearance, rename, or copying-in of an unrelated Suitcase file does not retroactively make that immutable MAP structurally invalid or ineligible. A later textual reference can still become ambiguous at resolution time under W002-STOR-021; that ambiguity causes the later operation to refuse rather than changing the historical MAP's validity.

The store_alias names the Store as a whole and is separate from the field/COL alias namespace. Alias mutation occurs through a governed Work Order, not through an editable GUI field. Exact cross-Store Store-alias uniqueness and future selection-by-Store-alias syntax remain outside this freeze.

A saved Work Order may refer to governed materialized columns by exact physical filename or by a unique COL alias from one selected Store MAP. The canonical explicit Store-MAP selector is MAP "<exact Store MAP filename>" under W002-STOR-019.3 and W002-WKO-012.3. If that clause is present and valid, exactly that Store snapshot is used. Otherwise Data Sculptor applies the Store-aware source-qualified selection rule in W002-STOR-019.2.

All textual physical-filename and COL-alias comparisons in this resolution step use exact Unicode scalar-value sequence equality under PB-STOR-010: no case folding, Unicode normalization, trimming, locale equivalence, or filesystem enumeration heuristic is permitted. Resolution is bounded to the selected Store snapshot and the physical targets/aliases that are addressable through that snapshot. If the supplied text has no exact target, resolution refuses. If it has more than one exact possible target in that domain—for example because a currently visible physical filename and a current alias are both exact matches—resolution also refuses. Data Sculptor must not choose filename over alias, alias over filename, first-found entry, directory order, modified time, UUID, or any other tie-break heuristic.

Before execution, Data Sculptor must record the exact physical Store MAP identity when one is used, bind the run to its exact rid_filename, and resolve aliases deterministically to physical COL artifacts. The selected Store MAP must remain fixed for the run even if a newer MAP is created during that same run. This protects Store/selection continuity but does not by itself claim that bytes stored under an analyst-owned source filename are cryptographically identical across different runs.

A selected directory becomes a validated Suitcase only when Data Sculptor successfully creates, completely writes, and closes one governed CER HTML Suitcase Validation Certificate in that directory. The certificate itself is the validation artifact and remains visible in the flat Suitcase as durable evidence.

No validation-only delete or rename is required. Failure to create, completely write, or close the certificate means the directory has not passed Suitcase validation and analytical execution remains locked.

F-14 CER exception: the CER is deliberately not staged as SCR. Suitcase validation is specifically the direct create/write/close test of the final canonical CER identity in the selected directory. Inserting an SCR-to-CER rename would test a different publication path and is therefore forbidden for this validation step. A successful CER does not pre-certify later SCR-to-final renames for other artifact classes.

F-24 CER lifecycle: every successful explicit Suitcase selection and validation publishes exactly one fresh immutable CER with a new governed UTC+UUID identity. Data Sculptor must not satisfy a new validation event by reusing an earlier CER. Every prior valid CER remains a standalone historical artifact under its original governed filename and exact bytes.

WASM-002 performs no automatic CER deletion, replacement, compaction, or CER-history ZIP packaging. Historical CERs are not housekeeping candidates merely because a newer CER exists. Any later archival or packaging capability must be separately governed and explicitly invoked; it is not part of the WASM-002 validation lifecycle.

The exact certificate filename is __DS__CER__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html, using the canonical UTC millisecond token and canonical lowercase hyphenated UUID v4. Data Sculptor chooses the filename; the analyst does not supply or edit it.

The CER create/write/close test begins only after the browser host has satisfied the required user-selected writable-directory capability in W002-PLAT-001. A browser that cannot expose that capability produces a host-capability refusal before folder validation; that condition is not evidence that any particular directory is unwritable or filename-incompatible.

WASM-002 path/filename acceptance must derive the maximum filename length from every governed final-artifact filename form and every governed SCR staging form that this build can actually emit. Under the current contract, the maximum is 73 ASCII bytes/characters: the governed .html CER/HLP final forms and an SCR candidate reserved for a .html final artifact have that length. The canonical CER filename therefore exercises the current maximum emitted filename length during the create/write/close validation test.

On a supported host, successful create/write/close of this canonical governed HTML filename is the WASM-002 folder filename/path compatibility test for the current emitted-name maximum. Data Sculptor does not maintain a product-level table of operating-system numeric path maxima and must not truncate, abbreviate, hash-shorten, or otherwise mutate a governed filename to fit a host path limitation. If the certificate cannot be created under its canonical name after a directory has actually been selected through the supported-host contract, the selected directory does not pass validation.

If a future PRD revision introduces an emitted final or staging filename longer than the current CER/HLP/SCR-HTML maximum, acceptance must detect that change and explicitly exercise the new maximum before the build may rely on this path-compatibility claim.

The HTML certificate uses the canonical built-in Data Sculptor presentation and must visibly contain, at minimum:

SUITCASE VALIDATION CERTIFICATE
RESULT: PASS
SUITCASE: .
UTC: <canonical certificate UTC>
UUID: <certificate UUID>
ARTIFACT: <full governed certificate filename>
TEST: CREATE_WRITE_CLOSE

It must state that Data Sculptor successfully created, completely wrote, and closed this governed HTML certificate in the selected Suitcase. It must state that this establishes that the selected directory was writable by Data Sculptor at the recorded UTC and accepted the governed artifact filename used for the certificate.

It must also state that the certificate does not certify available disk capacity, guarantee success of future analytical operations, or certify later SCR-to-final-class publication/rename operations. The semantic record uses SUITCASE: . and must not persist an absolute machine-specific path merely to prove validation.

The certificate is a human-facing HTML CER artifact and uses the canonical built-in Red5Sorcery/Data Sculptor presentation in WASM-002. Presentation must never change RESULT, SUITCASE, UTC, UUID, artifact identity, TEST, validation meaning, or limitation facts.

Configurable Brand Manifest application to CER artifacts is deferred to V1-BACKLOG / a future build and is not required for WASM-002 Suitcase validation.

Except for the deliberate CER Suitcase-validation path below, WASM-002 does not place a newly generated durable artifact into its final semantic class merely because candidate bytes exist. The complete candidate is first written under the governed SCR identity defined by W002-STOR-023.1, closed, reopened, and validated against the target class contract. Only a candidate that passes its class-specific publication predicate may be renamed into the intended final class. A final-class filename therefore records successful class publication, not broader authority where a separate MAP/registry relationship governs authority.

F-33 reserved-class boundary: DGN, RCV, BRD, and LCK are registered but not emitted by WASM-002, so they do not appear as publication profiles in this table and have no WASM-002 producer here.

RID, COL, Store MAP and WKO MAP publication retain their specialized transaction/commit rules elsewhere in this PRD. W002-STOR-023 does not replace those state-publication contracts; W002-STOR-023.1 supplies the shared SCR candidate identity and retained-failure-evidence boundary they may reference.

The canonical candidate filename for a staged governed artifact is:

__DS__SCR__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.<final-extension>

The SCR candidate uses the exact UTC token, UUID and extension reserved for its intended final artifact. Successful publication changes only the three-letter semantic class token from SCR to the intended final class. For example, an RCP candidate __DS__SCR__20261006T190000000Z__<uuid>.txt may become __DS__RCP__20261006T190000000Z__<uuid>.txt only after the complete candidate has been closed, reopened and validated against the RCP publication predicate. The rename must not alter candidate bytes, UTC, UUID or extension.

An SCR filename never by itself confers final-class validity, Store membership, registry authority, execution authority, or durable final-class evidence status. A retained SCR whose bytes happen to satisfy a target validator after an interrupted or refused transaction must not be auto-promoted, silently adopted, or treated as if the missing publication step occurred.

F-33 retained-failure-evidence boundary: when a handled failure leaves one or more SCR candidates or other staged bytes that cannot be safely removed or restored, they must remain visible only as non-authoritative SCR evidence. WASM-002 does not publish an RCV recovery manifest. Retention must not complete or simulate the failed publication step, and the governed diagnostic/Help path must report the failure using only facts actually established.

A retained or orphaned SCR remains non-authoritative even if its bytes later validate. Data Sculptor must not infer an intended final class solely from extension or byte content, must not rename or promote the SCR merely because it survives a later scan, and must not create a replacement RCV sidecar to manufacture attribution that the failed transaction did not durably preserve.

Before WASM-002 performs analytical CSV materialization, it must certify the complete selected source as valid UTF-8 using bounded processing.

Stage 1 UTF-8 certification must remain bounded independently of source byte length and must not buffer the complete source, CSV header, or CSV row set in memory. CSV column-count and operational-name rules belong to Stage 2 and must not be used to justify unbounded Stage-1 state.

The WASM-002 analytical/materialization path must proceed only after successful UTF-8 certification.

For a governed WASM-002 analytical run, the browser host must resolve the Work Order source reference once and retain the same selected source instance across Stage 1 UTF-8 certification and Stage 2 materialization.

The purpose of this binding is to prevent Stage 2 from accidentally consuming a different source than the one Stage 1 certified. It is a run-local continuity guarantee, not a claim of durable cryptographic identity across separate runs.

After Stage 1 begins, Stage 2 must not reacquire the analytical source by re-reading an alias mapping, re-resolving a filename/path, opening a newly selected browser file, or otherwise substituting another source instance. Stage 2 consumes the source instance already bound to the governed run.

Filename equality, alias equality, path equality, timestamps, or exact byte length may be useful provenance facts but must not be presented as cryptographic proof that source bytes are identical across separate runs. WASM-002 makes no such automatic cross-run exact-byte claim.

UTF-8 certification and ordinary column materialization must not automatically compute SHA-256 merely to establish WASM-002 source binding. The source-binding requirement is satisfied by preserving the same run-local selected source instance across the two stages.

This rule does not prohibit SHA-256 where another explicit WASM-002 requirement governs integrity for a specific generated artifact. It applies to automatic hashing of ordinary analytical source data.

If the browser host cannot preserve the selected source instance from certification into materialization, or the source becomes unavailable before Stage 2 can consume it, the analytical run must refuse before materialization rather than silently reselect, substitute, or infer another source.

WASM-002 must use an ASCII-first, strict inline UTF-8 certification algorithm or an equivalent implementation that preserves the same single-forward-scan semantics, bounded state, deterministic validity result, exact error location, and performance intent established by WASM-001b.

Window size may be changed only if semantics and byte-identical certification outcomes remain invariant.

An equivalent low-overhead strict validator is acceptable if it preserves the same governed result and bounded-state behavior.

No more than three source bytes may need to remain pending between windows, or an equivalent smaller state representation may be used.

On the first invalid UTF-8 sequence, certification must stop and return FAIL. The governed UTF-8 refusal evidence is:

• FIRST_INVALID_BYTE_OFFSET — the zero-based absolute byte offset of the first byte of the invalid sequence, counted from the first physical source byte, including a permitted leading UTF-8 BOM when present; and
• STOP_REASON — exactly INVALID_UTF8_SEQUENCE.

For an EOF-truncated multibyte sequence, FIRST_INVALID_BYTE_OFFSET is the absolute offset of that incomplete sequence's lead byte, not the EOF position. The certifier need not read the remainder of an already-invalid source. Input-window boundaries must not change the outcome, stop reason, or first-invalid offset.

F-16 follow-on boundary: stopping strict UTF-8 certification at the first invalid sequence does not make the remainder of the source irrelevant to conversion advice. When the governing operation is MATERIALIZE and Stage 1 reaches FAIL, the analytical run remains refused; Data Sculptor then starts the separate read-only compatibility assessment in W002-CONV-002 from physical byte offset 0 of the same bound source instance. That second pass may read to EOF solely to determine converter compatibility. Stage 2 must not start.

At EOF, certification may return PASS only if every physical source byte has been consumed under the strict UTF-8 rules and no incomplete sequence remains pending.

The completed Stage-1 outcome vocabulary is exactly PASS and FAIL. PASS means strict whole-source UTF-8 certification completed successfully. FAIL means an invalid UTF-8 sequence was deterministically established under W002-ENC-004.10.

The common Receipt absence tokens remain separate from those completed outcomes: NOT_RUN when Stage 1 never begins, and NOT_AVAILABLE when Stage 1 begins but a separate failure prevents a governed PASS/FAIL conclusion. NOT_APPLICABLE is not a completed value for STAGE1_UTF8_OUTCOME.

Certification answers only whether the complete source byte stream is valid UTF-8 under the frozen rules.

Splitting the same valid or invalid source at different bounded window sizes must not change PASS/FAIL or the first invalid absolute byte offset.

The inline validator must implement strict modern UTF-8 validity, excluding overlong forms, UTF-16 surrogate code points, values above U+10FFFF, invalid lead bytes, invalid continuation bytes, and truncated sequences.

F-07 stop-reason vocabulary: all strict UTF-8 invalidity classes governed by this requirement—lone continuation bytes, malformed continuation sequences, overlong forms, surrogate encodings, values above U+10FFFF, invalid lead bytes, and EOF-truncated sequences—serialize the single machine reason token INVALID_UTF8_SEQUENCE. The specific fixture category is acceptance evidence; the canonical stop reason intentionally does not duplicate validator-library-specific subcodes.

ASCII-first inline UTF-8 certification algorithm READ NEXT BOUNDED WINDOW Reference evidence used 4 MiB windows RESOLVE PENDING CROSS-WINDOW STATE At most one incomplete UTF-8 sequence ASCII FAST SCAN Advance cheaply while every byte < 0x80 ASCII RUN Already valid UTF-8 RESUME SCAN Same window BYTE >= 0x80 Validate sequence inline STRICT UTF-8 Lead + continuation range rules VALID END OF WINDOW?

Persist only bounded carry state MORE SOURCE? Yes: read next window; No: finish EOF + NO PENDING STATE UTF-8 PASS INVALID OR TRUNCATED UTF-8 FAIL No full-file allocation. No collection of all non-ASCII bytes. No per-sequence general string decode required.

Figure 2. The WASM-001b-derived fast path certifies ASCII directly, validates only non-ASCII sequences inline, and carries only bounded state across windows.

The following measurements are non-normative evidence explaining why WASM-002 begins with the ASCII-first inline algorithm. They are not WASM-002 acceptance results and must not be represented as such.

EVID-W001B-UTF8-001 On the 7,250,808,204-byte Statistics Canada source, the Day 039 distribution experiment observed 659,103 non-ASCII bytes, approximately 0.009090063% of the file, across 329,551 non-ASCII runs/sequences; the maximum observed non-ASCII run was three bytes.

EVID-W001B-UTF8-002 The Day 039 non-ASCII-only experiment submitted only 659,103 bytes to strict UTF-8 validation and completed in 12.664716 seconds at 545.998 MiB/s; it proved the source valid but still incurred 329,551 strict validation calls.

EVID-W001B-UTF8-003 A 1 GiB A/B test showed that reducing validated bytes alone was not enough: the selective per-run strategy submitted 115,839 bytes in 57,919 strict calls but took 503.7536 ms, while the baseline submitted 113,246,208 bytes in 27 strict calls and took 411.3590 ms.

UNRESOLVED SOURCE DAMAGE: preserved authoritative text continues “This supported removing per-run general-validator call overhead rather than merely shrinking” but the remainder has not been recovered. No missing words are inferred or supplied.

EVID-W001B-UTF8-004 The final native inline scan certified all 7,250,808,204 bytes in 10.377870 seconds at 666.313 MiB/s, observed 329,551 non-ASCII sequences and 659,103 non-ASCII bytes, and made zero std::str::from_utf8 calls.

EVID-W001B-UTF8-005 The same inline design was exercised in Microsoft Edge/WASM with 4 MiB transfers: the valid 7,250,808,204-byte source completed with 1,729 pushes, UTF8_VALID=true, and EOF_ALL_BYTES_VALID. That experimental run took 30.5858 seconds including file I/O, JS-to-WASM copy, and WASM validation.

EVID-W001B-UTF8-006 A full-size deliberately invalid Edge/WASM fixture stopped early after 2,936,012,800 bytes and 700 pushes with UTF8_VALID=false and STOP_REASON=INVALID_UTF8_SEQUENCE rather than reading to EOF.

EVID-W001B-UTF8-007 WASM-001b also retained malformed UTF-8 fixtures for stray legacy bytes, truncated sequences, lone continuation bytes, overlong encodings, UTF-16 surrogate halves, and 0xFE/0xFF invalid bytes. WASM-002 should reuse or regenerate equivalent acceptance fixtures with known invalid offsets.

The structural CSV parser and materializer operate under the explicit invariant that the same run-local selected source instance has already passed governed whole-file UTF-8 certification. Stage 2 must not independently re-resolve the analytical source.

Stage 1 establishes encoding validity. Stage 2 establishes CSV structure, row identity, selected values, and governed outputs.

After Stage 1 returns PASS, Stage 2 must begin its structural pass from absolute source byte offset zero using the same run-local selected source instance. Rewinding/re-reading the existing source handle is permitted; performing a new filename, alias, path, picker, or directory resolution is not.

If the host cannot re-read that same selected source instance for Stage 2, the Work Order must refuse under the run-local source-continuity contract.

If the certified source begins with the UTF-8 BOM bytes EF BB BF, Stage 2 must consume those three bytes before parsing the first CSV header field. They must not become part of the first source header or selected value.

The BOM is recognized only at absolute source offset zero. The fact that Stage 1 already saw the BOM does not permit Stage 2 to skip or reinterpret arbitrary later bytes.

Within the Stage 2 forward source scan, Data Sculptor must parse the complete first logical CSV record as the source header, construct ordered header metadata including exact decoded header text and 1-based source ordinal, resolve and validate all Work Order selectors/aliases, and then continue from the first data record without restarting the source.

Header resolution therefore does not add a third whole-file pass. A header-only valid CSV yields a zero-row materialization; a source with no valid header record refuses.

P3-09 no-header-record refusal: after Stage 1 has certified the source, if Stage 2 reaches end-of-source without establishing any logical CSV record from which a header could be parsed, materialization must refuse with CSV_REFUSAL_CONDITION: NO_HEADER_RECORD. This is the eighth governed Stage-2 structural CSV refusal token in the canonical oracle defined by W002-MAT-002.8. Its governed location facts are: CSV_SOURCE_BYTE_OFFSET = exact source byte length; CSV_PHYSICAL_LINE: 1; CSV_LOGICAL_RECORD: 1; CSV_FIELD_ORDINAL: 1. Therefore a zero-byte source reports offset 0, and a source containing only the UTF-8 BOM bytes EF BB BF reports offset 3. A first logical record that exists but is blank remains governed by the already-frozen BLANK_LOGICAL_RECORD condition and must not be reclassified as NO_HEADER_RECORD.

F-20 source-width boundary: the established header record may contain at most 16,384 physical source columns. Exactly 16,384 is valid; a header record containing 16,385 or more fields must refuse deterministically during header resolution before the first data record is consumed. The bound applies to the complete physical source width, not merely the requested KEEP set.

Header processing must remain bounded. Exact decoded source-header text is authoritative source evidence and must be preserved for every selected/materialized column, but the implementation is not required to retain the complete decoded text of every unselected header after selector resolution when bounded metadata is sufficient.

Stage 2 must not run a second whole-file UTF-8 certification algorithm over the source. It may inspect bytes and decoded field content only as required for CSV structure, header/selector semantics, governed field-size limits, output serialization, and diagnostics.

Any implementation that reintroduces redundant whole-source UTF-8 validation into Stage 2 is a measurable architectural regression unless separately justified and accepted.

A valid Work Order may request multiple source columns for materialization during the same bounded structural pass. For WASM-002 DS-STEPS, the requested set is expressed by one KEEP block containing one or more HEADER and/or COLUMN selectors under W002-STEPS-001 through W002-STEPS-004.

F-20 KEEP-width boundary: one governed KEEP block may resolve from 1 through 16,384 distinct source columns, subject to the source itself containing no more than 16,384 columns. An empty KEEP or a request that cannot resolve within that bound refuses before data-row materialization.

Every HEADER and COLUMN selector in the governed KEEP block must resolve to exactly one source column before any data-row materialization begins. Missing headers, ambiguous duplicate-header matches, invalid/out-of-range ordinals, duplicate resolved selections, invalid aliases, and successor-MAP alias collisions must refuse before the structural data-row pass.

The resolved selection cardinality must be an integer from 1 through 16,384. Resolution/validation must finish before the first data record is consumed, including operational-name/default-alias derivation and any deterministic oversized-header fallback required by W002-STOR-019.7.

After header/selector resolution, Stage 2 must traverse the source data records once regardless of whether the Work Order selects one column or many. The engine must not perform one complete source rescan per requested column.

During that scan, every source field is interpreted structurally, but only the fields required by the resolved selection set are materialized into governed COL outputs.

F-20 one-pass boundary: “one forward data-record scan” means one traversal of the source data records for the MATERIALIZE operation. WASM-002 must not reread source data records in batches merely because the selected-column set is wide. An implementation may perform additional bounded passes over Data-Sculptor-owned SCR, spool, or staging structures after the source scan when needed to finalize many outputs within resource limits; such passes must not reread the source data records or change governed output semantics.

The header is not a data row. The first accepted logical data record is row identity 1, the next is 2, and so on through N. The row counter advances exactly once per accepted logical CSV data record, not per physical line. Every selected COL produced by the run must contain exactly one logical data record for each accepted source data row and therefore exactly N data records in the same governed order. A multiline quoted field remains part of one logical record and must not advance row identity merely because it contains physical newline bytes.

When the run establishes a new Store, this 1..N sequence is published as that Store's one governed RID artifact. When the run extends an existing Store without changing its row universe, the existing RID is reused and must not be regenerated or renumbered.

Before the data-record scan begins, the validated selection set is placed in the same order in which its selectors appear in the governed KEEP block. That resolved order governs writer creation, per-row selected-field dispatch, progress/receipt presentation, deterministic backpressure-drain priority, and candidate COL identity allocation.

The Store MAP's own CSV mapping-row ordering remains governed separately by W002-STOR-019.9 and must not be confused with Work Order selection order.

Each active materialized-column writer, or an equivalent shared multiplexed output structure, must have bounded staging capacity. The aggregate kernel-owned staging state for all active writers must remain inside the governed WASM memory budget and must not grow with source row count or total output size.

If a required output writer cannot accept additional canonical bytes without exceeding its governed staging capacity, source consumption must pause while pending output is drained/written. When more than one writer requires service, drain priority follows resolved KEEP order. After sufficient space is available, parsing resumes from the same structural state.

The exact tuned staging-buffer size is an implementation/benchmark constant rather than an analytical semantic constant; changing it must not change output bytes, row identity, selection results, or diagnostics for the same governed input.

F-20 writer-resource bound: KEEP width and simultaneously active writable resources are distinct. The accepted build must declare a finite implementation bound on simultaneously active writable-output resources and retain acceptance evidence of both that configured bound and the observed peak. The engine may satisfy a wide selection by bounded shared/multiplexed staging or a Data-Sculptor-owned spool followed by bounded finalization passes, but it must not require one simultaneously open writer per selected column. Changing the writer-resource bound must not change final bytes, row order, selection identity, aliases, Receipts, or diagnostics for the same governed input.

All requested materialized-column outputs begin as visible governed SCR candidates, not COL artifacts. On first materialization of a new Store, the automatically generated RID likewise begins as a governed SCR candidate. Before any new RID/COL SCR candidate is opened, Data Sculptor establishes one publication-transaction UTC under PB-STOR-013/PB-STOR-014 and allocates a distinct artifact-specific UUID for each new candidate. Each candidate filename therefore already carries the exact UTC, UUID, and final extension intended for that RID or COL identity. A materialization transaction may begin promotion only when every required RID/COL candidate reaches EOF successfully, all selected outputs reconcile to the same accepted data-row count N, and all required candidate finalization/validation succeeds.

F-04 existing-Store cardinality gate: when materialization targets an existing VALID Store, after Stage 2 establishes the complete candidate logical data-row count N and before any requested COL candidate is promoted, Data Sculptor must read the expected N from the already-valid inherited RID header and compare the two values. If candidate N equals RID-header N, the cardinality gate passes and ordinary publication may continue. If candidate N differs, the Run must refuse before any SCR-to-COL promotion and before successor-MAP publication. The inherited RID, current MAP, and existing COL artifacts remain unchanged, and the existing Store remains VALID. Equal N proves cardinality compatibility only; it does not prove source-byte continuity, row-semantic identity, or permission for a different SOURCE to enter the lineage. Exact SOURCE/Store compatibility rules are prior gates.

For a new Store, Data Sculptor promotes the validated RID candidate first by host rename that changes only the class token from SCR to RID; the candidate bytes, shared transaction UTC, RID-specific UUID, and extension remain unchanged. That successful SCR-to-RID promotion is the event that establishes RID_ACTION: CREATED and the published RID_FILENAME fact for the Run. Before that promotion succeeds, the Run has not created a governed RID even if a candidate identity has been allocated.

For an existing Store, the inherited RID is reused unchanged and no RID candidate/promotion occurs. Once routing has selected and validated that exact inherited RID, that event establishes RID_ACTION: REUSED and the exact inherited RID_FILENAME; later refusal does not erase the already-established reuse fact. After the required RID state is established, Data Sculptor promotes each requested COL candidate in deterministic resolved KEEP order by changing only the class token from SCR to COL; each candidate's bytes, shared transaction UTC, COL-specific UUID, and extension remain unchanged.

If RID or COL promotion fails, Data Sculptor must refuse the run and roll any newly promoted RID/COL names back out of their final namespaces where safely possible. Candidate or rollback bytes that cannot be safely restored or removed must be retained visibly as non-authoritative SCR failure evidence. The existence of an unreferenced RID- or COL-looking file after interruption does not by itself make that artifact committed Store state.

After all required RID/COL promotions succeed, Data Sculptor allocates a MAP-specific UUID before opening the complete successor-MAP SCR candidate. That candidate uses the same publication-transaction UTC, the allocated MAP UUID, and the final .csv extension, and is constructed using the exact final RID/COL filenames. It is closed successfully, reopened, and validated completely while it remains SCR. Only then may the MAP candidate be promoted by changing only the class token from SCR to MAP; its bytes, UTC, UUID, and extension remain unchanged. The successful SCR-to-MAP rename is the materialization commit point.

Until that commit point, the prior valid MAP remains authoritative for an existing Store; for a new Store, no committed Store state exists yet. If MAP validation or MAP rename fails, Data Sculptor must refuse and roll the newly promoted RID/COL set back out of the final namespaces where safely possible; otherwise affected bytes remain attributable recovery evidence and are not committed Store membership. Governed Store membership/current state is established by a valid MAP binding, not by a final-class filename or timestamp equality alone.

Revision BB preserves the Revision AY staging/promotion mechanics and Revision AZ shared transaction-UTC rule for newly published RID/COL/MAP artifacts. Selected-folder support for the canonical governed filename/path form is established by the Suitcase Validation Certificate under W002-STOR-022 through W002-STOR-022.3 rather than by a frozen numeric host path-length table. Operation-specific host rename or publication failure remains a governed refusal under this requirement and is not pre-certified by Suitcase validation.

F-14 shared candidate grammar, reconciled by F-33: every RID/COL/MAP SCR candidate in this transaction follows W002-STOR-023.1: its SCR name already carries the UTC, UUID and extension intended for the final RID/COL/MAP identity, and successful promotion changes only the class token. Any retained SCR candidates after a handled publication/rollback failure remain visible non-authoritative failure evidence under W002-STOR-023.1 and are reported through the governed diagnostic/Help path; WASM-002 does not emit an RCV manifest. An orphaned SCR remains non-authoritative even if its bytes later validate.

A successful governed materialization that creates one or more COL artifacts must also publish exactly one new complete immutable Store MAP under W002-STOR-019 through W002-STOR-019.12. For a new Store, that MAP binds the automatically generated and promoted RID to the Store metadata and all newly materialized COL mappings. For an existing Store, it preserves the inherited RID binding and complete prior Store state while applying the successful materialization updates.

All required RID/COL SCR candidates must complete and validate before promotion begins. On a new Store, RID promotion occurs first; on an existing Store, the inherited RID is reused unchanged. All requested COL promotions must then succeed before successor-MAP candidate construction begins.

The complete successor MAP is written as SCR, closed, reopened, and fully validated before entering the MAP namespace. Its final host rename from SCR to the governed MAP filename occurs last and is the materialization commit point.

The materialization run is not reported as successfully committed until that MAP rename succeeds. If MAP candidate validation or MAP rename fails after RID/COL promotion, the run must refuse and the newly promoted artifacts must be rolled back out of their final namespaces where safely possible. Any failure residue that cannot safely be removed or restored is governed by W002-STOR-023.1 and remains non-authoritative retained failure evidence; its survival must not be used to infer or manufacture attribution or to simulate the failed publication step. The prior valid MAP remains authoritative for an existing Store; no committed Store is established for a first materialization without a valid successor MAP.

The parsed header establishes the expected source field count. Every nonblank logical data record must contain exactly that many fields after CSV parsing. A nonblank ragged record with fewer or more fields must refuse rather than pad, truncate, or shift later values.

An explicit empty field is valid data and preserves its ordinal. A bare blank logical data record occurring outside a quoted field must refuse and must not be silently skipped or converted into one empty field. A physical blank line inside a valid quoted multiline field is field content, not a blank record.

F-06 canonical malformed-CSV refusal facts

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.

Canonical structural refusal tokens

The seven frozen F-06 malformed-CSV tokens are:

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

P3-09 adds NO_HEADER_RECORD as the eighth governed Stage-2 structural CSV refusal token. Parser-library names, host exceptions, crate-specific error enums, or localized descriptions must not replace these governed tokens.

Governed refusal location by condition

Field ordinal rules

• 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.
• For NO_HEADER_RECORD, FIELD_ORDINAL is 1.

Bare CR scope

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.

EOF while quoted

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.

First-condition precedence

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.

Delimiter boundary

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.

Interaction with UTF-8 diagnostics

This structural CSV refusal oracle applies only 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.

Stage 2 must parse every field sufficiently to preserve CSV structure, field count, row boundaries, and governed safety checks, but it must not retain complete contents for unselected fields after those bytes are no longer structurally needed.

The engine must not materialize a complete source row, complete table, or complete unselected column in memory merely to emit selected columns. Selected-field content may use bounded accumulation required by the frozen field-size/output rules.

WASM-002 carries forward the established Data Sculptor field-buffer safety boundary: an individual CSV field may contain at most 16 MiB (16,777,216 bytes) of decoded UTF-8 field content. This is an engineering safety limit, not a semantic statement about CSV or an Excel cell limit.

The limit must be enforced incrementally for header and data fields. The parser must not first accumulate an arbitrarily large field and then check it. If a field would exceed the limit, the run must refuse without truncating, repairing, discarding the remainder, or finalizing the candidate materialization.

For an unselected field, Data Sculptor may count decoded field bytes without retaining the field value; the safety limit still applies so malformed unterminated fields cannot turn the structural scan into unbounded growth.

F-20 operational column-name boundary: after an exact source header field is decoded, Data Sculptor measures its length in Unicode scalar values, not UTF-8 bytes or grapheme clusters. If the exact decoded source header contains at most 1,024 Unicode scalar values, its operational column name is that exact header text. If it contains more than 1,024 scalar values, the operational column name begins from the deterministic physical-ordinal fallback Column <LETTERS>, where the letters are the Excel-style 1-based source ordinal (A through XFD for the WASM-002 width bound). This operational name is a bounded human-facing/default-alias construct; it does not replace or truncate the authoritative exact source header.

Each finalized materialized COL artifact is a one-column CSV. It begins with exactly one UTF-8 BOM (EF BB BF) and uses LF (0x0A) as the record terminator on every supported host.

The first logical record contains the exact decoded source header text for that physical source column; an alias assigned with AS lives in the governed MAP and does not rewrite the physical COL header. A deliberately empty source header is serialized as one explicit empty header field rather than as absence of a header record.

Header and data fields use deterministic minimal CSV quoting: quote when the field contains comma, double quote, CR, or LF; double embedded double quotes; otherwise write the field without quotes. Embedded CR/LF that belong to a quoted field remain field content. For a one-column data record whose decoded value is the empty string, serialize the value explicitly as "" so the row cannot be confused with a bare blank logical record.

For fixed source bytes and fixed governed semantics, changing input/output window boundaries must not change the finalized COL bytes.

F-20 source-fidelity rule: the physical COL header record always serializes the exact decoded source header, even when that header exceeds the 1,024-scalar operational-name boundary and the Store MAP/default alias therefore uses an operational fallback. The fallback name must never be substituted into the COL header record or into the MAP source_header field.

Structural materialization must process the certified source through bounded reusable input windows compatible with browser/WASM memory constraints. Source size and row count must not require proportional WASM memory growth.

The 4 MiB source window used successfully during the WASM-001b browser experiments is an evidence-backed starting/reference size. WASM-002 may tune the production input-window size using benchmark evidence, provided the governed memory budget and all window-invariance requirements remain satisfied.

For the same certified source and Work Order, permitted changes in bounded Stage 2 input-window size or boundary placement must not change CSV interpretation, resolved headers/ordinals, accepted row count, row identity, aliases, canonical COL bytes, successor MAP contents apart from newly allocated physical identities/timestamps, or the first deterministic refusal condition.

P3-09 window invariance: for a Stage-1-certified source containing no logical CSV record, every permitted Stage 2 window size and boundary placement must produce the same NO_HEADER_RECORD refusal and the same governed location tuple: source-byte offset equal to the exact source byte length, physical line 1, logical record 1, field ordinal 1.

F-06 full refusal-oracle window invariance: for the same certified source bytes, changing any 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; or FIELD_ORDINAL. This applies to every structural CSV refusal governed by W002-MAT-002.8.

Input-window boundaries may occur between ordinary field bytes, delimiter bytes, quote/escaped-quote pairs, CR/LF record-ending bytes, inside quoted multiline fields, and inside already-certified multi-byte UTF-8 sequences. The Stage 2 parser must preserve equivalent structural meaning across those boundaries.

Stage 2 may carry only the bounded state needed to continue the current logical CSV parse, including the current logical row ordinal, current field ordinal, quoted/unquoted state, escaped-quote/quote-transition state as required by the parser, pending CR/LF state, decoded-field byte count, resolved selected-field dispatch metadata, and bounded selected-field/output staging.

The parser must not retain previous complete rows or source windows merely because a CSV record crosses a window boundary.

The source read window, WASM transfer window where applicable, selected-field accumulator bound, and output-drain window are separate controls. One must not be silently treated as the maximum for another merely because an earlier prototype used the same numeric value.

Any tuning must preserve the Stage 2 memory, backpressure, byte, and window-invariance contracts.

The WASM-002 baseline performs its Stage 2 work directly from the certified source stream. It must not require a precomputed comma/quote/newline position map, binary structural index, hidden cache, or OPFS sidecar before materialization can proceed.

The previously discussed structural-sidecar comparison remains a separate future experiment and must not be introduced into WASM-002 as an unmeasured dependency.

The structural parser, row-count semantics, selector dispatch, canonical field serialization, and bounded output-state machine defined by Stage 2 belong in the shared Rust semantic core proven through the browser/WASM path first. A later native CLI host must call the same governed core rather than reimplementing competing materialization semantics.

Windows-1252-to-UTF-8 conversion is a distinct governed Work Order operation, separate from UTF-8 certification and separate from analytical materialization. The analyst must explicitly authorize it.

The canonical WASM-002 form is:

SUITCASE: .
WORK ORDER AS "Convert legacy source to UTF-8"
SOURCE "legacy_source.csv"
CONVERT WINDOWS-1252 TO UTF-8

CONVERT WINDOWS-1252 TO UTF-8 is the terminal operation clause. Exactly one SOURCE is permitted. The same WKO must not contain KEEP, MATERIALIZE, Store/RID/COL alias mutation, MAP, Inventory, repair, cataloging, Work Order composition, or another operation terminal clause.

F-10 conversion entry precondition

Before CONVERT WINDOWS-1252 TO UTF-8 may begin character transcoding, Data Sculptor must validate the complete bound source as strict UTF-8 under the same deterministic whole-source certification rules used elsewhere in WASM-002.

• If the complete source is already valid strict UTF-8, the conversion refuses as unnecessary and publishes no CVT.
• Only after complete strict UTF-8 validation reaches governed FAIL may Data Sculptor assess the same complete bound source against the frozen Windows-1252 compatibility mapping.
• Only a source that fails strict UTF-8 and passes the complete Windows-1252 compatibility assessment may proceed to conversion.

A failed analytical Work Order, UTF-8 certification, or materialization never silently invokes this operation. The analyst must explicitly authorize the separate conversion WKO.

After strict whole-source UTF-8 certification returns FAIL, the current analytical operation remains refused and Stage 2 must not start. As refusal handling, Data Sculptor performs one separate read-only Windows-1252 compatibility assessment from physical byte offset 0 of the same run-local bound source instance.

The compatibility assessment scans the complete source sequentially under W002-CONV-002.1 through W002-CONV-002.5. It does not transcode, publish a CVT, modify the analyst-owned source, resume materialization, or claim that Windows-1252 is the historical encoding. Its sole governed result is whether the entire byte stream is mappable by the frozen WASM-002 Windows-1252 converter.

If strict UTF-8 certification returned PASS, or did not reach a governed FAIL conclusion, this compatibility assessment is not run.

F-10 conversion classification gate

The conversion operation itself repeats/executes the complete classification gate on its bound source before transcoding:

1. validate the complete source as strict UTF-8;
2. if strict UTF-8 passes, refuse conversion as unnecessary;
3. only after strict UTF-8 fails, scan the complete source against the frozen Windows-1252 mapping;
4. if any source byte is undefined or unsupported by that mapping, refuse rather than guess; and
5. begin transcoding only when strict UTF-8 has failed and the complete Windows-1252 compatibility assessment has succeeded.

An undefined/unsupported Windows-1252 byte is therefore a pre-transcoding compatibility-assessment refusal. No CVT candidate may be represented as successfully converted from a source whose compatibility scan found an undefined byte.

The compatibility assessment must not substitute U+FFFD, reinterpret an undefined Windows-1252 byte as ISO-8859-1, or use permissive host/library decoder behavior to make an incompatible source convertible.

Compatibility means that every physical source byte can be mapped deterministically by the complete normative WASM-002 Windows-1252 mapping in W002-CONV-002.4. Successful EOF produces the governed outcome COMPATIBLE.

No statistical detector, locale rule, browser guess, replacement character, ISO-8859-1 substitution, best-effort decoder, or PRODUCT-scoped glossary text participates as normative authority in this determination.

COMPATIBLE means only that the complete byte stream is convertible under Data Sculptor's frozen Windows-1252 mapping. It must not be described as proof that Windows-1252 was historically, authoritatively, or intentionally the source file's original encoding.

If the compatibility pass encounters a byte that W002-CONV-002.4 defines as undefined, the assessment stops at the first such byte and returns INCOMPATIBLE. Data Sculptor must not substitute a replacement character, reinterpret the byte under another code page, or continue as though conversion were safe.

A later explicit conversion Work Order must apply the same complete WASM-002 mapping and the same refusal rule.

This requirement is the complete normative Windows-1252 mapping authority for WASM-002. It covers all 256 possible byte values. No PRODUCT-scoped glossary entry or host/library decoder is required to interpret compatibility or conversion.

0x00–0x7F

Every byte 0x00 through 0x7F maps one-to-one to Unicode U+0000 through U+007F.

0x80–0x9F

0xA0–0xFF

Every byte 0xA0 through 0xFF maps one-to-one to Unicode U+00A0 through U+00FF.

Undefined-byte rule

The only undefined byte values in this frozen WASM-002 mapping are exactly 0x81, 0x8D, 0x8F, 0x90, and 0x9D. Encountering any one of them makes the complete compatibility assessment INCOMPATIBLE at the first such byte and causes an explicitly run conversion Work Order to refuse before transcoding rather than guess.

These three ranges plus the 32-position table above exhaust the byte domain 0x00–0xFF. No unlisted byte value exists.

The compatibility check is one bounded-memory deterministic sequential pass from physical source byte offset 0 to EOF unless the first undefined Windows-1252 byte is encountered earlier. Buffer/window size must not change the compatibility outcome or the first undefined-byte offset.

On INCOMPATIBLE, WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET is the zero-based absolute physical source-byte offset of the first undefined byte. On COMPATIBLE, that offset is NOT_APPLICABLE. If the assessment begins but an independent read/host failure prevents a governed compatibility conclusion, the outcome is NOT_AVAILABLE and the first-undefined-byte offset is NOT_AVAILABLE. The assessment itself publishes no converted output.

Help may suggest the separate CONVERT WINDOWS-1252 TO UTF-8 Work Order only when the governed engine emits DS-CNV-001 after a complete compatibility assessment returned COMPATIBLE. The suggestion is therefore derived from a governed diagnostic fact, not from the UTF-8 failure itself.

If the assessment returns INCOMPATIBLE, is NOT_AVAILABLE, or did not run, DS-CNV-001 is not emitted and Help must not invent the conversion recommendation.

P3-08 Help disclosure: when conversion succeeds, Help must state that the published CVT is a new governed source artifact with its own source identity and that converting a refreshed legacy source later will publish another distinct CVT rather than refresh an earlier CVT-backed Store lineage. When a CVT is selected for first materialization, Help must disclose the same consequence before or with the normal materialization guidance: the Store lineage is anchored to the exact CVT filename, not to the analyst-owned pre-conversion filename. Help must not imply hidden lineage continuity across separate CVT artifacts.

The suggestion must state that the current analytical task has already stopped/refused because strict UTF-8 certification failed. DS-CNV-001 is informational and must not be rendered as though materialization can continue from the failed run.

The suggestion must state that the compatibility assessment was read-only and that Data Sculptor did not change the analyst-owned source. Any later successful conversion publishes a separate governed CVT artifact rather than editing the original source in place.

The suggestion must describe the complete source as compatible with Data Sculptor's supported Windows-1252 converter. It must not say that the source was definitively identified as Windows-1252 or imply provenance that the compatibility pass cannot prove.

The suggestion must make clear that conversion is a separate user-authorized Work Order. next_action: RUN_WINDOWS_1252_CONVERSION means that the separate operation is a governed safe option; it is not permission for Data Sculptor to silently transcode, modify the source, or reinterpret the refused analytical Work Order.

If the compatibility outcome is INCOMPATIBLE, NOT_AVAILABLE, or NOT_RUN, Help must not recommend Windows-1252 conversion as though it were safe. In particular, the mere presence of DS-ENC-001 never authorizes that recommendation.

A successful Windows-1252 conversion task must produce canonical UTF-8 output suitable for later submission to the normal UTF-8 certification and materialization path.

P3-08 lineage consequence: the successful conversion output is a new immutable governed CVT artifact with its own exact physical filename. That CVT filename is the source identity used by later Store routing. A later conversion, including one made from a refreshed analyst-owned legacy source with the same original filename, publishes a different CVT and therefore does not refresh, replace, or continue an earlier CVT-backed Store lineage merely by name association. On first materialization, each distinct CVT begins a new Store lineage unless that exact CVT filename already routes to an existing lineage under the normal Store rules.

F-14 CVT identity and publication: the final converted-source filename is exactly __DS__CVT__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv. Conversion writes first to the corresponding W002-STOR-023.1 SCR identity with the same UTC, UUID and .csv extension. Only after bounded conversion completes, the candidate closes/reopens successfully, and the converted bytes satisfy the governed strict UTF-8 requirement may the class token be renamed to CVT. CSV structural interpretation remains governed by the later normal certification/materialization path; CVT publication does not assert that the converted source is structurally valid CSV.

F-10 conversion semantics — encoding conversion only

The conversion operation performs deterministic character transcoding only. It does not parse, repair, normalize, or reinterpret CSV structure.

• Commas remain commas.
• Double quotes remain double quotes.
• Ordinary ASCII bytes retain the same byte value.
• LF remains LF.
• CR remains CR.
• CRLF remains CRLF.
• Embedded CR/LF bytes are preserved in place; the converter does not decide whether they are record terminators or field content.

Canonical UTF-8 output therefore means deterministic UTF-8 encoding of the accepted source characters, not normalization of line endings, quoting, delimiters, records, headers, or fields.

F-10 BOM rule

• The published CVT is UTF-8 without a BOM; Data Sculptor does not prepend EF BB BF.
• If the source failed strict UTF-8 classification, a leading source byte sequence EF BB BF is not blindly stripped as though it were a UTF-8 BOM. Under the Windows-1252 conversion path those source bytes are source data and are mapped according to the frozen Windows-1252 mapping.
• BOM interpretation remains subordinate to encoding classification rather than acting as a blind prefix-removal rule.

The canonical RCP for a successful governed Windows-1252-compatible conversion must identify exactly SOURCE_ENCODING: WINDOWS-1252-COMPATIBLE.

That operation-specific fact is carried within the canonical TXT Receipt governed by W002-RCP-001 through W002-RCP-010. Only that exact serialized spelling is permitted for this key/value pair.

The canonical RCP for a successful governed conversion must identify exactly MATERIALIZED_ENCODING: UTF-8.

This uses the canonical KEY: VALUE serialization frozen by W002-RCP-005. MATERIALIZED_ENCODING=UTF-8 is not valid canonical Receipt serialization.

The canonical RCP for successful conversion must identify that transcoding was performed under the governed bounded/streaming conversion contract.

Every governed user-visible failure or warning produced by WASM-002 must originate as a canonical diagnostic event. A diagnostic event must have a stable identity and structured facts independent of its final wording.

Governed success/status events that participate in the Help/status/evidence system—such as a successfully saved Work Order or a successfully validated Suitcase—are canonical INFO diagnostic events and obey the same identity/fact/behavior contract. Ordinary static labels, headings, decorative copy, and presentation-only status text are not automatically diagnostics merely because they are visible in the UI.

Every canonical diagnostic event must carry one stable identifier using the exact form DS-<DOMAIN>-<NNN>.

DOMAIN is exactly three uppercase ASCII letters A through Z. NNN is exactly three decimal digits, zero-padded, in the range 001 through 999. Examples include DS-ENC-001, DS-WKO-001, DS-STO-001, DS-MAT-001, and DS-HLP-001.

A diagnostic ID is permanent after allocation and must never be reused for a different diagnostic meaning. Severity, host, build/release, source filename, path, UUID, byte offset, row/column number, count, timestamp, occurrence ID, and other run-specific facts must not be encoded into the diagnostic ID; those values belong in structured diagnostic fields. The identifier is the canonical lookup key used by the Help message catalog.

Day 060 H-04 pre-freeze identifier normalization: the Windows-1252 compatibility suggestion diagnostic is DS-CNV-001. It follows the same exact three-letter DOMAIN grammar as every other diagnostic ID. No four-letter DOMAIN exception exists in the current WASM-002 contract. Any pre-H-04 draft spelling of this diagnostic is superseded and is not valid build-registry input.

Every canonical diagnostic event must carry exactly one severity token: INFO, WARNING, or ERROR.

Severity classifies the condition for human and machine interpretation. It does not itself determine whether execution continues or refuses; that authority is carried separately by the canonical behavior field.

Every canonical diagnostic event must identify the governed operation or phase using an uppercase ASCII snake-case token matching [A-Z][A-Z0-9]*(?:_[A-Z0-9]+)*.

Examples include WORK_ORDER_VALIDATION, SOURCE_CERTIFICATION, MATERIALIZATION, STORE_PUBLICATION, and HELP_REPORT. These examples do not constitute a closed global phase list; the fixed phase for each allocated diagnostic is declared by that diagnostic's registry entry.

The canonical event carries diagnostic-specific evidence in a structured facts object. Fact keys use lowercase ASCII snake case matching [a-z][a-z0-9]*(?:_[a-z0-9]+)*.

Each diagnostic registry entry declares disjoint required_facts and optional_facts sets. Every required fact must be present when that diagnostic is emitted. An optional fact key may be omitted when that fact is not emitted for the event, but omission itself has no governed absence-state meaning: it must not be interpreted as NONE, NOT_RUN, NOT_AVAILABLE, NOT_APPLICABLE, false, zero, or an empty string. An emitted fact key that is not declared for that diagnostic is invalid.

For structured JSON diagnostic facts, an established ordinary value retains its native JSON type. When a present diagnostic fact must express one of the shared governed absence states, its value is the exact JSON string "NONE", "NOT_RUN", "NOT_AVAILABLE", or "NOT_APPLICABLE", with the meaning frozen by F-18. JSON null is not a generic encoding for diagnostic-fact absence; it is permitted only where a specific JSON schema explicitly declares a nullable field and defines what that null means, as W002-HELP-009 does for HLP lineage.

A required diagnostic fact may not be silently omitted, defaulted, converted to null, guessed, or replaced by a Help-layer value. If Data Sculptor attempts to establish a registered diagnostic but cannot produce one or more facts declared required for that diagnostic, the intended diagnostic is not emitted. Instead the engine emits DS-HLP-001 under W002-HELP-001.8. The replacement event records the intended diagnostic ID and the complete sorted set of missing required fact names. No partially populated copy of the intended diagnostic may be presented beside it.

This fail-closed substitution is a diagnostic-contract integrity rule, not a presentation fallback. It preserves the F-17 boundary that diagnostics own facts and Help renders only complete governed diagnostic truth.

Every canonical diagnostic event must carry exactly one execution-behavior token: CONTINUE or REFUSE.

This field is the governed continue/refuse decision for the event. Help wording, severity, UI color, or presentation must not independently weaken, strengthen, or reinterpret it.

Every canonical diagnostic event must carry a next_action token using uppercase ASCII snake case matching [A-Z][A-Z0-9]*(?:_[A-Z0-9]+)*. NONE is the canonical value when no safe governed next action applies.

The token expresses stable machine-readable intent; Casual, Office Speak, and Technical wording for that action belongs to the Help layer. Run-specific values such as timestamps, paths, UUIDs, byte offsets, filenames, counts, or occurrence IDs remain structured facts and do not change the diagnostic identity or fixed next-action meaning.

Damaged-Store guidance is part of the safe-next-action contract. When ordinary materialization refuses because exact source routing identifies an INVALID Store lineage, or a DEGRADED lineage whose every mapped COL is broken and therefore cannot be reduced to a non-empty successor by REPAIR MAP, the selected Help voice must preserve the same frozen choices and consequences rather than inventing a recovery operation. The explanation must identify the blocked lineage/current MAP and distinguish: external restoration under the original governed physical filename followed by the required governed validation tier; source rename to deliberately begin a separate new Store lineage; and analyst retirement of the damaged lineage by moving all of that lineage's Store MAPs out of the active Suitcase root. For retirement, Help must warn that moving only the latest MAP can expose an older structurally valid MAP as current. Help must not claim that matching the original filename proves historical byte identity, and must not describe any of these analyst filesystem actions as Data Sculptor-authored repair, deletion, RID regeneration, or silent lineage replacement.

P3-07 malformed-MAP routing guard: when ordinary materialization refuses because no routable Store lineage can be established while one or more structurally malformed Store-MAP-class artifacts are present in the active Suitcase, Help must identify the malformed MAP artifact or artifacts and state that new-Store/RID creation was blocked to prevent a silent lineage fork. Help must not describe the missing structurally valid MAP as proof that the prior Store never existed, and must not invent a Data Sculptor repair or replacement operation for this condition.

P3-10 delimiter-hint clarification: when Stage 2 refuses with INVALID_BYTE_AFTER_CLOSING_QUOTE and the offending byte is semicolon (0x3B) or horizontal TAB (0x09), Help may include the governed delimiter-mismatch hint even though the refusal occurred before header-delimiter resolution. The hint is explanatory only: it must not change the canonical refusal condition, location facts, behavior, or safe-action boundary.

F-16 conversion-suggestion boundary: strict UTF-8 refusal diagnostic DS-ENC-001 has fixed next_action: NONE. UTF-8 failure alone does not establish that any converter is safe. Only the separate compatibility diagnostic DS-CNV-001, emitted after the complete governed Windows-1252 compatibility assessment returns COMPATIBLE, may carry next_action: RUN_WINDOWS_1252_CONVERSION. That token identifies a safe separately authorized option; it never resumes or rewrites the refused analytical Work Order.

Day 060 H-12 damaged-lineage diagnostic binding

• ordinary MATERIALIZE refusal for a routed INVALID Store uses DS-MAT-014 and its declared facts;
• ordinary MATERIALIZE refusal for a DEGRADED Store whose every mapped COL is broken uses DS-MAT-015 and its declared facts;
• the no-routable-lineage / malformed-Store-MAP guard uses DS-MAT-016 and its declared facts.

These specialized allocations are what permit closed-world Help to identify the blocked lineage/current MAP or malformed MAP artifacts without adding unrelated facts to the ordinary DS-MAT-010 validation diagnostic.

The shared Rust/WASM diagnostic path must provide the canonical semantic core required by Help: diagnostic_id, severity, phase, behavior, facts, and next_action. The fixed values and permitted fact-key sets for an allocated diagnostic are governed by diagnostics.json.

Casual, Office Speak, and Technical prose belongs to the Help rendering layer rather than being duplicated as authored message sets inside the governed engine. Host/build/occurrence metadata may be carried by surrounding governed execution evidence, but it must not redefine the diagnostic semantic core.

F-16 closed-world Help rule: Help may recommend the WASM-002 Windows-1252 conversion Work Order only when the governed engine emitted DS-CNV-001. Help must not infer compatibility from DS-ENC-001, byte appearance, file extension, locale, browser behavior, heuristic encoding detection, or prose outside the diagnostic facts.

The human-inspectable development/build source for the WASM-002 diagnostic registry is exactly diagnostics.json, encoded as UTF-8 without BOM. It is Data Sculptor product/build content, not a Suitcase artifact; it must not use the __DS__ namespace, consume an artifact-class token, or be copied into an analyst's Suitcase merely because Data Sculptor runs.

The top-level JSON object has exactly two fields: registry_version and diagnostics. registry_version is the string "1". diagnostics is an array written in ascending UTF-8 byte order of diagnostic_id.

Each diagnostic entry has exactly seven fields: diagnostic_id, severity, phase, behavior, next_action, required_facts, and optional_facts. Diagnostic IDs must be unique and satisfy W002-HELP-001.1. Severity, phase, behavior, and next-action values must satisfy W002-HELP-001.2 through W002-HELP-001.6. required_facts and optional_facts are arrays of canonical fact-key strings sorted in ascending UTF-8 byte order; keys must be unique within each array and the two arrays must be disjoint.

{
  "registry_version": "1",
  "diagnostics": [
    {
      "diagnostic_id": "DS-CNV-001",
      "severity": "INFO",
      "phase": "SOURCE_CERTIFICATION",
      "behavior": "CONTINUE",
      "next_action": "RUN_WINDOWS_1252_CONVERSION",
      "required_facts": ["source_filename", "windows_1252_compatibility_outcome"],
      "optional_facts": []
    },
    {
      "diagnostic_id": "DS-ENC-001",
      "severity": "ERROR",
      "phase": "SOURCE_CERTIFICATION",
      "behavior": "REFUSE",
      "next_action": "NONE",
      "required_facts": ["first_invalid_byte_offset", "source_filename", "stop_reason"],
      "optional_facts": ["analytical_outputs_published", "materialization_started", "source_modified_by_data_sculptor", "store_state_committed"]
    },
    {
      "diagnostic_id": "DS-HLP-001",
      "severity": "ERROR",
      "phase": "DIAGNOSTIC_ASSEMBLY",
      "behavior": "REFUSE",
      "next_action": "NONE",
      "required_facts": ["intended_diagnostic_id", "missing_required_facts"],
      "optional_facts": []
    }
  ]
}

The PRD does not need to enumerate every allocated WASM-002 diagnostic row. The complete registry delivered with the build is retained acceptance evidence. A diagnostic ID becomes permanent once allocated and must not later be reused for a different meaning.

Build validation must fail on malformed JSON; extra/missing entry fields; duplicate or noncanonical diagnostic IDs; invalid fixed tokens; unsorted, duplicate, overlapping, or invalid fact-key declarations; engine diagnostic definitions whose fixed semantics disagree with the registry; engine diagnostic definitions absent from the registry; Help-catalog IDs absent from the registry; or Help placeholders that name facts not declared as required or optional by the matching diagnostic.

F-07 DS-ENC-001 fact mapping: the canonical lower-case diagnostic facts for strict UTF-8 refusal are first_invalid_byte_offset, source_filename, and stop_reason. For this diagnostic, stop_reason is exactly INVALID_UTF8_SEQUENCE. The generic fact name byte_offset is retired for this UTF-8 refusal diagnostic.

P2-03 clock-order diagnostic facts: whichever stable WASM-002 Diagnostic ID is allocated to refusal because a successor Store MAP or WKO MAP cannot satisfy the strict monotonic UTC publication guard must declare these exact lower-case required facts in its diagnostic-registry entry: map_profile, observed_host_utc, predecessor_map_filename, and predecessor_utc. map_profile has exactly two permitted values: STORE for a Store-MAP chronology guard and WKO for a Work-Order-registry-MAP chronology guard. These facts identify both the governed MAP profile, the blocking predecessor artifact, and the truthful clock observation that caused refusal.

F-16 DS-CNV-001 allocation: DS-CNV-001 is emitted only when the complete read-only compatibility assessment under W002-CONV-002 through W002-CONV-002.5 reaches EOF with outcome COMPATIBLE. Its required fact windows_1252_compatibility_outcome is therefore exactly the JSON string "COMPATIBLE". behavior: CONTINUE means this informational diagnostic introduces no additional refusal; it does not reverse the already-established DS-ENC-001 refusal or resume Stage 2.

F-17 DS-HLP-001 allocation: DS-HLP-001 is the canonical fail-safe event when the engine cannot satisfy the complete required-fact contract of an intended registered diagnostic. intended_diagnostic_id is the exact canonical ID that was being assembled. missing_required_facts is a JSON array of every missing required fact-key string, sorted in ascending UTF-8 byte order with no duplicates. The intended diagnostic is suppressed rather than emitted incompletely. DS-HLP-001 always refuses and has next_action: NONE.

F-22 QA-independence boundary: diagnostics.json is authoritative for the fixed semantic contract of an allocated Diagnostic ID — its ID, severity, phase, behavior, next action, and permitted required/optional fact keys — but the implementation-delivered registry is not, by itself, an independent oracle proving that every arbitrary runtime condition was mapped to the correct Diagnostic ID. WASM-002 does not require a second QA-owned registry duplicating every implementation allocation.

Where this PRD independently freezes a condition-to-diagnostic mapping or exact required facts — including the named DS-ENC-001, DS-CNV-001, and DS-HLP-001 contracts and other explicitly pinned diagnostic facts — that PRD text remains normative and acceptance must test the mapping independently of the implementation registry. For allocations not independently pinned by the PRD, WASM-002 accepts the validated build registry as the build allocation while retaining all registry-shape, permanence, semantic-agreement, fact-discipline, and Help cross-validation gates. This is an explicit accepted QA-scope risk, not a claim of independent condition-to-ID verification.

Day 060 H-02 fixture-pinned diagnostic allocations

The following allocations are normative for the byte-exact Receipt acceptance corpus. They are genuine product diagnostics, not QA-only placeholder IDs. Every row has severity: ERROR, behavior: REFUSE, next_action: NONE, the phase shown below, the listed required facts, and an empty optional_facts array unless another requirement explicitly adds optional facts later. The existing DS-ENC-001 remains the Stage-1 invalid UTF-8 diagnostic and is reused by the H-02 Stage-1 compatibility-state fixtures.

Day 060 H-04 normalization: all allocated Diagnostic IDs in the current WASM-002 contract, including DS-CNV-001, use exactly three ASCII uppercase letters in DOMAIN. No exception exists.

Day 060 H-12 / BM-09 specialized diagnostic allocations

The H-02 fixture diagnostics above are intentionally narrow. In particular, publication diagnostics whose required facts are only artifact_class and collision_retry_count mean identity-allocation collision exhaustion, not every possible publication failure. Other publication failures receive distinct registry allocations unless another requirement independently pins their Diagnostic ID.

The following additional pre-freeze allocations are normative because existing Help duties require fact contracts that the broad H-02 fixture IDs cannot truthfully carry. Every row has severity: ERROR, behavior: REFUSE, and next_action: NONE except DS-MAT-017, whose next_action is RUN_REPAIR_MAP. optional_facts is empty unless another requirement explicitly extends it.

Closed-world Help consequence: Help may render the richer damaged-lineage, malformed-MAP, and monotonic-UTC explanations only from the applicable specialized diagnostic event above. It must not borrow undeclared facts from DS-MAT-010 or from a collision-exhaustion publication diagnostic merely because those facts are available elsewhere at runtime.

Cross-operation UTC rule: DS-UTC-001 has one stable semantic condition across Store-MAP and WKO-MAP successor publication. The required map_profile fact tells closed-world Help which governed MAP profile encountered the chronology guard: STORE means Store MAP and WKO means Work Order registry MAP. Help must select profile-appropriate explanation and analyst exits only from that declared fact and the other registered event facts; it must not infer the profile from filename shape, surrounding host state, or an undeclared operation field. The shared Diagnostic ID therefore does not need profile-specific clones.

The Help Engine must support the three established Data Sculptor help voices. All three renderings must preserve the same diagnostic truth. Voice selection may change wording, sentence structure, degree of technical detail, and explanatory style.

F-24 session default and persistence: Technical is the canonical Help voice at the start of every new browser application instance. The analyst may select Casual or Office Speak during that instance, but WASM-002 retains the selected voice only in volatile runtime state and does not persist the preference in browser-private storage. A new application instance therefore returns to Technical. This default does not alter the F-17 rule that a missing diagnostic-specific catalog entry visibly falls back to Generic Technical Help.

Tests must assert parity on the canonical event and structured facts, not brittle equality of prose.

The Help layer resolves a canonical diagnostic ID through one validated catalog that associates an authored ID with Casual, Office Speak, and Technical templates. The human-maintained development source is exactly help_messages.json, encoded as UTF-8 without BOM.

help_messages.json is a Data Sculptor product/build resource, not a Suitcase artifact. It must not use the __DS__ governed artifact namespace, consume a semantic artifact-class token, or be copied into an analyst's Suitcase merely because Data Sculptor runs. Run-specific structured facts remain authoritative in the canonical diagnostic event and are supplied separately to the selected template. The three authored voices must not be maintained as unrelated message stores.

F-17 coverage fallback: absence of an authored catalog entry for an otherwise complete registered diagnostic is permitted at run time and does not make the diagnostic incomplete. Data Sculptor must instead render the deterministic Generic Technical Help view defined by W002-HELP-002.9. The fallback consumes only the canonical event semantic core and its emitted governed facts; it is not a second message catalog and does not manufacture replacement diagnostic facts.

WASM-002 acceptance does not require the complete production Help corpus. Authored catalog entries may use unmistakable placeholder strings, and placeholder entries may be generated mechanically from the validated diagnostics.json registry; no production prose authorship is required.

Deterministic Generic Technical Help fallback. When a complete registered canonical diagnostic has no matching entry in help_messages.json, all selected Help voices fall back visibly to one Generic Technical rendering. The rendering must show, in this exact conceptual order, the diagnostic ID, severity, phase, behavior, next-action token, and then every emitted governed fact ordered by ascending UTF-8 byte order of fact key. It must state that no diagnostic-specific authored explanation is available. It must not infer cause beyond the diagnostic, invent remediation, default missing facts, inspect undeclared external state, or substitute prose for governed fact values.

The Generic Technical fallback preserves the original diagnostic unchanged. Catalog incompleteness is therefore distinct from diagnostic incompleteness: a valid event can always be rendered generically, while inability to satisfy the event's own required_facts contract suppresses that intended event and produces DS-HLP-001 under W002-HELP-001.4 and W002-HELP-001.8.

Acceptance must prove correct diagnostic-ID lookup, selected-voice resolution, structured-fact interpolation where a template exists, voice switching, deterministic Generic Technical fallback for a deliberately absent catalog entry, and semantic parity across authored voices. Final authored Help wording, examples, editorial polishing, and production-corpus quality remain deferred to a later Help-content milestone.

The top-level JSON object has exactly two fields: catalog_version and messages. catalog_version is the string "1". messages is an array written in ascending UTF-8 byte order of diagnostic_id.

Each message entry has exactly four fields: diagnostic_id, casual, office_speak, and technical. diagnostic_id must satisfy the canonical DS-<DOMAIN>-<NNN> grammar and must be unique in the catalog. Each voice field is a JSON string.

A voice string may contain zero or more structured-fact placeholders using the exact form {fact_name}. Each catalog diagnostic_id must exist in the validated diagnostics.json registry, and each referenced placeholder must be declared in that diagnostic's required_facts or optional_facts. Duplicate IDs, missing voice fields, null voice values, malformed JSON, noncanonical or unregistered diagnostic IDs, or undeclared fact placeholders make catalog validation fail.

The catalog is intentionally allowed to be non-exhaustive. A registered diagnostic with no message entry is rendered through the deterministic Generic Technical fallback in W002-HELP-002.9. Therefore a missing catalog entry for a registered diagnostic is not a build-validation failure and must not cause the engine to synthesize an authored entry or suppress the diagnostic.

WASM-002 therefore does not require one global exhaustive fact-name table in the PRD. Fact-key authority is per diagnostic: the validated registry declares which fact names are legal for each stable diagnostic meaning.

{
  "catalog_version": "1",
  "messages": [
    {
      "diagnostic_id": "DS-ENC-001",
      "casual": "[CASUAL PLACEHOLDER] {source_filename}",
      "office_speak": "[OFFICE PLACEHOLDER] {source_filename}",
      "technical": "[TECHNICAL PLACEHOLDER] {source_filename} {first_invalid_byte_offset} {stop_reason}"
    }
  ]
}

Later Help-content revisions may extend or version this schema only through an explicit PRD revision.

F-07 placeholder mapping: Help for the strict UTF-8 refusal may render {first_invalid_byte_offset} and {stop_reason} because those exact fact names are declared by the canonical DS-ENC-001 diagnostic registry entry. The older generic {byte_offset} placeholder is not valid for DS-ENC-001.

P2-03 Help rendering duty: Help for the monotonic-UTC refusal must identify the exact blocking predecessor MAP and show both predecessor UTC and truthful observed host UTC. It must distinguish an incorrect host clock from a genuinely future-dated governed MAP and may explain the approved analyst-owned choices: correct the clock, wait/rerun after truthful time advances, or deliberately move the exact future-dated current MAP out of the active Suitcase root with the warning that an older snapshot/registry may become current and that restoring the moved MAP may restore its authority.

Before a WASM-002 browser build is accepted, the build must parse and validate help_messages.json, then serialize the validated catalog directly into the Data Sculptor HTML itself as one non-executable application/json payload with the exact element ID ds-help-catalog.

The embedded JSON must be HTML-safe so catalog text cannot terminate the containing script element; at minimum, literal less-than characters in JSON string content must be escaped during embedding. At runtime, the browser host obtains this embedded payload and supplies the validated catalog to the shared Rust/WASM Help core. Browser JavaScript must not implement a competing template-selection, fact-interpolation, fallback, escaping, or HLP-semantic engine. The browser host must not fetch a Help catalog from the network, the filesystem, the Suitcase, or an adjacent deployment file.

Missing or malformed embedded catalog JSON, or a build whose embedded catalog does not correspond to the validated build input, is a build-validation failure. The released HTML therefore remains one offline portable front door for the browser Help catalog. A later native host may supply the same governed catalog semantics to the same shared core from its own build-bundled resource; host packaging may differ, but Help semantics must not fork.

The Help Engine must support both live and durable help surfaces.

The concise message is rendered in the dedicated browser Help / Diagnostic Surface when that surface is present; it is not required to be a modal or transient notification.

A concise Help message for an individual diagnostic and any durable Help Report that includes that diagnostic must resolve from the same canonical diagnostic event. A durable Help Report request may cover one active governed diagnostic, including a non-run diagnostic, or one governed run containing one or more canonical diagnostic events. Exactly one HLP is published for each explicit Help Report request.

A saved Help report must be able to include the following elements when relevant.

The report may include only source and Work Order context permitted by W002-HELP-010. Durable HLP disclosure is intentionally stricter than transient local Help because the HLP is a portable support-handoff artifact.

A relevant governed alias or source header may enter the HLP only under the necessity and disclosure rules in W002-HELP-010. Source-header text is eligible only when Data Sculptor has structurally established an actual CSV header record under the governed parser. Record position alone does not make text a header. When no valid header record has been established, including the headerless-source refusal case, the HLP must use structural evidence such as the 1-based column ordinal, diagnostic condition/location, or an applicable operational fallback name and must not substitute field data from the first data row.

Absolute local paths, entire Work Orders, Work Order comments, source rows/values, unrelated headers/aliases/columns, and unrelated Suitcase contents are not automatically eligible merely because they are available to the running application.

The report must carry its own governed HLP filename and generation UTC together with the diagnostic identity and applicable originating execution lineage. The exact HLP provenance contract is governed by W002-HELP-009.

When the governed diagnostic context can determine the execution boundary, the canonical fact names are exactly:

• source_modified_by_data_sculptor
• materialization_started
• analytical_outputs_published
• store_state_committed

When one of these facts has an established Boolean value, the JSON/structured value is the native Boolean true or false, never the strings "TRUE" or "FALSE".

source_modified_by_data_sculptor states only whether Data Sculptor modified the analyst-owned source in place; it must not imply knowledge that no external process or analyst changed the source between sessions.

materialization_started records whether the governed analytical materialization phase began.

analytical_outputs_published records whether governed analytical outputs were successfully published for user use; transient SCR candidates or abandoned/uncommitted debris do not make this fact true.

store_state_committed records whether the successor Store MAP commit point was crossed.

If a present boundary fact must express governed absence rather than an established Boolean, its JSON/structured value is the exact applicable shared absence-state string "NONE", "NOT_RUN", "NOT_AVAILABLE", or "NOT_APPLICABLE". JSON null is not a valid encoding for these four boundary facts because it would discard the reason for absence. A boundary fact that is optional for a particular diagnostic may instead be omitted under W002-HELP-001.4; that omission carries no absence-state meaning.

A missing, omitted, unavailable, or not-run fact must never be interpreted as false. If one of these facts is declared required for an intended diagnostic and the required value cannot be produced, it must not be silently defaulted; the intended diagnostic is suppressed and the fail-safe DS-HLP-001 contract in W002-HELP-001.4/W002-HELP-001.8 applies.

Included lineage must obey the disclosure boundary defined for Help reports and must not automatically expand into source-data disclosure.

Given the same canonical diagnostic event or ordered set of events, selected voice, PRETTY rules, validated Help catalog, and built-in presentation version, Help rendering must be deterministic except for explicitly permitted event/report-specific fields.

The Help renderer may consume only the canonical diagnostic fields and fact keys declared by the applicable diagnostic registry entries plus fields explicitly defined by the applicable HLP provenance schema. It must not inspect or interpolate an open-ended host-state bag, undeclared browser state, unrelated Suitcase contents, or another value merely because it is available at runtime.

A future configurable Brand Manifest may add another governed presentation input, but it is not part of the WASM-002 rendering contract.

The Help Engine must be designed for use by the browser host and the later native CLI host without changing diagnostic semantics. The shared Rust core owns diagnostic-to-template selection, governed fact interpolation, deterministic fallback behavior, governed escaping, and durable HLP semantic serialization.

The WASM-002 browser host supplies the validated catalog embedded under W002-HELP-002.11. A later native host may supply the same governed catalog semantics from a build-bundled native resource. Host-specific presentation and packaging may differ, but they must not create a second Help semantic engine or change canonical diagnostic identity, facts, behavior, next action, voice semantics, disclosure policy, or HLP meaning.

The live Help / Diagnostic Surface and the saved HTML Help Report must render from the canonical diagnostic event. Neither surface may independently create, reinterpret, weaken, suppress, or override governed diagnostic truth.

The user must be able to generate a styled, self-contained HTML Help Report from a governed diagnostic event for retention, IT/support handoff, or communication to another analyst.

The report must support two audiences in one document: a human-readable explanation using the selected Help voice and a clearly inspectable structured-facts section that preserves the technical evidence required to understand the event.

When relevant to the diagnostic, the report must render the governed values of source_modified_by_data_sculptor, materialization_started, analytical_outputs_published, and store_state_committed. These values originate from governed execution state rather than reassuring prose invented by the renderer. A missing/unavailable fact is not rendered as false.

The report must identify the originating WKO physical filename when one applies and may include only the minimum executable Work Order clause or clauses needed to establish the governed operation, user intent, and trigger for the diagnostic. It must not automatically embed the entire Work Order or Work Order comments. All such context remains subject to the fixed disclosure boundary in W002-HELP-010.

A durable generated Help Report is an immutable governed HLP artifact whose physical filename is:

__DS__HLP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.html

The UTC token is the HLP's own governed generation/publication time. The report is the final self-contained HTML artifact using the canonical built-in Red5Sorcery/Data Sculptor presentation; no unstyled intermediate is the canonical HLP.

Report-request multiplicity: one explicit Help Report request publishes exactly one HLP. The request may be bound to one active governed diagnostic, including a diagnostic that is not associated with a Run, or to one governed Run containing one or more canonical diagnostic events. A Run-level report includes the governed diagnostic events selected by that request in deterministic event order. HLP generation is never an automatic one-artifact-per-diagnostic side effect.

Every HLP must expose a visible deterministic Provenance section and exactly one embedded non-executable application/json payload whose element ID is exactly ds-hlp-provenance. F-34 supersedes the earlier draft schema version "1". For schema version "2", the JSON top-level object contains exactly these ten fields:

{
  "schema_version": "2",
  "hlp_filename": "__DS__HLP__20260922T191500123Z__<uuid-v4>.html",
  "hlp_generation_utc": "20260922T191500123Z",
  "diagnostic_ids": ["DS-ENC-001", "DS-MAT-004"],
  "originating_wko_filename": "__DS__WKO__...txt",
  "originating_rcp_filename": null,
  "selected_help_voice": "technical",
  "presentation_id": "red5sorcery-data-sculptor",
  "presentation_version": "1",
  "data_sculptor_build": "<exact-build-id>"
}

hlp_generation_utc must use the canonical fixed-width millisecond UTC form YYYYMMDDTHHMMSSmmmZ. diagnostic_ids is a non-empty JSON array containing one canonical diagnostic ID for each diagnostic event included in the report, in the same deterministic event order used by the report. Repeated IDs are permitted when distinct included events legitimately share one diagnostic type. selected_help_voice is exactly one of casual, office_speak, or technical, matching the Help catalog keys. For WASM-002 the built-in presentation identity is exactly red5sorcery-data-sculptor and its presentation version is exactly "1". data_sculptor_build must contain the exact running build identifier used for the tested/released build; the literal scope label WASM-002 alone is not sufficient unless it is also the exact build identifier.

originating_wko_filename and originating_rcp_filename are schema-declared nullable lineage fields. When the relationship exists and the exact physical filename is known, the value is that filename as a JSON string. When the relationship itself does not apply to this Help event/report request, the machine-readable value is JSON null. That null has one schema-defined meaning: the nullable relationship has no value, equivalent to Rust Option<T>::None and to the governed semantic state NOT_APPLICABLE. The visible Provenance section renders it as NOT APPLICABLE.

If the lineage relationship does apply but the exact filename cannot be obtained, JSON null must not be used; the field value is the exact string "NOT_AVAILABLE" and the visible Provenance section renders NOT AVAILABLE. Empty strings, invented lineage, N/A, UNKNOWN, or another substitute are forbidden. For these two lineage fields, null and "NOT_AVAILABLE" are deliberately non-interchangeable. A non-run HLP may therefore legitimately carry JSON null for both lineage fields when neither relationship applies.

This nullable-field rule is a schema-specific serialization choice, not a fifth absence state and not a generic JSON encoding rule. Other diagnostic JSON facts follow W002-HELP-001.4 and W002-HELP-004.11. The visible and machine-readable HLP provenance must express the same governed semantics even where their physical representations differ; a semantic mismatch is an HLP-generation failure and must not be silently tolerated.

The embedded JSON must be HTML-safe so provenance text cannot terminate the containing script element; at minimum literal less-than characters in JSON string content must be escaped during embedding. The provenance payload remains subject to W002-HELP-010 and must not introduce source rows, source values, absolute local paths, arbitrary Work Order content, or other context excluded by the fixed HLP disclosure policy.

WASM-002 does not automatically compute or embed a SHA-256 of the HLP, and saving an HLP must not create, refresh, or verify an LCK. The final HLP bytes remain eligible for exact-byte integrity evidence under the later explicit FINGERPRINT/LCK workflow. Configurable Brand Manifest provenance remains deferred to V1-BACKLOG / a future build.

F-14 HLP publication: the complete self-contained report is first written as the corresponding SCR candidate under W002-STOR-023.1. It must close, reopen, and validate the required visible Provenance section, exact schema-version-2 embedded JSON shape, HTML-safe serialization, self-contained presentation and visible/machine semantic parity before the class token may be renamed from SCR to HLP. A partial or semantically mismatched candidate never becomes a canonical HLP.

Generating a Help Report must not silently become a data-export path. WASM-002 therefore uses one deterministic allowlist rather than collecting broad context and attempting to redact it afterward. There are no disclosure checkboxes, permissive export modes, or per-report overrides in WASM-002.

Always eligible when present and applicable: diagnostic ID; severity/classification; governed operation/phase; continue/refuse decision; safe next action; selected Help voice; HLP identity and generation UTC; relevant governed artifact filenames; and the four canonical boundary facts from W002-HELP-004.11.

Eligible only when necessary to explain the diagnostic: the exact source filename but not an absolute OS path; a relevant source column header only when Data Sculptor has structurally established an actual CSV header record; the relevant 1-based column number; a relevant governed Store/RID/COL alias only when that alias itself is necessary to explain the diagnostic, such as an alias collision, ambiguity, or governed alias mutation; byte offset, row/count, or byte-length evidence; Store/RID/COL/MAP/WKO physical filenames; and only the minimum executable Work Order clause or clauses needed to establish intent and the diagnostic trigger. If that minimum Work Order excerpt necessarily contains a governed alias, that alias is disclosed and counts as alias text included.

Headerless boundary: record position alone never establishes a source header. If the governed parser has not established a valid header record, including a headerless-source refusal, HLP generation must not treat any field from the first data row or any later data record as header text. Structural evidence such as 1-based column ordinal, governed diagnostic/location facts, or an applicable operational fallback name must be used instead.

Never included automatically: source rows; source field values or arbitrary data samples; field data mislabeled as header text; absolute local paths; unrelated source headers, aliases, or column names; the complete Work Order; Work Order comments; unrelated Suitcase contents; browser/environment internals not governed as diagnostic evidence; or raw ungoverned stack traces.

Every generated HLP must contain a visible Disclosure section stating, at minimum: Source rows included: NO; Source values included: NO; Source header text included: YES or NO; Governed alias text included: YES or NO; Absolute local paths included: NO; Work Order comments included: NO; and Work Order excerpt: RELEVANT EXECUTABLE CLAUSES ONLY. The two YES/NO declarations must truthfully reflect the actual HLP bytes. A genuine established source header does not count as a source field value; this distinction applies only after the governed parser has established the header record. The renderer must not weaken any declaration when the underlying policy has not changed.

This durable-HLP allowlist does not prohibit transient local Help from showing a relevant governed alias or a genuinely established source header when useful to explain the same canonical diagnostic event. Local presentation does not enlarge what the portable HLP may disclose.

When an unexpected analytical result, row-alignment concern, or support question raises the possibility that an analyst-owned source changed between sessions, Data Sculptor-controlled guidance must flow through the Help Engine. Help must not imply that the engine monitored or cryptographically protected the source when it did not.

The explanation must distinguish ordinary analyst-controlled workflow from stronger optional evidence. It may ask whether the analyst edited, replaced, sorted, re-exported, synchronized, copied over, or otherwise changed the source after the Store was established.

For a suspected cross-session source change, Help must distinguish at least these evidence levels:

• No continuity evidence: state that cross-session byte continuity cannot be independently verified from filename/Store metadata alone.
• INVENTORY available: use filename, exact byte length, and last-modified metadata as lightweight clues; changed metadata may indicate that the source changed, while unchanged metadata must not be presented as proof of unchanged bytes.
• Explicit fingerprint evidence available: exact-byte SHA-256 evidence may establish whether the compared file bytes match or differ under the later governed FINGERPRINT workflow.

Help must not collapse these levels into one generic statement of certainty.

Ordinary WASM-002 materialization and Store inheritance must not automatically SHA-256 the source, recursively fingerprint the Suitcase, or maintain hidden whole-Suitcase surveillance merely to guard against the possibility that an analyst-owned file changed between sessions.

This is an intentional product boundary for the lone-office-analyst model. The product assumes the analyst normally controls the Suitcase, provides lightweight explicit INVENTORY evidence in WASM-002, preserves a later explicit FINGERPRINT path for stronger assurance, and relies on Help to explain unusual cross-session continuity questions proportionately.

WASM-002 must not create, refresh, or silently verify an LCK Suitcase Lock as a side effect of Work Order save, materialization, Store inheritance, INVENTORY, alias maintenance, or ordinary project use. LCK publication belongs to the explicit later-V1 FINGERPRINT workflow.

F-13 single-writer Help boundary: Help must distinguish cross-session continuity from concurrent writing. WASM-002 does not claim that two Data Sculptor tabs/windows can safely write the same Suitcase at once. User guidance must say to use one writing Data Sculptor context per Suitcase; read-only viewing is not itself a governed write. When a pre-commit guard detects that relevant governed state changed underneath an operation, Help must identify the changed authority where available and direct the analyst to refresh or reopen current state and rerun deliberately. It must not imply that Data Sculptor acquired a cross-tab lock, merged the competing work, or automatically rebased the refused transaction.

The PRETTY Engine must not decide analytical truth or reinterpret diagnostic meaning. It receives governed content and renders it into human-facing artifacts.

WASM-002 conceptual boundary: ENGINE TRUTH -> HELP / REPORT CONTENT -> PRETTY ENGINE -> BUILT-IN DATA SCULPTOR PRESENTATION -> ARTIFACT.

A future build may replace the built-in presentation source with a governed Brand Manifest without changing the analytical or diagnostic truth supplied to PRETTY.

The PRETTY Engine must provide a common rendering path for Data Sculptor artifacts that require governed human presentation, including at minimum the WASM-002 Help HTML report. WASM-002 uses the canonical built-in Red5Sorcery/Data Sculptor presentation. The architecture must permit the same path to accept a configurable Brand Manifest in a future build without changing analytical semantics.

The architecture must also permit later reuse for branded Receipt HTML, verification reports, tables, Quick Viz, and other PRETTY outputs. WASM-002 canonical run Receipts themselves remain TXT-only under W002-RCP-003.

Durable HTML artifacts produced by PRETTY must be self-contained for ordinary viewing after generation. Self-containment requires semantic and functional portability, not pixel-identical rendering across operating systems or browsers; ordinary system-font substitution and browser rendering differences are acceptable when meaning, evidence, hierarchy, and accessibility remain intact.

Required CSS, SVG, and other built-in presentation assets needed for ordinary viewing must be embedded or otherwise resolved into the generated artifact at creation time.

Future configurable Brand Manifest inputs, when implemented, must preserve this self-contained output rule.

PRETTY HTML must remain ordinary inspectable HTML. Presentation must not obscure the text, evidence, diagnostic code, provenance, or next-step guidance. The rendered artifact must remain usable without JavaScript when JavaScript is not required for its content.

Every material frozen WASM-002 behavior must have retained acceptance evidence sufficient to exercise the governed success, refusal, mutation, publication, or recovery boundary that makes the behavior meaningful. Related cases may share one fixture when the shared fixture proves each required condition explicitly; acceptance coverage must not rely on a behavior being difficult to reproduce under an uncontrolled host environment.

Permitted deterministic test-only seams. WASM-002 acceptance may use controlled clock values; controlled UUID sequences and collision outcomes; controlled filesystem create/write/close/rename/promotion failures; and controlled run-local source-handle reread/substitution conditions. A seam supplies only the external condition required to reach the governed behavior. It must not bypass validation, alter the normative semantic result, change governed serialization, relax publication rules, rewrite diagnostic truth, or create a second analytical execution model.

Release boundary. Test-only controls must not be invocable through the ordinary Data Sculptor UI, DS-STEPS, saved Work Orders, URL/query parameters, Suitcase configuration, or another analyst-facing product path. Compile-time exclusion, test-build configuration, or an isolated acceptance harness are permitted implementation techniques. Retained acceptance evidence must identify any seam used and must separately demonstrate that the accepted release surface cannot invoke that seam as a user feature.

Named storage acceptance gaps. Acceptance must include a case-variant governed namespace/class fixture proving that Data Sculptor does not silently normalize the variant spelling into canonical governed identity; an unknown syntactically valid governed-class fixture proving that the file remains byte-for-byte unchanged while a canonical INFO diagnostic and INVENTORY surface the unknown/unrecognized class; and at least one known-but-not-emitted-class fixture drawn from DGN, RCV, BRD, or LCK proving the same preserve-and-report behavior without activating a producer, lifecycle, or interpretation path.

Carried feature gates remain feature-owned. Mechanisms whose normative lifecycle is integrated in another package — including the F-02 Work Order-registry/alias-replacement behavior, the F-04 existing-Store cardinality refusal, and the F-24 CER-history decision — cannot be considered accepted without their corresponding feature acceptance gates. This requirement does not invent those feature semantics. If a proposed mechanism is removed from WASM-002 rather than integrated, no acceptance gate for that removed mechanism is required.

A valid multi-gigabyte UTF-8 fixture must complete whole-source certification with exact byte accounting under bounded memory.

A fixture containing an invalid UTF-8 sequence, including a sequence that crosses an input-window boundary, must deterministically produce STAGE1_UTF8_OUTCOME: FAIL, UTF8_STOP_REASON: INVALID_UTF8_SEQUENCE, and the exact governed zero-based UTF8_FIRST_INVALID_BYTE_OFFSET. Stage 2 must not begin and no analytical materialization output may be published.

The same bytes tested under different permitted Stage-1 input-window sizes and boundary placements must yield the same outcome, stop-reason token, and first-invalid offset.

An acceptance fixture must attempt to present Stage 2 with a different source instance/reference than the one retained from Stage 1. The run must refuse before materialization rather than accept the substitute merely because filename, alias, path, or byte length appears compatible.

F-23 governed seam: this fixture must use the test-only source-handle substitution/reread seam permitted by W002-QA-001 so the different Stage-2 instance is injected without changing the analyst-visible SOURCE syntax or adding a product-level source-selection path. Release-surface evidence must demonstrate that an analyst cannot invoke this substitution seam through the normal UI, Work Order, URL/query, or Suitcase configuration.