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.

Data Sculptor does not create scratch/cache subfolders inside the Suitcase. Logical organization is expressed by the flat filename grammar, open metadata, Store Map/Index, 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.

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:

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. LCK is reserved by Revision BC for the deferred explicit FINGERPRINT workflow governed under PB-OPS-010 and is not an ordinary WASM-002 output. 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.

If a current Data Sculptor version encounters a syntactically valid __DS__ artifact whose semantic class it does not understand, it must leave the artifact untouched and report the unknown/reserved class rather than delete, rewrite, or silently reinterpret it.

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.

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; governed RID recovery gives the replacement RID and recovery successor MAP one shared recovery-transaction UTC while surviving 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.

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.

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.

filesystem APIs differ.

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.

ABA, ... ZZZ. Ordinary lexical filename sorting therefore preserves the governed class order.

fixed-width token.

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.

Independent adversarial review must verify that every WASM-002-generated governed artifact uses one listed class with the frozen meaning, that WIP remains a lifecycle state rather than a class, and that unknown/unallocated classes are preserved and reported under PB-STOR-009 rather than silently interpreted.

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.

one frozen total length.

still have a frozen total length.

or shorten a Core physical filename.

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.

exists.

same relevant UTC/class context unless a later frozen rule requires a different deterministic response.

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.

The Store Index must provide a persistent HTML orientation layer over Store Map truth and related evidence. It may display friendly aliases and meaningful groupings while preserving exact links to physical identity.

For WASM-002, the governed MAP artifact is the single 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.

provenance.

identity where diagnostically useful.

dashboard.

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 publicly enough that an LLM collaborator can distinguish physical identity, logical meaning, integrity evidence, current state, and history without guessing.

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 Store-MAP versioning, Store-aware automatic MAP inheritance, complete-snapshot semantics, the exact nine-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 creation/replacement 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 ordinary 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, explicit governed RECOVER RID syntax and recovery semantics, recovery-aware Store-lineage continuity, shared publication-transaction UTC semantics for newly created RID/COL/MAP artifacts, the canonical automatic TXT Receipt contract including exact WKO lineage and RID-recovery facts, 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.

The Help-report provenance boundary is now 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. Persistent Work Order description storage, standalone alias creation/replacement, alias clearing/reset, explicit historical Store-MAP selection syntax, and HLP fingerprint provenance are no longer open storage items.

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. It is a deterministic line-oriented KEY: VALUE document with a frozen core-key order followed by operation-specific fact sections in deterministic order.

Enumerated values use the exact uppercase tokens frozen by the applicable requirement. Non-negative integers use ungrouped ASCII base-10 digits. Text values must be escaped or quoted by one deterministic receipt-text rule so embedded delimiter-like characters cannot make a Receipt ambiguous. The exact escaping rule may be implemented as a small shared serializer but must be acceptance-tested byte-for-byte.

Every canonical WASM-002 Receipt must contain, in frozen core order, at least:

• RECEIPT_VERSION;
• RECEIPT_FILENAME;
• WORK_ORDER_FILENAME — the exact physical immutable WKO identity invoked, including that WKO artifact's own governed timestamp and UUID;
• OPERATION — the governed top-level operation requested by that WKO;
• RUN_STARTED_UTC and RUN_FINISHED_UTC in canonical UTC millisecond form;
• RESULT — at minimum SUCCESS or REFUSED;
• DIAGNOSTIC_ID — canonical diagnostic identity for refusal, or an explicit none token for an ordinary successful run;
• IDENTITY_COLLISION_RETRIES — zero when no governed-filename collision retry occurred; and
• CREATED_ARTIFACT_COUNT followed by the exact governed physical filenames of artifacts successfully published by the run, excluding the Receipt itself.

The exact WORK_ORDER_FILENAME is the authoritative WKO→RCP lineage link. Receipt/WKO filename timestamps are not required to match and ordinarily represent different artifact-creation events. One immutable WKO may therefore be run multiple times, with each run publishing a distinct RCP carrying its own Receipt timestamp and run timestamps while pointing back to the same exact WORK_ORDER_FILENAME.

