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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

__DS__CCC__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.<extension>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ordinary lexical filename sorting therefore preserves the governed class order.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The physical Receipt filename is:

__DS__RCP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For one Run, the truthful temporal invariant is:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For a WASM-002 MATERIALIZE run, after the common envelope the Receipt serializes these operation-specific keys in exactly this order:

1. SOURCE_FILENAME
2. BASE_MAP_FILENAME
3. RID_FILENAME
4. RID_ACTION
5. STAGE1_UTF8_OUTCOME
6. CERTIFIED_SOURCE_BYTE_COUNT
7. STAGE1_ELAPSED_MS
8. UTF8_FIRST_INVALID_BYTE_OFFSET
9. UTF8_STOP_REASON
10. WINDOWS_1252_COMPATIBILITY_OUTCOME
11. WINDOWS_1252_FIRST_UNDEFINED_BYTE_OFFSET
12. STAGE2_LOGICAL_ROW_COUNT
13. STAGE2_ELAPSED_MS
14. CSV_REFUSAL_CONDITION
15. CSV_SOURCE_BYTE_OFFSET
16. CSV_PHYSICAL_LINE
17. CSV_LOGICAL_RECORD
18. CSV_FIELD_ORDINAL
19. REQUESTED_COLUMN_COUNT
20. RESOLVED_COLUMN_COUNT
21. PUBLISHED_COL_COUNT
22. zero or more indexed published-COL filename lines whose exact key form is PUBLISHED_COL_<INDEX>_FILENAME (for example PUBLISHED_COL_001_FILENAME, PUBLISHED_COL_002_FILENAME)
23. SUCCESSOR_MAP_FILENAME
24. OPERATIONAL_NAME_FALLBACK_COUNT
25. zero or more indexed fallback triplets: OPERATIONAL_NAME_FALLBACK_001_COLUMN_ORDINAL, OPERATIONAL_NAME_FALLBACK_001_ASSIGNED_NAME, OPERATIONAL_NAME_FALLBACK_001_REASON, continuing under the common indexed-key rule.

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

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

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

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

RID_FILENAME is a separate fact:

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

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

The refusal-boundary matrix is therefore:

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

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

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

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

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

The MATERIALIZE refusal-stage matrix is:

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

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

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

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

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

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

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

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

INVENTORY

1. INVENTORY_FILENAME
2. INVENTORY_ENTRY_COUNT

UPDATE_ALIASES

1. BASE_MAP_FILENAME
2. SUCCESSOR_MAP_FILENAME

REPAIR_MAP

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

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

REPAIR_WORK_ORDER_REGISTRY

1. BASE_WKO_MAP_FILENAME
2. REMOVED_STALE_ROW_COUNT
3. zero or more indexed stale-WKO filename lines using exact key form REMOVED_STALE_WKO_<INDEX>_FILENAME (for example REMOVED_STALE_WKO_001_FILENAME, REMOVED_STALE_WKO_002_FILENAME)
4. REGISTERED_CURRENT_COUNT
5. zero or more indexed current-WKO filename lines using exact key form REGISTERED_CURRENT_WKO_<INDEX>_FILENAME (for example REGISTERED_CURRENT_WKO_001_FILENAME, REGISTERED_CURRENT_WKO_002_FILENAME)
6. REGISTERED_DEPRECATED_COUNT
7. zero or more indexed deprecated-WKO filename lines using exact key form REGISTERED_DEPRECATED_WKO_<INDEX>_FILENAME (for example REGISTERED_DEPRECATED_WKO_001_FILENAME, REGISTERED_DEPRECATED_WKO_002_FILENAME)
8. SUCCESSOR_WKO_MAP_FILENAME

Each filename list is independently sorted by ascending exact UTF-8 filename bytes. If the bootstrap repair WKO is newly discovered and registered, it appears in the appropriate registered list under W002-STOR-018.3 and W002-STOR-018.4.

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

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

CONVERT_WINDOWS_1252_TO_UTF_8

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

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

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

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

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

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

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

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

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

CATALOG_STORES

1. CATALOG_ENTRY_COUNT
2. CATALOG_FILENAME

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Day 060 H-09 success-timeline acceptance

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

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

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

Day 060 H-11 successful RID_ACTION acceptance

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

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

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

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

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

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

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

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

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

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

Day 060 H-09 refusal-timeline acceptance

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The physical RID filename must be:

__DS__RID__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv

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

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

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

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

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

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

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

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

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

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

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

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

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

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

N=5
1
2
3
4
5

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

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

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

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

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

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

The canonical WASM-002 form is:

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

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

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

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

__DS__INV__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.txt

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

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

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

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

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

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

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

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

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

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

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

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

The exact V1 Inventory serialization order is:

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

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

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

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

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

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

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

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

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

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

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

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

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

Day 060 H-09 reachable-Suitcase INV golden fixture

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

wko_status,wko_alias,wko_filename

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

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

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

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

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

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

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

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

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

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

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

When the current WKO registry is repair-required under W002-STOR-018.4, Data Sculptor may save one ordinary visible immutable WKO whose sole semantic operation is exactly REPAIR WORK ORDER REGISTRY. That saved repair-only WKO may Run by its exact physical WKO filename even though it is not yet represented in the current WKO MAP.

• The WKO must be structurally valid under the predicate below, must contain exactly one mandatory non-empty WORK ORDER AS, and must contain exactly the governed registry-repair operation and no second operation.
• The exception does not grant alias-based Run authority. The repair WKO is invoked only by exact physical WKO filename.
• No other visible but unregistered WKO gains Run eligibility from this exception.
• The exception ends once registry repair successfully publishes the successor WKO MAP.
• This is the sole WASM-002 bypass of ordinary current-registry membership for Run eligibility.

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

F-02 governed WKO structural-validity predicate

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

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

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

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

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

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

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

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

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

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

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

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

F-02 deterministic registry reconciliation

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

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

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

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

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

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

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

F-02 Run eligibility and alias authority

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

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

F-08 REPAIR WORK ORDER REGISTRY Work Order structure:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

F-03 canonical evaluated Store-health states

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

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

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

F-03 status is evaluated, not persisted

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

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

F-03 strict DEGRADED operation gate

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

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

F-03 no damaged-lineage fork

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

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

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

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

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

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

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

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

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

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

MAP "__DS__MAP__YYYYMMDDTHHMMSSmmmZ__<uuid-v4>.csv"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A Store MAP remains part of governed Store history when its own bytes, schema, lineage facts, and deterministic structural rules are valid even if a referenced RID or COL later becomes missing or invalid. Referenced-artifact damage therefore does not make the current structurally valid Store MAP disappear and does not by itself cause fallback to an older MAP.

F-03 current Store MAP selection

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

• A structurally malformed newer MAP is never current.
• If a newer canonical MAP artifact is structurally malformed, Data Sculptor uses the greatest earlier structurally valid Store MAP in that same lineage, if one exists, and reports the malformed newer artifact through governed Help/evidence surfaces.
• This fallback applies to structural MAP invalidity only. It does not apply merely because a structurally valid current MAP references a damaged RID or COL.
• If two or more structurally valid MAPs share the greatest canonical UTC millisecond timestamp, current authority is ambiguous and selection refuses rather than breaking the tie by UUID, discovery order, directory order, or filesystem modified time.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The canonical CAT header row is exactly:

store_alias,source_filename,rid_filename,map_filename,store_health

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

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

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

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

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

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

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

The canonical WASM-002 Work Order form is:

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

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

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

The canonical Receipt operation token is CATALOG_STORES.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The canonical candidate filename for a staged governed artifact is:

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

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

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

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

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