The Receipt must not claim an artifact was successfully published merely because a candidate filename was allocated or partial bytes were written.

For a WASM-002 MATERIALIZE run, the Receipt must additionally record the exact source filename, inherited Store MAP filename or explicit none for a newly established Store, exact RID filename, RID_ACTION as CREATED or REUSED, Stage 1 UTF-8 outcome, exact certified source-byte count when Stage 1 reached completion, Stage 1 elapsed time, Stage 2 accepted logical row count when available, Stage 2 elapsed time when Stage 2 ran, requested/resolved selected-column count, the exact physical COL filenames successfully published in resolved KEEP order, and the successor Store MAP filename when successfully published.

A refusal Receipt records only facts that actually became known before refusal. It must use explicit not-run/not-available tokens rather than fabricate later-stage counts, timings, or artifact identities.

The same canonical RCP mechanism applies to other executable WASM-002 Work Orders, including INVENTORY, governed source conversion, and RECOVER RID. Each operation adds its required deterministic fact section without changing the fixed core Receipt meaning.

For INVENTORY this includes the resulting INV artifact identity and captured entry count when successful. For source conversion this includes the governed source-encoding terminology, materialized UTF-8 encoding, bounded/streaming fact, and resulting converted-source identity when successful, preserving the existing conversion requirements. RID recovery adds the exact deterministic facts frozen in W002-RCP-011.

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.

For a RECOVER RID run, the canonical Receipt must additionally record, when known: the exact requested Store alias; exact recovery-base MAP filename; exact damaged/missing RID filename named by that MAP; the reason recovery was eligible; the deterministic recovered row count N; the exact current COL filenames whose validated common cardinality established N; RID_ACTION: RECOVERED on success; the exact replacement RID filename when successfully promoted; and the exact recovery successor MAP filename when successfully committed.

The Receipt must make clear that the replacement RID preserves logical values 1..N while using a new physical artifact identity. It must not claim successful RID recovery unless the successor MAP commit point completed. A refused recovery records only facts actually established before refusal and uses the canonical diagnostic ID for the refusal.

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.

A saved WKO that is actually Run and deterministically refuses before Stage 2 must still produce one canonical TXT Receipt when receipt publication is available. The Receipt must identify RESULT: REFUSED, the exact diagnostic ID, the stage facts actually reached, explicit not-run/not-available values for later facts, and zero successfully published analytical artifacts when that is the true fixture outcome.

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

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. A governed RID recovery under W002-RID-009/W002-RID-010 may replace a missing or invalid physical RID with a new immutable RID artifact while preserving the same logical row-identity sequence 1..N. Historical damaged/replaced RID artifacts may therefore remain visible as evidence even though exactly one RID is current in the successor MAP.

The stable logical row reference is conceptually (Store recovery 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.

During that first Store-establishing materialization, the canonical RID byte stream is written first as a visible governed SCR candidate while the requested materialized columns are likewise written as SCR candidates. 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 allocates the final RID identity using the materialization transaction UTC shared under PB-STOR-013/PB-STOR-014 plus a RID-specific UUID, and promotes the RID candidate first by host rename from its SCR filename to the final RID filename. The RID bytes must not change during 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 out of the RID namespace where safely possible or retained as attributable recovery evidence under the materialization failure contract.

If the first Work Order materializes one source column, the successfully committed Store publishes exactly one RID plus that requested COL and the other governed evidence required by the materialization contract. If the first Work Order materializes multiple source columns, the transaction still commits exactly one RID plus the requested COL artifacts.

Later ordinary materializations or other same-row-universe operations that preserve row cardinality and order must reuse the existing RID unchanged. They must not create a new RID candidate, regenerate, replace, renumber, or silently supersede the inherited RID. The sole WASM-002 exception is an explicit governed RECOVER RID Work Order satisfying W002-RID-009/W002-RID-010.

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 CSV with:

• exactly one UTF-8 BOM at byte zero;
• the literal first logical record RID;
• LF (0x0A) record terminators on every supported host;
• one data record for each Store row, in order, containing the unquoted unsigned base-10 integer row identity;
• the exact sequence 1, 2, ... N, with no zero, negative values, signs, thousands separators, locale formatting, decimal points, exponent notation, or leading zeroes; and
• a final LF after the Nth RID data record.

Because every RID value contains ASCII digits only, quoting is neither required nor permitted in the canonical RID artifact.

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. Conversely, when ordinary materialization extends an existing Store, the engine must recognize and reuse that Store's existing RID rather than interpreting the absence of RID syntax as a request to create another one.

Governed recovery is intentionally different: when an existing RID is missing or invalid, the analyst must explicitly authorize reconstruction with the canonical RECOVER RID FOR STORE "<StoreAlias>" Work Order form. Recovery never occurs silently as a side effect of MATERIALIZE.

The canonical RID-recovery operation is a governed exceptional repair of physical RID representation, not ordinary materialization and not creation of a new logical row universe. The analyst must target one Store through the canonical DS-STEPS syntax in W002-STEPS-010.

Recovery may proceed only when Data Sculptor can deterministically identify one recovery-base MAP for the requested Store and establish that the defect requiring recovery is the MAP-bound RID: the referenced RID is missing, unreadable, or fails canonical RID validation. The recovery-base MAP itself must remain structurally valid apart from that RID-binding failure, and every COL artifact bound by that MAP must be present, readable, canonically valid, and agree on exactly one data-row count N in the existing governed row order.

The common COL cardinality N is the deterministic recovery evidence for reconstructing canonical RID values 1..N. If no unique target Store/recovery-base MAP can be resolved, if no trustworthy N can be established, if current bound COL artifacts disagree on N, or if any additional Store-state corruption prevents proving the existing row axis, Data Sculptor must refuse. It must never guess N, infer missing rows, reorder data, or use RID recovery to repair unrelated COL/MAP damage.

A successful RECOVER RID run must never overwrite, rename in place, or silently repair the damaged RID artifact. Data Sculptor writes canonical 1..N RID bytes under a governed SCR candidate, closes/reopens/validates the candidate completely, then promotes it by host rename to a new immutable RID identity.

The replacement RID and the recovery successor MAP use the same new canonical recovery-transaction UTC timestamp under PB-STOR-013/PB-STOR-014 and distinct UUIDs. Existing valid COL artifacts referenced by the recovery-base MAP retain their original filenames, timestamps, UUIDs, bytes, source metadata, and aliases.

After RID promotion, Data Sculptor constructs a complete successor MAP as SCR that preserves the recovery-base Store alias, Store source filename, RID alias, complete COL mapping set, and COL physical identities while replacing only the Store's bound rid_filename with the newly recovered RID. The MAP candidate must close, reopen, and pass full recovery-aware MAP validation; only then may it be renamed into its final MAP identity. That SCR-to-MAP rename is the recovery commit point.

If recovery fails before MAP commit, the prior published MAP remains historical evidence of the degraded Store state and no replacement RID becomes current merely by existing under an RID filename. Newly created recovery artifacts must be rolled back where safely possible or retained visibly as attributable SCR/RCV evidence.

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

RID
1
2
3
4
5

with LF terminators only and a final LF. The same fixture repeated under different permitted source-window boundaries must produce byte-identical RID content apart from the governed physical filename allocated to the artifact.

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 complete-set validation, the RID bytes must exist only as a 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 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.

An acceptance fixture must establish a Store, retain at least two valid current COL artifacts, then make the current MAP-bound RID missing or canonically invalid while leaving the recovery-base MAP and bound COLs otherwise valid. Running a saved Work Order containing RECOVER RID FOR STORE "<alias>" must prove that Data Sculptor derives one common N from all current bound COLs, reconstructs exact canonical RID bytes 1..N under SCR, promotes a new RID without overwriting the damaged RID, and publishes exactly one successor MAP last.

The replacement RID and successor MAP must carry the same new canonical recovery-transaction UTC token and distinct UUIDs. Existing valid COL filenames, timestamps, UUIDs, bytes, source metadata, and aliases must remain unchanged. The successor MAP must bind the replacement RID and the existing COL set; the previous MAP remains immutable historical evidence.

Additional fixtures must prove refusal when Store alias resolution is missing/ambiguous, when current bound COLs disagree on N, when any required current COL is missing/invalid, and when the RID is healthy so recovery is not warranted. A promotion/MAP-publication failure fixture must prove that no replacement RID becomes current without successful successor-MAP commit.

The canonical WASM-002 form is:

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.

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.

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.

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 in the directory denoted by SUITCASE: .. Data Sculptor does not recursively inventory user-created subdirectories in this build. If a directory entry is encountered, the inventory may identify that a directory is present, but it must not imply that nested contents were inspected or included.

This rule preserves the WASM-002 flat-Suitcase storage model while avoiding hidden recursive filesystem traversal.

The INV artifact must be a human-readable Red5Sorcery Data Sculptor TXT document encoded as UTF-8 with LF line endings. It must identify the inventory format version, capture UTC, generating WKO physical identity, Suitcase declaration, entry count, and the per-file metadata fields governed by W002-INV-003.

File entries must be serialized in deterministic ascending exact-filename UTF-8 byte order. The filename representation must be unambiguous even when a filename contains whitespace or delimiter-like characters. Equivalent Suitcase metadata under the same serialization rules must therefore produce equivalent ordered inventory content apart from governed run/artifact identity and capture timestamp fields.

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.

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 optional immutable Work Order content, not separately editable browser metadata. The canonical declaration is WORK ORDER AS "<alias>" under W002-STEPS-001.1. If present, 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 future 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 nine-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 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 two-field header:

wko_alias,wko_filename

Each row identifies one current visible saved WKO. wko_filename is the exact governed physical WKO filename. wko_alias is the exact alias declared by that WKO's optional WORK ORDER AS clause, or the empty string when no alias is declared.

Rows are written deterministically by ascending UTF-8 byte order of wko_filename. Duplicate wko_filename rows are invalid. Standard governed CSV quoting applies. A non-empty wko_alias must be unique within the current WKO MAP; Data Sculptor must refuse a new save that would make two current WKO rows share the same non-empty alias rather than silently disambiguating or suffixing the alias.

Saving a new immutable WKO begins from the newest valid WKO MAP in the Suitcase, or an empty WKO registry if none exists. Data Sculptor validates the draft, including its optional Work Order alias and comment syntax, and checks non-empty alias uniqueness before commit.

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 against the exact WKO-MAP schema and referenced visible WKO files. 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 validation or publication 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 attributable SCR/RCV recovery evidence and report the failure through Help.

Among valid WKO MAP artifacts, the one with the greatest canonical UTC millisecond timestamp is the current WKO alias registry. If two or more valid WKO MAPs share the greatest timestamp, current-registry selection must refuse rather than break the tie by UUID, discovery order, filesystem modified time, or directory order.

The browser may use the current WKO MAP to show human-facing Work Order aliases 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. Revision BB does not pull the deferred Work Order invocation/orchestration grammar into WASM-002; it establishes the governed alias registry that later composition can depend on.

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.

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 store_source_filename in valid Store MAPs.

• If no eligible Store lineage exists for that exact source filename, the materialization establishes a new Store with a new RID and first Store MAP.
• If exactly one eligible Store lineage exists, Data Sculptor uses that Store's valid MAP with the greatest canonical UTC millisecond timestamp as the inheritance base.
• If more than one distinct Store lineage is eligible for the same exact source filename, automatic inheritance must refuse rather than guess which Store the analyst intended. The analyst must explicitly select one valid MAP.

Store lineages are distinguished by their exact immutable rid_filename. If two or more valid MAPs for the one selected 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.

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.

A governed Store-aware Work Order may explicitly identify any one 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-alias MAP profile, missing file, malformed MAP, or other MAP profile is invalid for this clause. Data Sculptor must use exactly the named Store MAP rather than silently substituting a later one.

For materialization, SOURCE "..." remains required to identify the source file being read; an optional MAP "..." clause overrides automatic Store-MAP inheritance and supplies the exact Store-state base. The named Store MAP must be compatible with the materialization source under the existing source/Store rules or validation must refuse. For an alias-only UPDATE ALIASES Work Order, MAP "..." may itself be the Store-state selector and no source-data read is required.

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.

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, performs governed RID recovery, and/or later 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. RID recovery uses the recovery-base MAP resolved under W002-RID-009.

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/recovery-base 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 SCR/RCV evidence rather than Store state.

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

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

Each data row describes one current logical materialized-column mapping while repeating the same Store-level metadata in the first four fields:

• store_alias — current human-facing Store name;
• store_source_filename — exact visible Suitcase filename whose logical data-record order established the Store RID universe;
• rid_filename — exact immutable governed RID artifact filename that physically anchors this Store;
• rid_alias — current human-facing RID name;
• source_filename — exact visible source filename from which this mapped COL was materialized;
• 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.

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 the mutable store_alias.

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 exact source_header. If that default would be empty or would violate governed alias-uniqueness/shadowing rules, Data Sculptor must not invent a suffix or alternate name. The Work Order must supply an explicit valid alias for that column before a valid successor MAP can be published.

If the same Work Order supplies an explicit alias for a newly materialized column, the explicit governed alias overrides the default header alias.

For a previously materialized COL, RESET COL "<reference>" ALIAS restores this same deterministic default: the exact recorded source_header. If that header is empty or the restored value would violate alias uniqueness/shadowing rules in the successor Store MAP, RESET must refuse rather than invent 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 store_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. The only WASM-002 operation permitted to replace rid_filename while preserving the same logical row universe is explicit governed RID recovery under W002-RID-009/W002-RID-010.

Store MAP CSV files are encoded as UTF-8 without BOM and use LF (0x0A) record termination. The exact nine-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, store_source_filename, rid_filename, and rid_alias. Mapping rows are written deterministically by ascending UTF-8 byte order of source_filename, then ascending numeric source_column_number, then ascending UTF-8 byte order of source_header. Two rows with the same logical source-column key are invalid.

A canonical MAP filename alone does not make a file an eligible Store MAP. To participate in automatic or explicit inheritance, the artifact must be readable as complete UTF-8, have the exact nine-column schema, parse deterministically, satisfy Store-level consistency and mapping-key/alias constraints, reference one valid visible governed RID filename, and reference valid visible governed COL filenames for its mapped rows.

For successor publication, Data Sculptor constructs the complete deterministic MAP CSV under a governed SCR candidate identity after the required RID/COL physical promotions have succeeded. 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 allocate the final timestamp+UUID MAP identity and promote the candidate by host rename into the canonical __DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv namespace. 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 attributable SCR/RCV 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.

For WASM-002, Data Sculptor does not allocate a second permanent Store UUID in addition to governed RID/MAP evidence. Under ordinary operation, 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 ordinary successor MAPs repeat it exactly.

Governed RID recovery is the sole exception. When W002-RID-009/W002-RID-010 proves that the current physical RID is missing or invalid but the same logical row axis 1..N is recoverable, the recovery successor MAP may bind a new RID filename while preserving the Store's logical continuity, aliases, source identity, existing COL mappings, and row order. The recovery Receipt records the old-to-new RID transition. This replacement does not assert that a different row universe was created.

Within any one MAP, every row must repeat the same exact current rid_filename; disagreement is invalid. Outside an explicit proven recovery transition, a different RID filename denotes a different Store row universe and must not be silently treated as same-Store continuation.

When the first successful materialization establishes a Store, its first Store MAP must initialize store_alias to the exact store_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 store_source_filename, rid_filename, RID bytes, COL bytes, or prior MAP history.

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 and must not silently shadow another visible physical filename or alias under the applicable filename-comparison rules.

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.

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.

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.

Successful create/write/close of this canonical governed HTML filename is the WASM-002 supported-host folder filename/path compatibility test. 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, the selected directory does not pass validation.

The brandable HTML certificate 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.

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

span adjacent input windows.

source is valid UTF-8.

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.

source-file size.

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

resolved before the remaining bytes are treated as independent input.

ASCII and certified directly because ASCII is a complete subset of UTF-8.

bytes to a second general UTF-8 decoder pass.

resume the ASCII-fast scan after the valid sequence.

offsets for later validation.

sequence. 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.

required by the frozen error contract. The certifier need not read the remainder of an already-invalid source.

rules and no incomplete sequence remains pending.

validated, but the remaining source must still undergo complete certification.

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

different bounded window sizes must not change PASS/FAIL or the first invalid absolute byte offset.

read, windows/pushes processed, non-ASCII sequences encountered when counted, final pending state, and stop reason without requiring those counters to alter certification semantics.

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.

0x80 through 0xBF.

through 0xBF, preventing overlong encodings.

bytes 0x80 through 0xBF.

through 0xBF, excluding UTF-16 surrogate halves.

continuation bytes 0x80 through 0xBF, preventing overlong encodings.

0xBF.

continuation bytes 0x80 through 0xBF, preventing code points above U+10FFFF.

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. This supported removing per-run general-validator call overhead rather than merely shrinking 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.

analytical semantics.

change, not an optimization.

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.

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.

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.

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.

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.

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. 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.

For a new Store, Data Sculptor establishes one publication-transaction UTC under PB-STOR-013/PB-STOR-014, allocates the final RID identity using that UTC plus a RID-specific UUID, and promotes the validated RID candidate first by host rename from its SCR filename to a valid governed RID filename. For an existing Store, the inherited RID is reused unchanged and no RID candidate/promotion occurs. After the required RID state is established, Data Sculptor promotes each requested COL candidate by host rename from SCR to a valid governed COL filename using that same transaction UTC plus a distinct COL-specific UUID, in deterministic resolved KEEP order.

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 attributable SCR/RCV recovery 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 constructs the complete successor MAP under a governed SCR candidate identity using the exact final RID/COL filenames, closes it successfully, reopens it, and validates it completely while it remains SCR. Only then may the MAP candidate be renamed into its final governed MAP identity using the same transaction UTC plus its own MAP UUID. 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.

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 or retained as attributable recovery evidence. 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.

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.

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.

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.

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 must be implemented as a distinct Work Order operation, separate from UTF-8 certification and separate from analytical materialization.

After strict UTF-8 certification fails, Data Sculptor may assess whether the source bytes are compatible with the specific Windows-1252 conversion rules supported by the product.

the frozen Windows-1252 rules.

original encoding.

conversion task to refuse rather than guess.

and 0x9D.

When UTF-8 certification fails and the bytes are compatible with Data Sculptor's supported Windows-1252 conversion rules, the Help Engine may suggest the separate conversion Work Order.

definitively identified as Windows-1252.

conversion as though it were safe.

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.

The canonical RCP for a successful governed Windows-1252-compatible conversion must identify SOURCE_ENCODING=WINDOWS-1252-COMPATIBLE or the exact equivalent terminology frozen by the conversion contract. That operation-specific fact is carried within the canonical TXT Receipt governed by W002-RCP-001 through W002-RCP-010.

The canonical RCP for successful conversion must identify MATERIALIZED_ENCODING=UTF-8.

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.

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.

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 may be absent when it is not available or not applicable. An emitted fact key that is not declared for that diagnostic is invalid.

Absence is semantically distinct from a value: a missing fact must never be silently interpreted as false, zero, an empty string, or another default. This rule includes the canonical Boolean boundary facts governed by W002-HELP-004.11.

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.

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.

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-ENC-001",
      "severity": "ERROR",
      "phase": "SOURCE_CERTIFICATION",
      "behavior": "REFUSE",
      "next_action": "CONVERT_SOURCE_TO_UTF8",
      "required_facts": ["byte_offset", "source_filename"],
      "optional_facts": ["analytical_outputs_published", "materialization_started", "source_modified_by_data_sculptor", "store_state_committed"]
    }
  ]
}

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.

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.

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 that 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 voices must not be maintained as unrelated message stores.