WASM-002 Claude QA Reconciliation Log

• VALID — the current governed MAP is valid, the RID is valid, and every non-RID COL binding in that MAP resolves to a valid governed artifact.
• DEGRADED — the current governed MAP is valid and the RID is valid, but one or more mapped non-RID COL artifacts are missing or invalid.
• INVALID — the Store's governing state cannot be trusted, including a missing or invalid RID or an untrustworthy current MAP.

There is no fourth ABANDONED Store status.

If the RID is missing or invalid, the Store is INVALID, not DEGRADED.

An INVALID Store is terminal and non-recoverable for analytical use. Data Sculptor must not regenerate the RID, repair the Store, inherit from it, materialize into it, mutate aliases against it, or perform any other Store operation.

Read-only Help, status, Inventory, and historical/evidence inspection may explain the condition; they are not Store operations.

A DEGRADED Store still has trustworthy Store identity because both its current MAP and RID remain valid. Its only defect is that one or more non-RID COL artifacts named by the current MAP are missing or invalid.

The meaning or origin of a COL does not affect this status rule. A COL may be source-derived, calculated, a future 1/0 selection/filter column, or another future same-row column type. Store health does not need to know how the COL was built.

When a Store is DEGRADED, no Store operation is enabled except the single recovery operation REPAIR MAP.

Materialization, extension with new columns, transformations, alias mutation, other recovery operations, and ordinary analytical execution against that Store are refused until the Store returns to VALID.

Read-only Help, Inventory, and status inspection remain available to explain the condition; they are not Store operations.

REPAIR MAP is the sole governed recovery path for a DEGRADED Store.

• The user does not name a MAP filename, Store alias, or individual columns.
• Data Sculptor resolves the Store's current/latest governed MAP under the normal current-state rule.
• Data Sculptor confirms that the Store is DEGRADED and that both the MAP and RID are valid.
• Data Sculptor determines which mapped non-RID COL artifacts are actually missing or invalid.
• Data Sculptor publishes a successor MAP with exactly those broken COL bindings removed.
• REPAIR MAP must never remove a valid mapped COL.
• The existing MAP is never edited in place.
• No source data is read.
• No missing COL is rebuilt or rematerialized as part of repair.
• No RID is regenerated.
• If the successor MAP validates and every remaining mapped artifact is valid, the Store returns to VALID.
• If repair cannot complete successfully, the Store remains DEGRADED.
• INVALID Stores cannot execute REPAIR MAP.

The revised model prevents a missing COL from making the Store silently disappear from routing and prevents a missing RID from triggering a quiet new Store lineage. Damage becomes an explicit Store status, and recovery requires explicit human authority through a saved Work Order.

The recovery rule also avoids committing WASM-002 to future column semantics. Data Sculptor does not need to know how a missing calculated, selection, source-derived, or future column was originally produced in order to restore the Store's MAP to truthful agreement with the governed artifacts that still exist.

What happened

Data Sculptor found that the Store's current governed MAP and RID are valid, but one or more non-RID COL artifacts referenced by the MAP are missing or invalid.

The Store remains identifiable and its row identity remains trustworthy, but its current MAP no longer matches the complete set of valid governed files in the Suitcase.

What Data Sculptor did

Data Sculptor changed the Store status to DEGRADED.

While a Store is DEGRADED, all Store operations are disabled except:

REPAIR MAP

Read-only Help, Inventory, and status inspection remain available.

How to fix it

Run a saved Work Order containing:

REPAIR MAP

Data Sculptor will:

1. Resolve the Store's current governed MAP.
2. Confirm that the MAP and RID are valid.
3. Identify every mapped non-RID COL artifact that is missing or invalid.
4. Create a successor MAP that removes exactly those broken COL bindings.
5. Preserve every valid mapped COL binding.
6. Validate the successor MAP and all remaining governed Store artifacts.
7. Return the Store to VALID if validation succeeds.

What REPAIR MAP will not do

• Rebuild or rematerialize a missing column.
• Read the original source data.
• Regenerate the RID.
• Remove a valid mapped column.
• Modify the existing MAP in place.
• Infer why a file is missing or invalid.

Historical MAPs remain unchanged.

If repair fails

The Store remains DEGRADED. No other Store operation becomes available.

What happened

Data Sculptor cannot trust the Store's governing state.

A Store is INVALID when its current governed MAP cannot be trusted, or when its RID is missing or invalid.

Because the RID defines the Store's row-identity spine, Data Sculptor cannot safely reconstruct, substitute, or infer it.

What Data Sculptor did

Data Sculptor changed the Store status to INVALID and disabled all Store operations.

Read-only Help, Inventory, status, and historical evidence may still be inspected.

How to continue

This Store cannot be repaired.

To continue analytical work, establish a new Store from an appropriate source through a new governed Work Order.

REPAIR MAP is not available for an INVALID Store.

Why Data Sculptor refuses

Continuing with an untrustworthy MAP or RID could falsely associate columns with rows or create a new analytical lineage while presenting it as the old one.

Data Sculptor refuses rather than guess.

Result

The DEGRADED Store was successfully repaired.

Data Sculptor published a successor MAP that removed the bindings for mapped non-RID COL artifacts that were missing or invalid. Valid COL bindings and the existing RID were preserved.

The previous MAP remains unchanged as historical evidence.

Store status

VALID

Normal Store operations are now available.

When a materialization targets an existing VALID Store, the candidate materialization must produce exactly the Store's expected row count N before any new Store publication may commit.

• The authoritative expected N for this gate is read from the existing Store RID header.
• The candidate materialization's accepted logical data-row count is compared with that expected N.
• If candidate N equals RID-header N, this cardinality gate passes.
• If the counts differ, the Run refuses before any candidate COL or successor Store MAP is promoted.
• A cardinality mismatch does not damage the existing Store. The existing Store remains VALID.
• The refused Run continues to follow the normal governed diagnostic, Help, Receipt, and evidence rules.

This gate proves cardinality compatibility only. Equal row counts do not, by themselves, prove byte identity or semantic row identity. Broader source-to-Store compatibility remains separately governed by F-05.

The RID is a one-column UTF-8 CSV. Its header is structural metadata and is exactly:

N=<value>

<value> is the canonical decimal representation of the Store's total logical data-row count N.

• The header uses uppercase N, exactly one equals sign, and no spaces or thousands separators.
• The header is not a RID data value and does not consume a logical Store row.
• After the header, the RID contains exactly N data records.
• Those data records are the consecutive decimal integers 1 through N, one RID value per logical Store row.
• RID row 1 therefore remains physically aligned with COL data row 1; RID row N remains aligned with COL data row N.
• The governed RID artifact class/filename and MAP binding identify the artifact as a RID; the literal word RID is not required in the CSV header.

Example for a five-row Store:

N=5
1
2
3
4
5

A valid RID must be internally consistent with its own header: the header declares N, the file contains exactly N logical data records after that header, and those records are exactly the sequence 1..N.

For the F-04 comparison, Data Sculptor therefore does not need to scan the existing RID merely to rediscover its expected cardinality. It reads N from the already-valid RID header.

No new Store-level MAP field is introduced solely for this F-04 check. Existing MAP row-count/provenance fields are not removed or otherwise changed by this decision.

What happened

Data Sculptor attempted to materialize into an existing Store, but the candidate source produced a different number of logical data rows than the Store RID declares.

Expected Store rows: {expected_N}
Candidate rows: {candidate_N}

What Data Sculptor did

The Run was refused before any candidate COL or successor Store MAP was published. The existing Store remains VALID and unchanged.

Why Data Sculptor refuses

Columns with a different row count cannot be safely attached to the Store's existing RID row spine.

This refusal establishes only that the row counts differ. Data Sculptor does not infer who changed the source or why.

What to do next

If this source was meant to extend the existing Store, restore or select the source whose row universe matches the Store RID. If this source intentionally represents a new row universe, preserve it under a distinct filename and reference that filename in a new Work Order so Data Sculptor can establish a new Store and RID.

The analyst-controlled source filename is the explicit Store-routing boundary for WASM-002.

• If a Work Order names the same SOURCE filename as an existing Store source, Data Sculptor treats the Run as a candidate extension of that Store and applies the existing-Store cardinality gate.
• If the analyst knows that a refreshed, revised, reordered, or otherwise distinct source represents a new row universe, the analyst makes or preserves a separate CSV copy under a distinct filename and references that distinct filename in the new Work Order.
• A distinct source filename that does not resolve to an existing Store lineage establishes a new Store and a new RID under the normal Store-creation rules.
• Data Sculptor does not silently copy, rename, overwrite, or reinterpret the analyst-owned source to create this distinction.
• No NEW STORE, MATERIALIZE NEW STORE, or equivalent syntax is added to WASM-002 for this case.

This is a visible, analyst-controlled workflow rather than a hidden filename trick: the distinct analyst-owned source filename is the explicit evidence of intent to establish a separate row universe.

If the source is intentionally a different row universe

Keep or create a separate copy of the CSV under a distinct filename, update the Work Order SOURCE to that filename, save the Work Order, and Run it as a new source.

Because the new source filename is not bound to the existing Store lineage, Data Sculptor will establish a new Store and generate a new RID for that row universe.

Do not rename or overwrite the existing Store's source merely to force continuation. Preserve the distinct source files visibly in the Suitcase.

For WASM-002, one Store MAP may describe multiple Stores. Each Store lineage is distinguished by its governed rid_filename. Within one Store lineage, one physical analyst-owned source filename establishes the row universe and one or more materialized COL artifacts may be derived from that same source.

• Each mapped materialized COL row contains exactly one source_filename, identifying the physical source file from which that COL was materialized.
• Rows with the same rid_filename belong to the same Store lineage and must all carry the same source_filename.
• Rows with different rid_filename values represent different Store lineages and may legitimately carry different source_filename values.
• A Store lineage whose rows contain more than one source_filename value violates the WASM-002 single-source Store invariant.
• The separate store_source_filename field is removed from the WASM-002 Store MAP profile because the Store's source identity is already represented by the common source_filename across that RID lineage.
• The RID remains the Store's permanent row-identity spine.

This keeps the model narrow without limiting the MAP to one Store: one MAP may describe many Stores, while each individual Store remains single-source.

Valid example — two Stores in one MAP, each internally single-source

Assume Store A was established first at publication UTC 20260924T191500000Z. Store B was established later at publication UTC 20260924T191600000Z. The later successor MAP is therefore:

__DS__MAP__20260924T191600000Z__7e8f9a0b-5555-4000-8000-000000000005.csv

An illustrative subset of that MAP's rows is:

source_filename,store_alias,rid_filename,rid_alias,col_filename,col_alias
CrimeData.csv,Crime Data,__DS__RID__20260924T191500000Z__a1b2c3d4-1111-4000-8000-000000000001.csv,Crime Rows,__DS__COL__20260924T191500000Z__e5f6a7b8-2222-4000-8000-000000000002.csv,Region
CrimeData.csv,Crime Data,__DS__RID__20260924T191500000Z__a1b2c3d4-1111-4000-8000-000000000001.csv,Crime Rows,__DS__COL__20260924T191500000Z__c9d0e1f2-3333-4000-8000-000000000003.csv,Value
Population.csv,Population,__DS__RID__20260924T191600000Z__4a5b6c7d-4444-4000-8000-000000000004.csv,Population Rows,__DS__COL__20260924T191600000Z__8e9f0a1b-6666-4000-8000-000000000006.csv,Age
Population.csv,Population,__DS__RID__20260924T191600000Z__4a5b6c7d-4444-4000-8000-000000000004.csv,Population Rows,__DS__COL__20260924T191600000Z__2c3d4e5f-7777-4000-8000-000000000007.csv,Population Count

This is valid under the F-05 rule. The two rows sharing the CrimeData.csv source also share one exact RID physical filename and therefore form one Store lineage. The two Population.csv rows share a different exact RID physical filename and form a second Store lineage. Each governed file keeps its opaque physical identity while the MAP carries the analyst-facing aliases that explain what those files mean.

The example also illustrates publication identity correctly: Store A's RID and COLs share Store A's creation UTC but have distinct UUIDs. Store B's newly published RID, COLs, and the successor MAP share Store B's later publication UTC, again with distinct UUIDs. Historical Store A artifacts retain their earlier physical identities when copied forward into the successor MAP snapshot.

Invalid example — one Store lineage contains mixed source filenames

source_filename,store_alias,rid_filename,rid_alias,col_filename,col_alias
CrimeData.csv,Crime Data,__DS__RID__20260924T191500000Z__a1b2c3d4-1111-4000-8000-000000000001.csv,Crime Rows,__DS__COL__20260924T191500000Z__e5f6a7b8-2222-4000-8000-000000000002.csv,Region
OtherData.csv,Crime Data,__DS__RID__20260924T191500000Z__a1b2c3d4-1111-4000-8000-000000000001.csv,Crime Rows,__DS__COL__20260924T191700000Z__9a0b1c2d-8888-4000-8000-000000000008.csv,Age
Population.csv,Population,__DS__RID__20260924T191600000Z__4a5b6c7d-4444-4000-8000-000000000004.csv,Population Rows,__DS__COL__20260924T191600000Z__8e9f0a1b-6666-4000-8000-000000000006.csv,Age

The Population Store lineage is internally consistent. The Crime Data lineage is invalid for WASM-002 because two rows claim the same exact RID lineage while naming different physical source files: CrimeData.csv and OtherData.csv. The aliases do not cure that conflict, and equal row counts would not cure it either. A human-friendly alias is orientation metadata; it never overrides the physical Store-lineage identity or authorizes a cross-source positional attachment.

When a Work Order explicitly names a Store MAP for materialization, Data Sculptor must validate compatibility against the Store lineage being continued before materialization begins.

• The target Store lineage is identified by its governed rid_filename under the Store-selection rules.
• The Work Order SOURCE filename must exactly equal the common source_filename carried by the materialized COL rows in that target RID lineage.
• Different Store lineages elsewhere in the same MAP may carry other source filenames; they do not make the MAP incompatible.
• If rows belonging to the target RID lineage contain inconsistent source_filename values, that lineage violates the Store invariant and cannot be used as a materialization base.
• If Work Order SOURCE does not exactly equal the target Store lineage's source filename, the Run refuses before materialization and before any new Store artifact is published.
• An explicit MAP means use this governed state of this Store lineage. It does not mean attach this source to a different Store lineage.
• Matching source identity does not bypass F-04. Existing-Store materialization must still satisfy the frozen RID-header cardinality gate: candidate logical row count N must equal the existing valid RID header N before publication may commit.

WASM-002 must never use an explicit MAP as permission to attach a different source file to an existing Store lineage by physical row position, even when the two files happen to have the same row count.

Equal cardinality is not evidence of row identity. A different source filename therefore refuses against that Store lineage rather than being treated as a positional join, silent append, or alternate source for the Store.

The Revision BL Store MAP profile must be revised during later PRD integration so that WASM-002 no longer stores both store_source_filename and per-row source_filename.

The WASM-002 direction is to retain one per-materialized-COL source_filename field and remove the redundant store_source_filename field. Store source identity is derived per RID lineage: all rows sharing one rid_filename must agree on source_filename. The MAP continues to pair opaque governed physical filenames with human-facing Store/RID/COL aliases and other frozen provenance fields; removing store_source_filename does not weaken that physical-to-logical mapping role.

The exact final column order and full revised Store MAP schema remain an integration task for the PRD revision; this reconciliation decision freezes the semantics, not a new full serialized row example.

• Multiple Stores in one MAP: two or more RID lineages with different source filenames are valid when each lineage is internally single-source.
• Compatible explicit MAP: Work Order SOURCE exactly matches the common source_filename of the target RID lineage; the Run may proceed to the F-04 cardinality gate.
• Cardinality mismatch after source match: source identity matches, but candidate N differs from RID-header N; the Run refuses under F-04 without changing the existing Store.
• Different source filename for target Store: Work Order SOURCE differs from the target RID lineage's source filename; the Run refuses before materialization and publishes no candidate COL or successor Store state.
• Internally inconsistent Store lineage: rows sharing one rid_filename but containing more than one source_filename violate the Store invariant and cannot serve as the materialization base for that Store.
• No positional-alignment escape: two different sources with equal row counts still cannot be attached to the same RID lineage.

When explicit joins are designed in a later build, the preferred direction is to preserve single-source Store-lineage semantics and represent cross-Store relationships through a separate governed Join MAP or equivalent join-specific artifact.

A future join-specific artifact could record facts such as the left Store/MAP, right Store/MAP, left key, right key, join type, and the governed evidence needed to prove the relationship. The exact artifact class, filename grammar, schema, syntax, lifecycle, and acceptance rules are deliberately not frozen here.

This preserves a clean boundary: a Store MAP may describe multiple single-source Store lineages; a future Join MAP would record how two governed Stores were explicitly related.

Claude's F-05 concern is resolved because the compatibility predicate is now explicit and independently testable at the Store-lineage level: the target RID lineage is internally single-source, the Work Order source must match that lineage's source filename, and matching source identity is followed by the existing F-04 cardinality gate.

Different Store lineages may coexist in one MAP without being treated as joined. A Store lineage cannot become a hidden positional-join mechanism, and future cross-source joins remain a separate, deliberately designed capability.

• The WASM-002 Store MAP profile must be revised so the redundant store_source_filename field is removed and each materialized COL row carries exactly one source_filename.
• One Store MAP may contain multiple Store lineages. Store lineages are distinguished by rid_filename; all rows within one RID lineage must agree on source_filename, while different RID lineages may use different source filenames.
• An explicit Store MAP is compatible with a Work Order only at the target Store-lineage level: Work Order SOURCE must exactly match the common source filename of the target RID lineage. Other Store lineages in the same MAP may name other sources.
• Matching source identity does not replace the F-04 gate; candidate logical row count must still equal the valid RID-header N before existing-Store publication may commit.
• Acceptance fixtures must prove a valid multi-Store MAP, mismatched-source refusal for one target RID lineage, mixed-source invalidity within one RID lineage, and refusal of equal-row-count cross-source positional attachment.
• The future Join MAP direction recorded in F-05 is not part of WASM-002 and must not create a current artifact class, schema, syntax form, gate, or implementation obligation.
• Existing RID-recovery requirements and DS-STEPS syntax that imply RID regeneration will need to be retired or rewritten.
• MAP eligibility/current-state language must distinguish a DEGRADED Store from an INVALID Store rather than making both disappear from inheritance/routing.
• Ordinary materialization must not silently create a replacement Store merely because a current Store is DEGRADED or INVALID.
• Help requirements must explain the three statuses, why a Store entered DEGRADED or INVALID, and the only permitted DEGRADED recovery command.
• Acceptance fixtures will be needed for: missing COL → DEGRADED; missing RID → INVALID; REPAIR MAP removes only broken COL bindings; valid COLs cannot be removed by repair; successful repair → VALID; all non-repair Store operations refuse while DEGRADED.
• RID serialization must adopt the frozen N=<value> header followed by exactly the sequence 1..N.
• Existing-Store materialization must compare candidate row count against the valid RID header before publication and refuse on mismatch without changing Store status.
• Acceptance fixtures will also be needed for RID header/sequence consistency, candidate N == RID N success, candidate N != RID N pre-publication refusal, same-filename candidate extension routing, and distinct-source-filename new-Store/new-RID creation.
• WASM-002 must not add a NEW STORE command for this case; the analyst expresses a new row universe by preserving the CSV under a distinct visible filename and referencing that filename as SOURCE.
• The WKO MAP remains a governed CSV MAP profile, but the alias-registry profile must be revised from the earlier two-column form to the frozen three-column form wko_status,wko_alias,wko_filename.
• The only frozen WKO registry status values are CURRENT and DEPRECATED. Status belongs to the WKO registry row; it does not modify the immutable WKO file or the alias text stored inside that WKO.
• If a save would reuse a non-empty alias already held by a CURRENT row, Data Sculptor must stop before commit and offer the analyst exactly the lifecycle choice Replace alias target or Cancel.
• If the analyst chooses Replace alias target, the successor WKO MAP changes the previous row for that alias to DEPRECATED and adds the newly saved WKO as the sole CURRENT row for that alias. If the analyst chooses Cancel, no alias-registry change is committed.
• For any non-empty alias, at most one row in the current WKO MAP may be CURRENT; any superseded rows for that alias are DEPRECATED. Alias resolution by human-facing alias considers the CURRENT row, never greatest filename UTC.
• Deprecated WKO files and prior WKO MAPs remain immutable historical evidence. Deprecation is registry history, not deletion, invalidation, or byte mutation.
• The human-facing Work Order list/map may render the same CSV truth as two sections — CURRENT WORK ORDERS and DEPRECATED WORK ORDERS — while the physical governed artifact remains one deterministic CSV file.
• WASM-002 adds the governed Work Order operation REPAIR WORK ORDER REGISTRY. It reconciles the current WKO MAP against visible valid WKO artifacts without reconstructing missing files or changing established current authority.
• Repair removes every current-registry row whose referenced physical WKO file is missing. The missing WKO is not reconstructed, inferred, or replaced by an older deprecated WKO.
• A visible valid WKO that is absent from the current WKO MAP is not a governed Run target until registry repair registers it.
• Repair adds an unregistered valid WKO as CURRENT when its non-empty alias has no existing CURRENT binding. If its alias already has a CURRENT WKO, the discovered WKO is added as DEPRECATED; existing current authority is not displaced merely because another file appeared.
• If repair discovers multiple previously unregistered valid WKOs sharing the same non-empty alias and there is no established CURRENT binding, repair registers those discovered WKOs as DEPRECATED rather than guessing which one should become current. An unaliased valid WKO has no alias collision and may be registered as CURRENT.
• Repair publishes a successor WKO MAP; predecessor WKO MAPs and all surviving WKO files remain unchanged. Help explains removed stale references and any discovered WKOs registered as deprecated.

These are integration consequences, not edits to the official PRD in this document.

A saved WKO remains an immutable governed artifact. Editing a loaded WKO and saving the result creates a new immutable WKO identity; the older WKO file is neither overwritten nor deleted.

The lifecycle distinction belongs to the WKO registry row, not to the bytes of the WKO itself. A deprecated WKO therefore retains its original WORK ORDER AS text and every other byte exactly as saved.

The WKO alias-registry MAP remains a governed CSV artifact. For this lifecycle model its frozen profile is:

wko_status,wko_alias,wko_filename

The only frozen values of wko_status are CURRENT and DEPRECATED.

When a save would create a new immutable WKO whose non-empty alias is already held by a CURRENT WKO row, Data Sculptor must not silently choose between the two and must not require the analyst to invent a different alias.

Before the alias-registry commit, Data Sculptor presents the analyst with exactly two lifecycle choices:

• Replace alias target — continue the save and supersede the prior current binding;
• Cancel — do not commit the alias-registry change.

If Replace alias target is chosen and the save transaction commits successfully, the successor WKO MAP:

• retains the prior WKO row but changes its wko_status from CURRENT to DEPRECATED;
• adds the newly saved WKO row with the same alias and wko_status=CURRENT;
• leaves every WKO file unchanged;
• leaves the predecessor WKO MAP unchanged as historical evidence.

No permanent deletion is part of alias replacement.

For any non-empty alias represented in the current WKO MAP, at most one row may have wko_status=CURRENT. Any superseded rows with that same former/current alias are retained as DEPRECATED.

When a user or governed operation resolves a WKO by human-facing alias, Data Sculptor considers the CURRENT row. It does not resolve by greatest filename timestamp or greatest UTC.

A DEPRECATED WKO is historical governed evidence. Deprecation does not mean that its physical WKO file is invalid, deleted, or rewritten.

DEPRECATED describes registry authority for alias resolution; it does not mutate or invalidate the physical WKO artifact. Direct historical inspection may remain available, while governed Run eligibility follows the current registry and other separately frozen Run rules.

The governed WKO MAP remains one deterministic CSV file. Example after Prepare monthly crime data has been edited and the analyst chose Replace alias target:

wko_status,wko_alias,wko_filename
CURRENT,Prepare monthly crime data,__DS__WKO__20260923T175010331Z__D4.txt
CURRENT,Create Halifax subset,__DS__WKO__20260921T091233442Z__B7.txt
CURRENT,Export executive report,__DS__WKO__20260922T164455006Z__C3.txt
DEPRECATED,Prepare monthly crime data,__DS__WKO__20260920T140501123Z__A1.txt

Claude identified that Revision BL simultaneously required immutable new WKO identities for edits and unique current aliases, but supplied no retirement/supersession path. The frozen rule above supplies that path at save time: the analyst explicitly chooses whether to replace the alias target or cancel; replacement preserves the previous WKO as DEPRECATED history and makes the new immutable WKO the sole CURRENT alias target.

This removes the need to invent a different human alias for every saved revision, avoids timestamp arbitration, avoids destructive overwrite/delete behavior, and keeps the current WKO MAP itself human-readable as a record of both present alias authority and superseded history.

A WKO MAP row whose referenced physical WKO file is no longer present is a stale registry reference. Data Sculptor must not silently fall back to an older WKO MAP, reconstruct the missing WKO, or automatically promote a deprecated WKO to replace it.

The frozen governed repair syntax is:

REPAIR WORK ORDER REGISTRY

Repair resolves the current WKO MAP, compares its rows with the visible Suitcase, and removes every row whose referenced WKO file is missing. The affected Work Order is therefore gone from the successor registry. Surviving WKO files are not edited or deleted, and predecessor WKO MAPs remain immutable historical evidence.

Until repair, a missing referenced WKO cannot be loaded or Run. A registry-changing transaction that requires a fully valid successor WKO MAP must not silently bypass the stale reference.

A visible WKO that is well-formed and passes the governed WKO validity checks but is absent from the current WKO MAP is unregistered. It is not a governed Run target merely because its file is present.

REPAIR WORK ORDER REGISTRY also reconciles this direction:

• If the discovered WKO has no non-empty alias collision with an established CURRENT row, repair adds it as CURRENT.
• If the discovered WKO uses an alias already held by an established CURRENT row, repair adds the discovered WKO as DEPRECATED. The established current target remains current.
• If two or more previously unregistered valid WKOs are discovered with the same non-empty alias and there is no established current binding, repair adds those discovered WKOs as DEPRECATED rather than inventing current authority from filename time, discovery order, or UUID.
• An unaliased valid WKO has no alias collision and may be registered as CURRENT.

This means newly discovered files can be brought under governance without letting their mere arrival silently displace a Work Order that the current registry already treats as authoritative.

Repair is structural reconciliation, not content recovery. It publishes a successor WKO MAP only after the repaired registry satisfies its validity rules. It never rewrites a WKO, recreates a missing WKO, infers that a deprecated WKO should be current, or selects a winner by greatest UTC.

Help must explain which stale rows were removed, which visible WKOs were newly registered, and which discovered alias-colliding WKOs were registered as DEPRECATED. The human remains free to use the ordinary load/edit/save alias-replacement workflow later if a deprecated WKO should become the new current target.

F-02 now has deterministic rules for all lifecycle edges Claude raised: editing and re-saving an aliased immutable WKO, superseding alias authority without deletion, a registered WKO disappearing from the Suitcase, and a valid visible WKO appearing without a registry row.

The WKO MAP remains the governed registry truth; immutable WKO files remain visible evidence; and REPAIR WORK ORDER REGISTRY reconciles filesystem reality without guessing away established current authority.

WASM-002 uses a deliberately explicit Data Sculptor CSV profile. It is RFC 4180-inspired but is not defined merely by reference to RFC 4180 or by the behavior of any parser library. The rules below are the product contract.

• Delimiter: comma (,) is the only field delimiter. Automatic delimiter detection and semicolon/tab/other-delimiter CSV dialects are outside the WASM-002 CSV contract.
• Quoted fields: double quote (") is structural only when it begins a quoted field. A quote appearing inside an unquoted field, such as ab"c, is malformed and refuses.
• After a closing quote: the next byte must be a comma, an accepted record terminator, or EOF. Characters after a closing quote, such as "ab"c, are malformed and refuse.
• Record terminators: LF ( ) and CRLF ( ) are accepted. A bare CR is not a record terminator and refuses as malformed CSV, including CR followed by a byte other than LF.
• EOF: the final record may terminate directly at EOF without a trailing LF or CRLF.
• Final line ending: one accepted record terminator ending the final record does not create an additional phantom blank record. Ordinary exported CSV files ending in LF or CRLF therefore remain valid under this rule.
• One-column CSV: one-column sources are valid. In a one-column source, "" is the explicit representation of an empty field. A physically blank record remains a blank record and is refused under the existing blank-record rule.

• An optional UTF-8 BOM with bytes EF BB BF is permitted only at absolute source-byte offsets 0–2, before the first CSV field.
• That leading BOM is an encoding signature, not CSV data. It must not become part of the first header name or first field value.
• A U+FEFF occurring anywhere else is not granted BOM semantics merely because of its value; after decoding it is ordinary input data subject to the CSV grammar and other applicable rules.
• After an optional leading BOM is consumed at the encoding/CSV boundary, BOM presence or absence must not otherwise change CSV parsing semantics.
• The physical BOM bytes remain part of the source byte stream for any absolute source-byte location accounting. The exact common offset/error semantics are frozen with the shared error contract under F-07, not duplicated here.

Any violation of the frozen CSV profile above is a deterministic malformed-CSV refusal. Parser-library leniency must not broaden the accepted language. Streaming window boundaries must not change whether input is accepted, which malformed condition is encountered first, or the governed location reported for that condition.

F-06 freezes what constitutes valid and malformed CSV. The exact common diagnostic location facts and byte-offset convention are intentionally delegated to F-07 so that WASM-002 has one error-location contract rather than two competing definitions. That dependency does not leave the CSV grammar open.

Claude's seven unresolved CSV cases now have deterministic answers: quote placement, post-quote characters, bare CR handling, EOF termination, final line-ending behavior, one-column empty values, and delimiter scope. The Council additionally froze UTF-8 BOM handling because the BOM sits directly at the encoding-to-CSV boundary and must never silently become analytical data.

Independent fixtures can now be authored against the accepted/refused byte forms without inheriting undocumented behavior from the Rust csv crate or another parser. F-07 remains responsible only for the shared error-location/offset oracle.

The governed UTF-8 first-invalid offset is the zero-based absolute byte offset, measured from the first physical byte of the source file, of the first byte of the invalid UTF-8 sequence.

The offset is a property of the physical source byte stream. It is not a character index, code-point index, logical CSV position, decoded-text position, or streaming-window-relative offset.

• A lone invalid byte or lone continuation byte reports the absolute offset of that byte.
• An invalid multibyte sequence reports the absolute offset of its lead byte.
• If a sequence begins with a valid multibyte lead byte but becomes invalid when a later byte is examined, the reported offset remains the offset of that sequence's lead byte.
• A multibyte sequence truncated by EOF reports the absolute offset of its lead byte.
• If an invalid sequence spans two or more streaming windows, the result is identical to parsing the same bytes in one contiguous window. Window boundaries never reset or alter the governed offset.

The F-06 CSV profile permits one UTF-8 BOM, byte sequence EF BB BF, only at absolute offsets 0 through 2. That leading BOM is an encoding signature and is not analytical CSV data.

Nevertheless, the BOM bytes remain physical source bytes. Therefore all governed absolute byte offsets count them. For example, the first byte following a permitted UTF-8 BOM is at absolute byte offset 3, not 0.

This preserves one literal meaning of “absolute source byte offset” regardless of whether a permitted BOM is present.

A UTF-8 validation refusal must expose, at minimum, the following deterministic facts to the governed diagnostic/Receipt/Help path:

• FIRST_INVALID_BYTE_OFFSET — the governed zero-based absolute source-byte offset defined above;
• STOP_REASON — a deterministic UTF-8 validation reason identifying why validation stopped.

An implementation may retain or expose an offending-byte evidence window where separately required, but such a window is not the authority for the first-invalid offset. The offset rule above is authoritative.

The exact human-facing wording of the diagnostic remains a Help/rendering concern; it must not change these machine-deterministic facts.

F-06 freezes the CSV input grammar and states that malformed-input failures must be deterministically locatable. F-07 freezes the common absolute-source-byte convention for UTF-8 validation failures. The two rules are compatible: the optional leading UTF-8 BOM is excluded from analytical CSV content but included when counting physical source bytes.

F-07 does not reopen the CSV grammar decisions frozen under F-06.

Claude identified that Revision BL required exact offsets but did not define whether an invalid multibyte sequence reports its lead byte, the later offending byte, or EOF, and did not state whether streaming-window boundaries affect the result. The frozen rules above supply one independent oracle: the first byte of the invalid sequence, counted as a zero-based absolute offset from the first physical source byte.

This makes lone-byte, malformed multibyte, truncated-EOF, BOM-bearing, and cross-window fixtures deterministic without allowing the implementation library to choose the contract.

• DS-STEPS string literals are delimited by the ASCII double-quote character ".
• A literal double quote inside a string is represented by doubling it: "". Backslash escaping is not part of the WASM-002 DS-STEPS lexical contract.
• Strings do not span physical lines.
• Unicode text inside the delimiters is otherwise preserved as authored; keyword case rules do not case-fold string contents.
• An empty string is syntactically representable as "", but any operation clause whose semantic contract requires a non-empty value must refuse an empty string.

Example: a header named The "official" rate is written as HEADER "The ""official"" rate".

DS-STEPS keywords are parsed ASCII case-insensitively. Canonical Data Sculptor examples and renderings use uppercase keywords. String contents, filenames, aliases, headers, and other quoted values are not altered merely because keyword matching is case-insensitive.

• Spaces and horizontal tabs may appear before clauses and between tokens where token separation is otherwise valid.
• Indentation carries no semantic meaning in WASM-002.
• Blank physical lines are ignored by the parser.
• A # begins a whole-line comment only when it is the first non-whitespace character on that physical line.
• Inline comments are not part of the WASM-002 lexical contract.
• Comments remain part of the saved Work Order bytes and therefore remain part of that artifact's exact identity.

The COLUMN n selector accepts only an unsigned base-10 integer in canonical lexical form [1-9][0-9]*. Therefore COLUMN 7 is valid. COLUMN 07, COLUMN +7, COLUMN 0, COLUMN -7, decimal forms, and other numeric spellings refuse.

For the WASM-002 materialization Work Order form, clause order is enforced, not merely canonical presentation. Ignoring blank lines and whole-line comments, the form contains:

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

Duplicate structural clauses refuse. An empty KEEP refuses. After MATERIALIZE, only blank lines or whole-line comments may follow.

• Any nonblank, non-comment line that is not valid in the selected WASM-002 operation grammar refuses. There is no best-effort interpretation and no silently ignored text.
• One saved Work Order must conform to one defined WASM-002 operation grammar. Clauses from another operation may not be mixed into that Work Order unless the selected operation's frozen grammar explicitly defines that combination.
• Accordingly, a materialization Work Order does not acquire unrelated STORE AS, RID AS, CLEAR, RESET, or other operation clauses merely because another requirement mentions those tokens elsewhere.

• A valid WASM-002 Work Order TXT artifact is UTF-8.
• Data Sculptor-authored Work Orders are serialized without a UTF-8 BOM and use LF line endings.
• When reading an existing Work Order, Data Sculptor accepts LF or CRLF physical line endings.
• A lone CR line ending refuses.
• Invalid UTF-8 refuses.
• Accepting CRLF does not authorize silent normalization of an existing saved Work Order. The bytes actually saved remain the immutable artifact bytes and remain identity-bearing.

For WASM-002, RUN is the exact recognized Work Order composition/invocation keyword that triggers the deferred-composition refusal when parsed as a construct. WASM-002 does not invent additional aliases such as CALL, EXEC, or INCLUDE merely to broaden that gate. If such a line is not part of another defined operation grammar, it is unknown syntax and refuses under Section 11.6.

• String fixtures must prove ordinary quoted values, doubled-quote inclusion, unterminated strings, physical-newline refusal inside a string, and empty-string refusal where a clause requires a non-empty value.
• Keyword fixtures must prove mixed/lowercase keyword acceptance without changing quoted content.
• Whitespace fixtures must prove indentation neutrality, blank-line tolerance, whole-line comments, and refusal of unsupported inline-comment interpretation.
• Ordinal fixtures must distinguish 7 from refused forms such as 07, +7, 0, -7, and decimal spellings.
• Structure fixtures must prove enforced clause order, exactly-one cardinality for structural clauses, non-empty KEEP, terminal MATERIALIZE, and refusal of non-comment text after it.
• Unknown-line and mixed-operation fixtures must prove refusal rather than ignored text or cross-operation interpretation.
• WKO byte fixtures must prove UTF-8, Data Sculptor-authored no-BOM/LF serialization, accepted LF and CRLF reads, lone-CR refusal, and no silent rewrite of accepted existing bytes.
• Composition fixtures must prove that parsed RUN triggers the deferred-composition diagnostic and that invented near-synonyms do not become composition syntax by accident.

Claude's F-08 concern was that save-time validation, run-time validation, string handling, and the deferred-composition gate depended on lexical rules that Revision BL cited but did not define. The frozen rules above now supply an independent oracle for quoting, keyword case, whitespace, comments, ordinal numerals, clause order/cardinality, unknown lines, operation mixing, WKO byte form, and the exact deferred-composition token.

An implementation no longer has discretion to import accidental syntax from a parser library or another language for these points. Revision BL remains the reviewed evidence baseline until the frozen decisions in this log are deliberately integrated into a later PRD revision.

• RCP and INV TXT artifacts are UTF-8.
• Data Sculptor serializes them without a UTF-8 BOM.
• Line endings are LF only.
• Every artifact ends with exactly one final LF.
• No serialized line carries trailing spaces.
• No blank physical lines are emitted unless a later artifact grammar explicitly freezes them.

Every ordinary serialized fact uses exactly:

KEY: VALUE

• KEY is an uppercase ASCII field name.
• The separator is one ASCII colon followed by exactly one ASCII space.
• The KEY=VALUE form is not permitted in RCP or INV serialization.
• Accordingly, conversion evidence uses the colon form, for example SOURCE_ENCODING: WINDOWS-1252-COMPATIBLE.
• Key order is normative and forms part of the byte-for-byte acceptance oracle.

• 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: "".
• CR and LF are not permitted inside a single serialized value. Each fact remains exactly one physical line.

• NONE — the fact definitively has no value in this event.
• NOT_RUN — the stage or operation was not executed.
• NOT_AVAILABLE — the value should exist or may exist, but could not be obtained.
• UNKNOWN_OPERATION — parsing or validation failed before a governed operation could be identified.

An unparseable Work Order therefore records OPERATION: UNKNOWN_OPERATION; the field is not left blank or omitted.

Every WASM-002 Receipt begins with the following common keys in this exact order:

1. RECEIPT_VERSION
2. RECEIPT_UTC
3. WORK_ORDER_FILENAME
4. OPERATION
5. RESULT
6. DIAGNOSTIC_ID

Operation-specific facts follow in their frozen operation order, followed by the created-artifact list defined in Section 12.6. DIAGNOSTIC_ID is never omitted: successful execution records DIAGNOSTIC_ID: NONE; a refusal records the exact governed diagnostic ID.

Created artifacts are serialized by a declared count followed by one-based, three-digit, contiguous indexed keys:

CREATED_ARTIFACT_COUNT: 3
CREATED_ARTIFACT_001: "__DS__RID__...csv"
CREATED_ARTIFACT_002: "__DS__COL__...csv"
CREATED_ARTIFACT_003: "__DS__MAP__...csv"

• The number of indexed lines must equal CREATED_ARTIFACT_COUNT.
• Indices begin at 001, increase by one, and contain no gaps.
• When the count is zero, no CREATED_ARTIFACT_nnn lines are present.
• Comma-separated filename lists, repeated unindexed keys, and continuation-line list syntax are not part of the WASM-002 contract.

Where the operation is known, the Receipt uses the governed operation token. At the point F-09 was frozen, the operation tokens were MATERIALIZE, INVENTORY, UPDATE_ALIASES, and REPAIR_MAP. The F-10 resolution below subsequently freezes CONVERT_WINDOWS_1252_TO_UTF_8 and its conversion-specific Receipt facts without reopening the shared serialization grammar frozen here.

RECOVER_RID is not a valid WASM-002 operation token. F-03 already froze that a missing or invalid RID makes the Store INVALID and that RID recovery is not permitted; REPAIR MAP is the sole DEGRADED Store recovery operation.

The UPDATE_ALIASES Receipt includes, in operation-specific fact order:

1. BASE_MAP_FILENAME
2. SUCCESSOR_MAP_FILENAME

Both use the common quoted-text serialization. If execution refuses before a successor MAP exists, SUCCESSOR_MAP_FILENAME: NONE is recorded together with the applicable diagnostic ID.

Inventory TXT uses the same UTF-8/no-BOM/LF physical rules and the same KEY: VALUE grammar. Its frozen header is:

1. INVENTORY_VERSION
2. INVENTORY_UTC
3. FILE_COUNT

The header is followed by exactly FILE_COUNT filename lines using one-based, three-digit, contiguous keys: FILE_001, FILE_002, and so on. Filenames use the common quoted-text serialization.

Inventory ordering is exact ascending order of the physical filename's UTF-8 byte sequence. Locale-aware collation, case-folded collation, and filesystem enumeration order are not permitted as the serialization authority.

• The later PRD integration must carry at least one golden byte-exact Receipt fixture for each WASM-002 operation whose grammar is frozen.
• The later PRD integration must carry at least one golden byte-exact Inventory TXT fixture.
• Acceptance compares emitted artifact bytes directly against those fixtures, including encoding, BOM absence, LF placement, key spelling, key order, quoting, escaping, list indices, absence tokens, and the final LF.
• F-10, reconciled below, adds the conversion operation's exact token, operation-specific Receipt facts, and golden-byte conversion/Receipt fixtures without reopening the shared serialization grammar frozen here.

Claude's F-09 concern was that Revision BL required byte-for-byte Receipt and Inventory testing while leaving the byte grammar partly to the implementation. The frozen rules above now define the physical text encoding, line grammar, quoting/escaping, absence vocabulary, unknown-operation token, common Receipt key order, indexed list form, UPDATE ALIASES facts, Inventory line form, and deterministic filename ordering.

The acceptance obligation now has a spec-side oracle rather than merely testing whether one implementation is self-consistent. Revision BL remains the reviewed evidence baseline until these frozen decisions are deliberately integrated into a later PRD revision.

Windows-1252-to-UTF-8 conversion remains an in-scope but separate governed Work Order operation. It is not silently invoked by a failed analytical Work Order, UTF-8 certification, or materialization. The analyst must explicitly authorize the conversion operation.

An earlier Day 039 design note contemplated transcoding while materializing. Revision BL superseded that direction by defining conversion as a distinct operation. The F-10 decision follows Revision BL: conversion produces a governed UTF-8 derivative first; any later analytical use occurs through a separate Work Order.

• CONVERT WINDOWS-1252 TO UTF-8 is the terminal operation clause for this WASM-002 Work Order form.
• Exactly one SOURCE is permitted.
• No KEEP, MATERIALIZE, Store alias, RID clause, COL clause, or other analytical/materialization clause may appear in the same Work Order.
• The lexical, quoting, ordering, unknown-line, and one-operation-per-WKO rules frozen under F-08 apply unchanged.

1. Validate the complete source as strict UTF-8.
2. If the complete source is already valid strict UTF-8, refuse the conversion as unnecessary; do not create a CVT artifact.
3. Only after strict UTF-8 fails, assess compatibility with the frozen Windows-1252 mapping.
4. If any source byte is undefined or unsupported by that mapping, refuse rather than guess.
5. Only a source that fails strict UTF-8 and passes the Windows-1252 compatibility assessment may be converted.

The exact full Windows-1252 mapping and its undefined-byte semantics remain part of the separate F-16 reconciliation. F-10 freezes the operation and output contract for a source that is accepted by that mapping.

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

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

Accordingly, “canonical UTF-8 output” means a deterministic UTF-8 encoding of the accepted source characters, not a normalization of line endings, CSV quoting, delimiters, records, headers, or fields.

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

A successful conversion publishes exactly one converted-source artifact with semantic class CVT and physical CSV serialization:

__DS__CVT__<UTC>__<UUID>.csv

The three-letter class describes the artifact's role; the .csv extension describes its physical representation. The converted artifact receives its own governed identity and is distinct from the analyst-owned source.

• Conversion streams the accepted source through the deterministic Windows-1252 mapping into a visible governed SCR candidate under bounded-memory operation.
• The analyst-owned source is read only and is never rewritten in place.
• At source EOF, Data Sculptor closes the candidate, reopens it, and certifies the complete candidate as strict UTF-8.
• Data Sculptor also confirms that conversion completed without an undefined/unsupported Windows-1252 source byte.
• Only after those checks pass is the candidate promoted by final host rename from SCR to its governed CVT filename.
• That final rename is the CVT publication commit point.
• Failure before the commit point publishes no CVT artifact. Any retained failure evidence remains governed by the normal SCR/recovery/evidence rules rather than masquerading as a successful converted source.

Conversion does not create or mutate a Store, RID, COL, or Store MAP and performs no analytical materialization.

To use a successful converted artifact analytically, a later saved Work Order names the exact physical CVT filename as its source, for example:

SOURCE "__DS__CVT__20260926T190000000Z__00000000-0000-4000-8000-000000000000.csv"

The CVT then enters the ordinary strict UTF-8 certification and materialization path as a governed source artifact. No automatic handoff or hidden Store registration occurs.

F-09's shared RCP grammar applies unchanged. The exact operation token is:

OPERATION: CONVERT_WINDOWS_1252_TO_UTF_8

Conversion-specific facts are serialized in this order before the common created-artifact list:

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

On successful conversion, the frozen values include:

SOURCE_FILENAME: "legacy_source.csv"
SOURCE_ENCODING: WINDOWS-1252-COMPATIBLE
MATERIALIZED_ENCODING: UTF-8
TRANSCODING: BOUNDED_STREAMING
SOURCE_CHANGED: NO
OUTPUT_FILENAME: "__DS__CVT__...csv"

On refusal before a CVT exists, OUTPUT_FILENAME: NONE is recorded with the applicable governed DIAGNOSTIC_ID. A successful conversion's created-artifact list contains the one CVT artifact.

At minimum, PRD integration must carry a byte-exact conversion fixture proving character transcoding, line-ending preservation, and BOM absence. One frozen minimal fixture is:

Windows-1252 source bytes:
63 61 66 E9 0D 0A

UTF-8 CVT bytes:
63 61 66 C3 A9 0D 0A

This represents café followed by CRLF. The expected CVT begins immediately with 63; no EF BB BF prefix is present.

Acceptance for the conversion operation must also demonstrate:

• the analyst-owned source bytes are unchanged;
• the published CVT passes complete strict UTF-8 certification;
• source CR, LF, and CRLF bytes are preserved rather than normalized;
• conversion is bounded/streaming;
• the successful Receipt contains the frozen F-10 operation token and required conversion facts;
• a source already valid as strict UTF-8 is refused as an unnecessary conversion and creates no CVT;
• a source containing a byte refused by the frozen Windows-1252 mapping creates no CVT;
• golden output bytes and the golden Receipt bytes are compared byte-for-byte against contract fixtures.

Claude's F-10 concern was that an in-scope operation with an acceptance gate still required the implementer to invent its Work Order syntax, output serialization, BOM and line-ending behavior, publication path, and evidence contract. The frozen rules above now provide those decisions while preserving Revision BL's separation between conversion and analytical materialization.

The converter now has one deliberately narrow responsibility: produce a faithful, governed UTF-8 derivative from a source accepted by the frozen Windows-1252 mapping. It does not repair CSV, normalize records, silently rewrite the analyst's file, or attach the derivative to a Store. Revision BL remains the reviewed evidence baseline until this decision is deliberately integrated into a later PRD revision.

WASM-002 shall not create, publish, discover, validate, select, or maintain a separate HTML Store Index artifact. No Store Index artifact class is allocated for WASM-002.

The separate Store Index concept is retired from the WASM-002 implementation contract rather than completed by inventing a new governed class, trigger, or serialization. The useful human-orientation intent survives through aliases in WASM-002 and through the governed Suitcase Directory (DIR) in WASM-003.

The Store MAP remains the authoritative machine-readable relationship between governed Store identity, RID, COL artifacts, source binding, aliases, lineage, status, hashes, and related provenance.

No HTML orientation artifact may compete with, replace, or silently become a second source of Store truth in WASM-002.

The WASM-002 meaning of W002-STOR-010 is narrowed from “Store Index and aliases as human orientation” to “Aliases as human orientation.”

• Aliases may help a person understand a Store, column, operation, source, receipt, Help event, or governed artifact.
• Aliases never rename the underlying Core physical artifact.
• Aliases do not replace exact physical filenames where exact identity is required.
• The Store MAP remains the machine-truth substrate for alias binding and governed relationships.

• W002-STOR-010.1 remains in force: an alias may orient a user to a Store, column, operation, source, Receipt, Help event, or artifact without renaming the underlying Core file.
• W002-STOR-010.2 remains in force: changing a friendly alias must not change physical identity, hashes, lineage, or historical provenance.

W002-STOR-010.3 and W002-STOR-010.4 are removed from the WASM-002 implementation obligation because both are specifically about the retired Store Index presentation layer.

• The human-vocabulary orientation intent of W002-STOR-010.3 is carried forward into the separately governed DIR design.
• The static, durable HTML intent of W002-STOR-010.4 is likewise carried forward into DIR.
• This does not pull DIR into WASM-002. DIR remains a separate later build, currently planned as WASM-003.

The no-subfolder rule remains unchanged, but the obsolete Store Index reference is removed.

For WASM-002, the phrase:

open metadata, Store Map/Index, and human-facing aliases

is replaced by:

open metadata, Store MAP, and human-facing aliases

The important invariant remains: current state and durable history are different truths.

For WASM-002, W002-STOR-012 is interpreted and later integrated without the Store Index reference: the current Store MAP and any other explicitly governed current-state artifacts are selected without deleting or rewriting historical artifacts. Historical fact remains preserved in durable history / Flight Recorder evidence.

The WASM-002 storage freeze item is current Store MAP selection rule, not “current Store Map/Index selection rule.”

The old illustrative Store Index example is removed from the WASM-002 normative integration path so that it cannot be mistaken for a required artifact or current architecture.

The governed Suitcase Directory is the later human-facing project-orientation artifact. It remains deliberately outside WASM-002 and is currently sequenced as WASM-003.

WASM-002 establishes the foundation DIR depends on: validated Suitcase access, governed identities, Store MAP truth, aliases, Stores, Work Orders, Receipts, Help, and visible persistence. WASM-003 may then publish durable DIR HTML snapshots over that already-governed foundation without redefining Store truth.

Claude's F-11 concern was that the contract made a persistent HTML Store Index mandatory while providing no registered class, generation trigger, or content contract. The implementer therefore had no conforming way to satisfy the requirement without inventing architecture.

The frozen decision removes that contradiction. WASM-002 now has one machine-truth substrate for Store state—the Store MAP—plus aliases for human orientation. The richer durable HTML project-orientation role belongs to the separately governed DIR build. No additional Store Index artifact is required or permitted in WASM-002.

The pre-Revision-BB meaning of W002-UI-ACC-019 is retired. WASM-002 shall not expose or persist an independent mutable Work Order Description separate from the governed Work Order TXT.

There is no standalone editable Description field for a draft or saved Work Order and no separate hidden or mutable Work Order-description store.

The human-facing Work Order label in WASM-002 is the WORK ORDER AS value contained in the governed WKO TXT itself.

Because that label is part of the governed WKO bytes, changing it is an edit to the Work Order artifact rather than an out-of-band metadata edit.

Editing any byte of a loaded saved Work Order—including WORK ORDER AS, comments, or operational instructions—creates a derived draft.

• The previously saved WKO remains byte-for-byte unchanged.
• Its physical filename and UUID remain unchanged.
• The derived draft cannot Run until it is saved as a new immutable WKO identity.
• Saving the derived draft never rewrites or renames the predecessor WKO file.

The old acceptance gate is replaced by a gate proving the architecture that WASM-002 actually permits:

• the browser exposes no standalone editable Work Order Description field;
• no separate mutable or hidden Work Order-description store exists;
• editing any governed WKO byte transitions a loaded saved WKO into a derived draft;
• the predecessor WKO TXT bytes, physical filename, and UUID remain unchanged;
• the derived draft cannot Run until saved as a new WKO identity.

If the derived draft is saved with the same non-empty WORK ORDER AS alias already held by the current predecessor WKO, the save follows the frozen F-02 lifecycle.

• Data Sculptor offers exactly Replace alias target or Cancel.
• On successful replacement, the new WKO becomes CURRENT in the successor WKO MAP.
• The predecessor WKO becomes DEPRECATED.
• Neither WKO file is rewritten or deleted.

• Any Revision BL wording that implies a separate mutable Work Order Description is superseded for WASM-002 by this decision.
• The replacement acceptance gate may overlap with existing immutability coverage such as W002-MAT-ACC-002.4; PRD integration may consolidate duplicate proof obligations rather than creating two inconsistent gates.
• This decision does not prohibit future DIR Description metadata. DIR descriptions belong to the separately governed Suitcase Directory contract in WASM-003 and do not become hidden mutable metadata attached to WKO artifacts.

Claude's F-01 concern was a direct contradiction: the old acceptance gate required editing a separate Work Order Description while the later architecture forbade exactly that mutable path. The frozen decision removes the stale requirement instead of implementing prohibited machinery.

WASM-002 now has one coherent rule: human Work Order labeling lives inside the immutable governed WKO TXT. Any change to that label or any other WKO byte creates a new draft and, after save, a new WKO identity under the already-frozen F-02 lifecycle.

Every successor state MAP published by WASM-002 must carry a transaction UTC that is strictly greater than the exact predecessor MAP UTC.

This rule applies to both Store MAP successors and WKO MAP successors. A successor whose observed UTC is equal to or earlier than its predecessor is not eligible for publication.

Data Sculptor must use the actual observed host UTC. It must not synthesize, increment, round forward, or otherwise fabricate a later timestamp merely to make a publication sort after its predecessor.

The canonical UTC token therefore remains evidence of observed time, not a hidden sequence number.

If the observed host UTC is less than or equal to the predecessor UTC, the state publication must refuse.

• No automatic sleep-and-retry loop is performed.
• No predecessor is skipped or replaced by an older fallback state.
• No artificial timestamp is generated.
• The predecessor remains the current authoritative state.

Example: if the predecessor UTC is 20260926T180000500Z, then both 20260926T180000499Z and 20260926T180000500Z refuse; 20260926T180000501Z is acceptable.

The strict-greater-than comparison is a publication precondition. A candidate may not be promoted into a successor WKO MAP or Store MAP unless its transaction UTC passes this check.

A failed clock check must not alter current governed state and must not publish a successor state MAP.

The first MAP in a new lineage has no predecessor UTC to compare against and therefore uses the observed host UTC normally.

The monotonic successor rule begins only when publication is explicitly creating a successor to an existing governed state.

A refusal caused by a non-increasing clock must emit the canonical diagnostic condition for this boundary and expose the ordinary Help path.

The diagnostic facts must include, at minimum, the predecessor UTC and the observed host UTC so the analyst can see why publication was refused. Final diagnostic-ID allocation remains governed by the diagnostic-registry work reconciled separately under Claude Pass 1.

Acceptance must use an injected/test clock seam sufficient to prove the rule deterministically.

• A later observed UTC succeeds.
• An equal-millisecond observed UTC refuses.
• A backward observed UTC refuses.
• Each refusal leaves the predecessor current and publishes no successor state MAP.
• The emitted diagnostic facts report both predecessor UTC and observed host UTC.

Claude's F-12 concern was that greatest-UTC current-state selection could silently preserve stale state after a backward clock step or create a self-inflicted tie when two publications received the same millisecond UTC.

The frozen rule prevents both outcomes without corrupting the meaning of UTC. Data Sculptor may publish a successor state only when the truthful observed UTC is strictly later than its predecessor. Otherwise publication refuses visibly and leaves the prior state authoritative.

Data Sculptor is designed for one user operating one user-owned Suitcase at a time. WASM-002 assumes that only one Data Sculptor execution context writes governed artifacts to that Suitcase at any given time.

Concurrent writers to the same Suitcase are outside the WASM-002 operating contract.

The single-writer assumption does not transfer ownership of the Suitcase to Data Sculptor. The Suitcase and its visible files remain user-owned.

The user may inspect, copy, move, add, or delete files with ordinary filesystem tools. If those actions alter or damage governed state, Data Sculptor applies the separately frozen validity, degradation, invalidity, repair, refusal, and evidence rules. The single-writer contract does not require Data Sculptor to prevent external filesystem changes.

WASM-002 does not implement or promise safe simultaneous mutation of one Suitcase by multiple writers. Therefore this build has no requirement for:

• multi-user collaborative editing;
• distributed or cross-process write locking;
• multi-writer transaction arbitration;
• concurrent publication merge or conflict resolution; or
• multi-tab or multi-instance write coordination for the same Suitcase.

These are outside the WASM-002 contract rather than silently delegated to browser, filesystem, or host behavior.

WASM-002 acceptance is evaluated under the frozen single-user / single-writer operating model. Acceptance fixtures are not required to prove correctness under simultaneous writers to the same Suitcase.

The PRD integration must state this operating assumption explicitly so implementers and QA do not infer an unstated concurrency guarantee.

User ownership permits ordinary filesystem changes between Data Sculptor operations. It does not create a concurrency guarantee while Data Sculptor is actively reading, validating, staging, or publishing governed state.

If another browser tab, process, sync client, filesystem tool, or the user mutates the same Suitcase during an active governed operation, that mutation is a concurrent external write and is outside the WASM-002 operating contract. Data Sculptor is not required to lock out or coordinate that writer.

If such a mutation becomes observable before publication commits and invalidates a governed precondition, Data Sculptor must fail/refuse safely under the All-or-Refuse Publication Discipline rather than knowingly publish from invalidated state. WASM-002 does not promise correctness for an undetectable race caused by an out-of-contract concurrent writer.

Claude's F-13 concern was that the contract relied on a single-writer assumption without stating it. The Council has now made that architectural boundary explicit: one user owns and operates one Suitcase, and one Data Sculptor execution context writes governed artifacts to it at a time.

F-13 therefore requires no new collaboration, locking, merge, or concurrency subsystem. It is closed by making the intended operating model explicit and testable.

A governed non-Store artifact becomes published only after its complete artifact bytes and governed identity satisfy the applicable artifact-class contract.

• Incomplete, interrupted, failed, or invalid candidate output is not a published governed artifact.
• A candidate must not be promoted to its final governed filename until generation and the applicable artifact-specific validation succeed.
• A failed candidate must not participate in current-state resolution, registry authority, governed Inventory truth, or later governed operations as though publication had succeeded.
• The presence of a reserved __DS__-style name alone never proves that an artifact is valid governed evidence.

Where a governed operation publishes a successor artifact, the existing valid predecessor remains authoritative until the successor publication commits successfully. Publication never edits the predecessor in place.

If successor generation, validation, or publication fails, the predecessor remains unchanged and authoritative under its existing current-state rules.

An artifact may remain valid governed evidence without being current. Historical predecessor artifacts remain immutable evidence after a valid successor becomes current.

Likewise, a DEPRECATED WKO may remain a valid physical WKO artifact; deprecation describes registry authority for alias resolution, not corruption or invalidity of the WKO bytes.

This publication discipline applies to governed non-Store artifact classes produced in WASM-002, including WKO, WKO registry MAP, Receipt, Inventory, CVT, and other in-scope governed non-Store outputs whose specific contracts are frozen elsewhere in the PRD/reconciliation.

Artifact-specific grammars and validity predicates remain authoritative for the details of each class; F-14 supplies the common publication boundary and does not replace those class-specific contracts.

• Acceptance must prove that a failed or interrupted candidate cannot appear as successfully published governed evidence.
• Acceptance must prove that invalid candidate bytes or invalid governed identity do not commit under the final governed filename.
• For successor-producing operations, acceptance must prove that the predecessor remains authoritative if successor publication fails.
• Acceptance must distinguish artifact validity from current authority: a historical valid predecessor may remain valid after supersession.

Claude identified that WASM-002 specified several governed non-Store artifact classes without one explicit common boundary between candidate output and published governed evidence. The frozen All-or-Refuse rule now supplies that boundary: complete validated bytes plus valid governed identity are required before publication, failed candidates cannot masquerade as governed truth, and existing authority survives a failed successor publication.

This closes the ambiguity without introducing collaborative locking, multi-writer coordination, or a separate lifecycle system for every artifact class.

Whether a governed MAP is eligible must not depend on arbitrary or unrelated files merely being present in the Suitcase.

• Data Sculptor evaluates the MAP itself under its applicable MAP grammar and validity rules.
• It evaluates the governed artifacts that the MAP explicitly references where those references participate in the applicable validity/health contract.
• An unrelated source CSV, WKO, Receipt, Inventory, CVT, older governed artifact, user-owned file, or newly appearing file does not make an otherwise eligible MAP ineligible merely by existing.
• Filesystem enumeration order, file arrival order, and the total count of unrelated Suitcase files are not MAP-eligibility inputs.

If a file explicitly referenced by a MAP is missing or invalid, that condition is governed by the artifact-specific rules already frozen elsewhere. For Store state, F-03 determines VALID, DEGRADED, or INVALID consequences. WKO registry discrepancies use the F-02 registry and repair rules.

F-15 does not create a second repair path and does not reinterpret referenced damage as an unrelated-file event.

When more than one otherwise eligible MAP participates in current-state resolution for the same applicable governed MAP class/lineage, temporal precedence is determined by the governed publication UTC encoded in the artifact filename, subject to the strict monotonic successor-UTC publication guard frozen under F-12.

• Comparison is performed only among MAPs that belong to the same applicable current-state comparison domain; unrelated MAP classes or lineages do not compete merely because they coexist in the Suitcase.
• UUID establishes opaque artifact identity and does not establish temporal precedence.
• Filesystem modified time, creation time, directory enumeration order, discovery order, and lexical UUID order are not current-state authorities.
• If the frozen rules do not yield one unique authoritative current MAP, Data Sculptor refuses the affected governed operation rather than inventing a tie-breaker.

Adding, copying, or otherwise causing an unrelated file to appear in the user-owned Suitcase cannot by itself change which eligible MAP is current. Current authority changes only through the governed publication/lifecycle rules applicable to that MAP class or through an explicitly governed repair/lifecycle operation already defined for the affected state.

WASM-002 uses exact Unicode scalar-value sequence equality for governed filename and Suitcase-entry reference matching after the filename/reference text has been decoded under the applicable governed text rules.

• No case folding is performed. Data.csv and DATA.csv are different spellings.
• No Unicode normalization equivalence is performed. Two visually similar names encoded with different scalar-value sequences are different spellings.
• No locale-sensitive filename comparison is used.
• A governed textual reference must exactly match the visible entry name returned for the Suitcase item. Data Sculptor does not rely on a host filesystem accepting an alternate case or normalization spelling for the same physical file.
• If the available Suitcase state cannot yield one unique exact match, the governed operation refuses rather than guessing.

This rule deliberately favors cross-platform reproducibility over host-specific filename leniency.

• Acceptance must prove that adding unrelated files does not change MAP eligibility or current-state selection.
• Acceptance must prove that a referenced missing/invalid artifact follows its artifact-specific health or repair rules rather than being ignored as unrelated.
• Acceptance must prove deterministic comparison among eligible MAPs in the same comparison domain using governed publication UTC and the F-12 monotonic successor guard.
• Acceptance must prove that UUID, filesystem timestamps, enumeration order, and discovery order do not break ties or establish current authority.
• An otherwise ambiguous current-state condition must refuse rather than guess.

Claude identified that MAP eligibility could drift as unrelated Suitcase contents changed and that the comparison authority was not explicit. The frozen rule makes eligibility reference-bounded and current-state comparison explicit: unrelated files cannot perturb governed MAP authority, relevant referenced damage follows its existing contract, and temporal precedence is governed rather than inherited from filesystem behavior.

For WASM-002, Windows-1252 compatibility is defined by the frozen Windows-1252 byte-to-Unicode mapping, not by the permissive behavior of a browser, Rust crate, operating-system decoder, or replacement-character fallback.

• Bytes 0x00 through 0x7F map to the corresponding Unicode code points.
• Bytes 0xA0 through 0xFF use the standard Windows-1252 mappings.
• Bytes in the 0x80 through 0x9F range use their defined Windows-1252 assignments where a mapping exists.
• The five undefined Windows-1252 byte values 0x81, 0x8D, 0x8F, 0x90, and 0x9D are not accepted as compatible input.
• If any of those undefined bytes occurs anywhere in the complete source, Windows-1252 compatibility fails and the governed conversion operation refuses.
• Data Sculptor must not substitute U+FFFD, reinterpret an undefined byte as ISO-8859-1, or otherwise guess a character value.

A source that fails strict UTF-8 validation remains a UTF-8 validation failure. The deterministic F-07 facts, including FIRST_INVALID_BYTE_OFFSET and STOP_REASON, remain the governed diagnostic facts for that failure.

A later Windows-1252 compatibility assessment does not replace, relabel, suppress, or mutate the UTF-8 diagnostic. Encoding compatibility and diagnostic classification are separate facts.

After strict UTF-8 validation fails, Data Sculptor may assess the complete source against the frozen Windows-1252 compatibility mapping solely to determine whether the explicit conversion path is available.

• If the complete source is Windows-1252-compatible, Help may state that the source is not valid UTF-8 but is compatible with Data Sculptor's Windows-1252 mapping and may suggest the separate governed CONVERT WINDOWS-1252 TO UTF-8 Work Order operation.
• If the complete source is not Windows-1252-compatible, Help must not present that governed conversion operation as an available remedy for that source.
• The suggestion is advisory Help. It is not a different diagnostic result and does not authorize conversion.

The F-10 operation boundary remains unchanged. A failed analytical Work Order, UTF-8 validation, or materialization never silently converts the source. Conversion occurs only through the separately saved and explicitly authorized Windows-1252-to-UTF-8 conversion Work Order.

F-16 therefore freezes the classification oracle used by the F-10 compatibility gate without reopening F-10's Work Order form, CVT artifact contract, or conversion semantics.

• Acceptance must prove the frozen mapping for representative ASCII, defined 0x80–0x9F, and 0xA0–0xFF byte values.
• Acceptance must prove refusal for each undefined byte: 0x81, 0x8D, 0x8F, 0x90, and 0x9D.
• Acceptance must prove that no replacement-character or ISO-8859-1 fallback makes an undefined byte convertible.
• Acceptance must prove that Windows-1252 compatibility does not alter the governed F-07 UTF-8 diagnostic facts.
• Acceptance must prove that the conversion suggestion appears only when the complete source passes the frozen Windows-1252 compatibility assessment.
• Acceptance must prove that no suggestion or compatibility result triggers automatic conversion.

Claude identified two ambiguities: conversion guidance could be mistaken for a change to fixed diagnostic semantics, and the Windows-1252 compatibility oracle itself was not frozen. The Council resolution separates those concerns. UTF-8 failure retains its deterministic diagnostic identity, while a separate complete-source compatibility test uses one explicit Windows-1252 mapping with five undefined bytes that refuse rather than guess.

This gives F-10 a deterministic classification gate and allows Help to suggest an explicit conversion path without changing the meaning of the original failure.

Diagnostics own facts. Help renders facts. Help does not manufacture facts.

Help presentation may explain, organize, and render governed diagnostic facts, but it must not invent, default, infer, replace, or override machine-deterministic facts merely to satisfy a Help template.

Every governed diagnostic must have a usable Technical Help rendering path even when no diagnostic-specific Help entry has been authored.

• If a diagnostic-specific Technical Help entry exists, Data Sculptor may render that entry from the governed diagnostic facts.
• If no diagnostic-specific entry exists, Data Sculptor renders a deterministic generic fallback that identifies the diagnostic and presents the governed facts that are available.
• The generic fallback must explicitly avoid inventing a cause, interpretation, or remediation that is not established by the diagnostic contract.
• An incomplete Help catalogue must therefore never produce a blank Help surface for a governed diagnostic.

Each governed diagnostic definition explicitly identifies the machine facts required to establish that diagnostic. Those required facts form part of the diagnostic contract.

• A required fact may not be silently omitted, replaced with an empty string, zero, an invented default, or a guessed value.
• If the facts required to establish a particular diagnostic cannot be produced, Data Sculptor must not present that diagnostic as though its required fact contract were complete.
• Facts that are optional or contextual may legitimately carry an applicable frozen absence state.
• Whether a fact is required is defined by the diagnostic contract, not by whichever Help template happens to render it.

Where absence semantics apply, Help reuses the frozen meanings already established for governed text artifacts rather than creating Help-only ambiguity:

• NONE — the fact definitively has no value in this event.
• NOT_RUN — the stage or operation was not executed.
• NOT_AVAILABLE — the value should exist or may exist, but could not be obtained.

Human-facing Help may render these states in natural language such as “None,” “Not run,” or “Not available,” but the presentation must preserve the underlying meaning. Absence must not silently become an empty field, zero, a generic “unknown,” or omission whose meaning cannot be distinguished.

• Acceptance must prove that every governed diagnostic can render Technical Help even when no diagnostic-specific Help entry exists.
• Acceptance must prove that the generic fallback identifies the diagnostic and renders available governed facts without inventing cause or remediation.
• Acceptance must prove that diagnostic-specific required facts cannot be silently omitted or defaulted.
• Acceptance must distinguish required facts from optional/contextual facts independently of Help-template structure.
• Acceptance must prove distinct rendering semantics for NONE, NOT_RUN, and NOT_AVAILABLE where those states apply.
• Acceptance must prove that Help wording or flavor cannot alter the underlying governed diagnostic facts.

Claude identified that the Help contract could fail when catalogue coverage was incomplete, could render absent values inconsistently, and did not define whether a fact was required because of the diagnostic or merely because a template expected it. The frozen rules separate these responsibilities: diagnostics define required truth; Help renders that truth; and a deterministic fallback guarantees coverage without fabrication.

This closes the rendering-contract gap without requiring WASM-002 to author final bespoke prose for every diagnostic or Help voice.

WASM-002 uses one shared governed absence-state vocabulary wherever a present governed fact field needs to express absence:

• NONE — the fact is applicable and definitively has no value in this event.
• NOT_RUN — the relevant 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.

HLP provenance must distinguish non-applicability from unavailability. If a provenance concept does not apply to the Help event, the governed value is NOT_APPLICABLE. If the provenance concept applies but the value cannot be obtained, the governed value is NOT_AVAILABLE.

HLP must not use NOT_AVAILABLE merely as a generic placeholder for a fact that does not apply.

The shared absence tokens retain the same meanings across WASM-002 governed fact-bearing artifacts and diagnostic/Help paths wherever their artifact grammars permit those fields. Artifact-specific synonyms or ambiguous alternatives such as N/A, UNKNOWN, UNAVAILABLE, blank values, or prose variants must not acquire competing machine meanings where the shared governed vocabulary applies.

An artifact's own frozen grammar still determines whether a field is present. F-18 does not require every artifact to serialize every possible fact. It governs the value used when a present governed field expresses one of these absence states.

F-18 extends the shared absence vocabulary frozen under F-09 by adding NOT_APPLICABLE; it does not change the existing meanings of NONE, NOT_RUN, or NOT_AVAILABLE.

F-17 remains authoritative that diagnostics own facts and Help renders facts. Human-facing Help may translate the machine tokens into readable language, but the rendering must preserve the underlying absence state and must not manufacture a value.

• Acceptance must explicitly distinguish NOT_APPLICABLE from NOT_AVAILABLE in HLP provenance fixtures.
• Acceptance must prove the distinct meanings of NONE, NOT_RUN, NOT_AVAILABLE, and NOT_APPLICABLE.
• Acceptance must prove that artifact-specific synonyms, ambiguous blank values, or alternate machine tokens do not replace the shared vocabulary where it applies.
• Acceptance must prove that human-facing Help rendering may rephrase an absence state without changing its governed machine meaning.

Claude identified two related ambiguities: HLP provenance treated a fact that did not apply as though its value were merely unavailable, and different artifacts used inconsistent absence representations. The frozen vocabulary now gives those states separate meanings and applies one governed semantic model across WASM-002.

A consumer can therefore distinguish “there is no value,” “this stage did not run,” “the value could not be obtained,” and “this fact does not apply” without inferring meaning from artifact-specific blanks or synonyms.

WASM-002 treats source headers and Data Sculptor aliases as ordinary analyst-visible Suitcase facts for Help purposes. The analyst owns and can inspect the source CSV and governed artifacts in the Suitcase; Help does not create a separate secrecy boundary around text the analyst is already authorized to work with locally.

A header may contain ordinary data-like or sensitive text. That fact does not require Data Sculptor to redact the header from local Help when reproducing it materially improves understanding of the event.

Help may reproduce a header or alias when it is relevant to explaining the current diagnostic, operation, governed artifact, or corrective action. Help must not dump unrelated headers, aliases, source values, or other Suitcase content merely because those facts are locally available.

The governing question is relevance to understandable Help, not whether the text appears sensitive.

• Source header text may be rendered when needed to identify the column, selector, mismatch, or other condition being explained.
• Store, RID, COL, Work Order, and other governed aliases may be rendered when relevant to identifying the affected object or explaining the action the analyst should take.
• Neither category requires special redaction or a separate sensitivity classifier merely because its human-authored text may contain identifying or sensitive information.
• Help must not infer that structurally interpreted text is safe for unrelated disclosure; the permission is limited to relevant local Help for the user's own Suitcase.

WASM-002 Help rendering is local. Rendering Help does not transmit Suitcase facts, source headers, aliases, source values, diagnostic context, or other Suitcase content to an external service.

This local-processing boundary is what permits Help to remain specific and understandable without introducing a redaction layer between the analyst and the analyst's own data.

Technical Help, later alternate Help voices, and the F-17 deterministic fallback all obey the same relevance and local-processing rules. A rendering voice may change explanation and presentation; it may not broaden the event into an unrelated disclosure of Suitcase content.

• A diagnostic involving a named source header must be able to render that exact header when doing so makes the explanation understandable.
• A diagnostic involving a governed alias must be able to render the relevant alias.
• Fixtures must prove that header or alias text is not redacted merely because it resembles sensitive information.
• Fixtures must prove that unrelated headers, aliases, and source values are not dumped into Help.
• Help rendering must operate without transmitting Suitcase content to an external service.
• The F-17 fallback must preserve the same relevance boundary.

Claude correctly identified that the prior disclosure model did not clearly cover aliases and that a header can itself contain data-like text. The Council resolves those edge cases by making the product boundary explicit rather than by hiding useful context: the Suitcase belongs to the analyst, Help is local, and relevant headers and aliases may be shown to make Help understandable.

Data Sculptor therefore does not need a sensitivity classifier or blanket redaction rule for headers and aliases. It needs a relevance rule and a local-processing guarantee.

A WASM-002 source CSV may contain at most 16,384 columns. This V1 product limit deliberately aligns with the Excel A-through-XFD column range and generalizes the project's existing 16,384-column transpose safety boundary into the WASM-002 source-width contract.

A source containing more than 16,384 columns is refused clearly and deterministically before analytical publication. Data Sculptor does not silently discard, merge, or ignore excess columns.

The maximum operational column-name length is 1,024 Unicode characters after CSV parsing and decoding.

A source header of 1,024 characters or fewer is preserved as the operational column name, subject to the other frozen header/identity rules. A source header longer than 1,024 characters is not truncated and does not by itself cause the CSV to be rejected.

For this WASM-002 limit, one “Unicode character” means one Unicode scalar value in the decoded header string. The limit is therefore exactly 1,024 Unicode scalar values after successful decoding.

Data Sculptor does not normalize the header before counting and does not count user-perceived grapheme clusters. Combining marks and other independently encoded scalar values each count toward the 1,024-value limit. This makes the boundary deterministic and testable.

When a source header exceeds 1,024 Unicode characters, Data Sculptor assigns the deterministic operational name Column <LETTERS>, where <LETTERS> is the Excel-style letter reference derived from the column's one-based physical ordinal.

• Column 1 → Column A
• Column 26 → Column Z
• Column 27 → Column AA
• Column 16,384 → Column XFD

The source CSV remains untouched. The oversized source header remains source evidence; Data Sculptor does not rewrite it or truncate it into a different apparent source header.

Whenever the oversized-header fallback is used during a consequential operation, the resulting Receipt must record that fallback use. At minimum it records the affected column ordinal, the assigned deterministic operational name, and that the substitution occurred because the source header exceeded the 1,024-character operational column-name limit.

The Receipt is not required to reproduce the complete oversized source header merely to document the fallback.

KEEP may select any number of columns from 1 through the full V1 source-width maximum of 16,384 columns. WASM-002 imposes no smaller KEEP-specific width limit. Therefore a valid 16,384-column source may be kept in its entirety.

WASM-002 processing remains streaming/out-of-core. Peak working memory must not scale with source row count or total source-file size. Structural state may scale only within the frozen V1 width bounds needed to represent the header/column metadata and the requested KEEP selection; accumulated row data must not be retained in memory merely because the source is large.

Output-writer concurrency must also remain bounded independently of KEEP width, row count, and total source-file size. A maximum-width KEEP does not authorize one permanently open writable stream or a full-row data buffer per selected column. The implementation may use fixed-size batching, visible governed scratch/staging where otherwise permitted, repeatable multi-pass processing, or another deterministic bounded-resource strategy.

The accepted build must declare the configured upper bound for simultaneously active writable output streams in retained acceptance evidence, and test instrumentation may report the observed peak. The bound is an implementation resource limit, not an analyst-facing syntax limit.

Oversized-header fallback labels must not silently create ambiguous operational names. Before fallback assignment, Data Sculptor knows the set of preserved operational header names at or below the 1,024-scalar-value limit. Oversized headers are then assigned fallbacks in ascending physical column ordinal.

The preferred fallback is Column <LETTERS>. If that exact label collides with a preserved operational name or a fallback already assigned, Data Sculptor tries Column <LETTERS> [<ORDINAL>]. If that also collides, it appends a deterministic numeric suffix -2, -3, and so on until one unique operational label is obtained. The Receipt records the final assigned fallback label.

Column identity remains anchored to physical ordinal and the governed Store/RID/COL model; the fallback label is a deterministic human-operational name, not a replacement for ordinal identity.

WASM-002 does not create, track, merge, or resolve MAP branches, alternate current states, or parallel MAP lineages. Governed MAP publication remains a single chronological history.

Deriving a new MAP from an older eligible MAP does not create a branch. The derivation source and publication chronology are separate facts.

An analyst may explicitly select and use a historical eligible MAP as the input state for a new governed operation. WASM-002 does not require a special historical-successor permission gate merely because the selected MAP is not currently authoritative.

Inspection of a historical MAP alone does not change current state. Current state changes only when a new eligible governed MAP is successfully published.

When an operation using a historical eligible MAP successfully publishes a new eligible MAP, that artifact enters the ordinary chronological MAP history. If its governed publication UTC makes it the latest eligible MAP under the frozen current-state rules, it becomes current.

The previously current MAP is not overwritten, invalidated, or deleted. It remains immutable historical evidence alongside all earlier governed MAPs.

Governed UTC publication identity in the MAP filename continues to determine chronology subject to the already-frozen eligibility and strict monotonic successor-UTC rules. A MAP's derivation from an older state does not create an alternate chronology or override those rules.

For WASM-002, a Diagnostic ID is a stable routing identifier used to connect a diagnostic condition to the Help Engine. The build is required to demonstrate that an applicable diagnostic condition can emit an ID and that the Help Engine can receive and render Help through that ID.

WASM-002 does not require the Council to pre-assign and independently specify the final semantic meaning and polished prose for every Diagnostic ID before implementation.

• When a WASM-002 requirement calls for a diagnostic condition, the implementation emits a Diagnostic ID as required by the diagnostic/Help wiring contract.
• The emitted Diagnostic ID is successfully routed through the Help Engine.
• The Help Engine can render the required WASM-002 Help path, including the already-frozen deterministic fallback behavior where diagnostic-specific Help content is absent.
• Acceptance does not treat the final wording or semantic polish associated with every Diagnostic ID as an independently specified oracle for this build.

The implementation may deliver and use a diagnostic registry containing the Diagnostic IDs and their Help routing information. For WASM-002 this does not compromise QA independence, because acceptance is testing that the required diagnostic/Help plumbing works; it is not using that registry to prove that a separately normative catalogue of final diagnostic semantics is correct.

No duplicate QA-owned diagnostic registry is required for WASM-002, and the PRD does not require a new pass solely to assign a predetermined ID number and final message semantics to every possible diagnostic.

Casual, Office Speak, and Technical are Help presentation voices. Their final prose and semantic polish are not a WASM-002 acceptance deliverable. The Help Engine wiring must support the voice model, but message refinement may occur in a later build.

Where the WASM-002 PRD specifies Help wording or an example Help message at all, Technical is the default voice unless the requirement explicitly states otherwise.

This resolution does not weaken the already-frozen F-17 and F-18 requirements governing diagnostic facts, fallback rendering, and absence-state semantics where those contracts are explicitly required by WASM-002. It narrows F-22 to the question Claude raised: whether every Diagnostic ID and its final semantic message must be independently pre-specified for QA. For WASM-002, they do not.

One diagnostic condition → one stable Diagnostic ID → one Help entry → three explanatory voices.

A diagnostic condition emits one stable Diagnostic ID. That Diagnostic ID identifies one Help entry. The Help entry may provide three human-facing explanations of the same underlying condition: Casual, Office Speak, and Technical. The selected voice changes the explanation; it does not change the Diagnostic ID or the underlying diagnostic condition.

For WASM-002, acceptance verifies the wiring path from diagnostic condition to Diagnostic ID to Help Engine to the selected voice. Final prose and semantic polish for the three voices remain deferred. Where Help wording is specified in the WASM-002 PRD, Technical is the default voice unless explicitly stated otherwise.

F-22 does not remove F-17's structural requirement that a governed diagnostic definition identify the machine facts required to render its Help deterministically. Each Diagnostic ID carried in the implementation registry must therefore declare the required fact set, applicable absence semantics, and Help-routing information needed by the frozen Help model.

For WASM-002, acceptance verifies the generic invariants of that registry and representative diagnostic → ID → Help → voice paths. It does not require an independently authored semantic oracle and bespoke acceptance fixture for every registry entry or every final sentence of Help prose.

The division is therefore: F-17 governs the structure and deterministic fact contract of diagnostics; F-22 limits the depth of semantic/message acceptance required in this build.

During canonical PRD integration, acceptance coverage must be added for substantive WASM-002 behaviors that are frozen but not presently exercised by an acceptance gate. Closely related behaviors may be covered by one coherent acceptance scenario; WASM-002 does not require a separate acceptance gate for every sentence or subclause merely to inflate gate count.

The acceptance suite must nevertheless provide evidence for the material behaviors Claude identified as uncovered, including the applicable CLEAR/RESET alias cases, Receipt-publication failure, governed-name collision/retry behavior, unknown-class preservation/reporting, case-variant governed names, WKO save transaction rollback, embedded Help-catalog safety/no-runtime-fetch behavior, and required Receipt facts for UPDATE ALIASES and INVENTORY where those contracts remain in WASM-002.

WASM-002 may include deterministic test-only seams for conditions that cannot reasonably or reliably be caused on demand through ordinary analyst use. Permitted seam targets include controlled clock values, controlled UUID sequences/collisions, controlled filesystem publication or rename failures, and controlled source-handle/source-substitution conditions needed to exercise frozen acceptance behavior.

A test seam exists to make an otherwise rare or nondeterministic condition reproducible for independent QA. It does not change the product contract for ordinary users.

Test-seam controls must not become an alternate user-accessible Data Sculptor execution path. The release product must not expose test-only fault controls through the Data Sculptor UI, DS-STEPS, Work Orders, URL/query parameters, or another ordinary user-facing product interface.

The implementation may satisfy this boundary by compile-time exclusion, build configuration, isolated harness injection, or another demonstrably inert technique. WASM-002 freezes the behavioral boundary rather than prescribing one implementation mechanism.

• Acceptance evidence must identify which fault/test seam was used for a test case whose condition cannot be produced reliably in ordinary operation.
• The same acceptance evidence must show that the release/user surface does not expose that seam as ordinary product functionality.
• Fault injection must not alter the normative behavior being tested; it supplies only the controlled external condition needed to reach that behavior.
• Independent QA may use the seams to repeat rare failure cases deterministically rather than relying on accidental clock movement, collision, source replacement, or filesystem failure.

The seams are part of testability, not product scope. They allow the implementation and independent QA roles to reproduce the same exceptional conditions without adding hidden ad hoc hooks during testing. This preserves the project's separation between implementation and adversarial acceptance while keeping the analyst-facing product surface clean.

• F-13: user ownership remains intact, while concurrent external mutation during an active governed operation is explicitly outside the single-writer contract; observable invalidation before commit must fail safely.
• F-15: filename/reference matching is exact Unicode scalar-value equality with no case folding, normalization equivalence, or locale-dependent comparison; ambiguous resolution refuses.
• F-20: the 1,024-header limit counts Unicode scalar values; fallback labels have deterministic collision handling; output-writer concurrency is bounded independently of KEEP width and retained as acceptance evidence.
• F-22: F-17 still governs required machine facts and deterministic Help structure; F-22 merely limits WASM-002 semantic/message acceptance to generic invariants and representative wiring paths.

F-14, F-16, F-17, F-18, F-19, F-21, and F-23 were re-read and require no substantive change from today's frozen decisions. F-14's common publication rule does not silently supply missing class-specific grammars; any still-unresolved class-specific obligations remain available to later findings such as F-33 and canonical PRD integration.

When the analyst selects a Suitcase and Data Sculptor successfully validates/certifies it sufficiently to unlock the workspace, Data Sculptor publishes a new governed CER for that opening. A new browser/session opening is therefore intentionally evidenced by a new CER rather than reusing the previous certificate.

The newly published CER is the current standalone CER. Its governed identity is immutable after publication.

WASM-002 permits exactly one governed CER-history ZIP container in a Suitcase. The container is housekeeping packaging for superseded CER evidence; it is not itself the historical event being preserved.

• The current/newest CER remains visible as a standalone governed CER.
• Every older valid CER is historical and may be compacted into the singleton CER-history ZIP.
• Each archived CER retains its original governed filename and exact bytes inside the ZIP.
• The ZIP shall not transform, rename, reserialize, or semantically rewrite an archived CER.
• A CER governed filename shall occur at most once in the history package.
• Archive entries are ordered deterministically by governed CER filename.

The steady-state target after successful compaction is therefore one current standalone CER plus at most one CER-history ZIP.

After a fresh CER is successfully published, Data Sculptor automatically reconciles CER history. If no superseded CER exists, no history ZIP is required. If one or more superseded CERs exist, Data Sculptor constructs a replacement singleton history ZIP containing both the CERs already present in the previous history ZIP, if any, and all superseded standalone CERs that are eligible for archival.

If a prior attempt left multiple superseded standalone CERs visible, a later successful reconciliation may compact all of them in the same deterministic pass.

CER compaction follows the project's All-or-Refuse Publication Discipline. Data Sculptor must completely write and verify the replacement history ZIP before deleting any predecessor history ZIP or any superseded standalone CER.

• Verification must establish the complete expected CER entry set and confirm each archived CER's original governed filename and exact bytes.
• If compaction, verification, replacement, or cleanup cannot complete safely, Data Sculptor deletes no CER evidence. Superseded CERs may remain visible as standalone files until a later successful housekeeping pass.
• If the same governed CER filename is encountered with conflicting bytes, Data Sculptor refuses compaction rather than choosing, overwriting, or deduplicating by guess.

A CER may therefore disappear from standalone visibility only after its exact bytes and original governed filename have been verified in the successfully published singleton history ZIP.

The singleton CER-history ZIP is deliberately replaceable as CER history grows. This is a narrow housekeeping exception to immutable event-artifact identity: the immutable evidence consists of the CER entries preserved inside the package, while the package is the current governed container used to keep that evidence tidy.

WASM-002 shall not create an accumulating chain of historical CER ZIP containers; there is only one current CER-history ZIP.

WASM-002 does not persist the Suitcase directory handle in IndexedDB or another browser-private store between sessions. On a new session, the analyst selects the Suitcase again and grants whatever browser access is required. Data Sculptor then validates/certifies that selected Suitcase, publishes the fresh CER, and performs CER-history reconciliation automatically.

Browser-private state shall not become a second project database or a hidden dependency for understanding the Suitcase.

Theme and Help-voice selections are session-local convenience choices in WASM-002 and reset to their canonical defaults when a new browser session begins. WASM-002 does not introduce IndexedDB, localStorage, or another browser-private persistence mechanism merely to remember those preferences.

A later build may deliberately define a preferences mechanism, but F-24 does not create one implicitly.

Unsaved Work Order drafts are not persistently autosaved in browser-private storage. A modified unsaved draft remains transient session state until the analyst explicitly saves it as a governed WKO.

Where the browser permits, Data Sculptor must warn before ordinary navigation, reload, or tab/window closure would discard a dirty unsaved draft. WASM-002 does not claim that such a warning can be guaranteed for browser crashes, forced process termination, operating-system failure, or power loss.

Claude identified three ambiguities: repeated CER production, whether the browser may remember Suitcase/UI state, and loss of unsaved drafts. The Council deliberately keeps a fresh CER for every successful Suitcase opening, but prevents flat-directory pollution by automatically compacting superseded CERs into one safely replaceable singleton history ZIP while preserving each CER byte-for-byte. The browser remembers no Suitcase handle or UI preferences across sessions, and unsaved drafts are transient with a loss warning where the browser permits it.

The result preserves visible Suitcase truth, keeps certification history, avoids a hidden browser-side project store, and bounds CER clutter without deleting historical evidence.

The canonical WASM-002 small-screen / low-end Windows acceptance host is the project's 11-inch Windows 11 laptop with an Intel N100 processor, 16 GB RAM, and a native 1920×1200 display.

This machine is the required reference host for the WASM-002 small-screen usability and browser-host acceptance path. Stronger machines may provide additional characterization or headroom evidence, but they do not replace the N100 reference host for this build.

Microsoft Edge is the primary WASM-002 browser on the canonical Windows 11 N100 host. Formal WASM-002 browser acceptance uses the current stable Microsoft Edge release installed for the acceptance run.

Edge is the canonical full browser host for the WASM-002 Direct Workspace path, including the browser filesystem capabilities needed by the build when those capabilities are exposed by the host: Suitcase selection, governed reads and writes, CER publication and CER-history compaction, Work Order save/run flows, Help rendering, Receipts/Inventory, conversion, and materialization.

Mozilla Firefox is the secondary WASM-002 browser and the required independent-engine browser characterization host. Formal secondary-browser characterization uses the current stable Firefox release installed for the acceptance run.

Firefox is exercised for the WASM/core behavior and every relevant filesystem/browser capability it actually exposes. A browser-specific API limitation — for example the absence of a Chromium-family direct-directory-write API — is recorded as a host capability difference rather than treated as an analytical failure by itself.

Firefox does not become a second analytical truth oracle merely because it is the secondary browser. Analytical correctness remains governed by the frozen engine/fixture acceptance contracts; Firefox provides required browser-host and independent-engine characterization.

WASM-002 does not freeze a permanently aging Edge or Firefox major-version number into the product architecture. Instead, formal acceptance uses the current stable releases present at the time of that acceptance run and records their exact full version numbers with the retained acceptance evidence.

This preserves historical reproducibility: a later reader can identify exactly which Edge and Firefox builds were exercised without requiring the Product Backlog PRD to be revised merely because either browser publishes a routine stable update.

The retained WASM-002 browser acceptance evidence must identify, at minimum:

• the exact Windows 11 build;
• the exact Microsoft Edge version;
• the exact Mozilla Firefox version;
• the native display resolution used by the N100 reference host;
• Windows display scaling;
• browser zoom;
• the effective browser viewport used for the small-screen test.

The small-screen/keyboard acceptance requirements are then evaluated against that recorded environment rather than an undefined phrase such as “supported host” or “canonical small-screen baseline.”

Chrome, Opera, Safari, mobile browsers, macOS, and Linux are not required WASM-002 acceptance targets merely because Data Sculptor's browser/WASM architecture may later support or characterize them. Testing those environments remains permitted, but F-25 does not make them part of the frozen WASM-002 acceptance baseline.

This is a build-scope decision, not a claim that Data Sculptor is inherently Windows-only or permanently Edge/Firefox-only.

Claude's finding was that the reviewed cut invoked a supported host, canonical low-end Windows laptop, and canonical small-screen baseline without identifying them, leaving UI/browser acceptance unreproducible. The Council now identifies the concrete hardware host, fixes Microsoft Edge as primary and Mozilla Firefox as secondary, defines the role of each browser, and requires the exact runtime/display environment to be retained with acceptance evidence.

The result is reproducible without freezing transient browser major-version numbers into the long-lived product contract.

The WASM-002 SOURCE clause contains one quoted physical filename located directly in the selected Suitcase root. It does not contain a filesystem path.

Examples:

SOURCE "crime.csv"
SOURCE "__DS__CVT__20260926T190000000Z__00000000-0000-4000-8000-000000000000.csv"

User-created subdirectories may exist in the Suitcase, but WASM-002 SOURCE does not address into them.

The following forms are outside the WASM-002 SOURCE grammar and must refuse rather than be normalized, rewritten, searched, or guessed:

• forward-slash or backslash path components, such as data/crime.csv or data\crime.csv;
• .. or other parent-directory traversal;
• absolute paths, drive-letter paths, UNC paths, home-relative paths, or operating-system-specific path forms;
• URLs, URIs, browser-private object references, or external-location references.

The Suitcase boundary is therefore explicit: SOURCE in WASM-002 resolves only against the selected Suitcase root.

A WASM-002 analytical source may be:

• an analyst-owned CSV source file located in the Suitcase root; or
• a successfully published governed CVT artifact in the Suitcase root whose physical serialization is CSV.

The already-frozen F-10 conversion contract remains authoritative for CVT: conversion publishes a governed UTF-8 CSV derivative, and a later Work Order may name that exact physical CVT filename as SOURCE. Using a CVT as source does not create an automatic Store handoff or hidden lineage registration.

WASM-002 does not allow a Store artifact or evidence artifact to become an analytical source merely because it is a visible file in the Suitcase. In particular, RID, COL, MAP, WKO, RCP, INV, CER, HLP, SCR, ZIP/history containers, and other governed non-CVT artifacts are not valid SOURCE targets in this build.

A COL therefore cannot be used as the source of another Store in WASM-002. Store-within-Store source lineage is deliberately not introduced here.

The exact filename/reference-comparison semantics frozen under F-15 apply to SOURCE. Data Sculptor does not case-fold, Unicode-normalize, locale-fold, search nearby files, or substitute a differently spelled filename in an attempt to infer analyst intent.

If the exact governed spelling cannot be resolved unambiguously under the frozen filename rules, Data Sculptor refuses rather than choosing another physical file.

A CSV filename identifies only a candidate physical source form. It is not evidence that the file is analytically valid. Before materialization or other analytical use, the selected source must still pass the ordinary WASM-002 encoding and CSV certification rules, including the frozen UTF-8 / Windows-1252 decision path and CSV grammar.

Renaming malformed, non-CSV, or otherwise uncertifiable bytes to a CSV filename does not make them a valid Data Sculptor source.

Claude identified that the reviewed cut left path separators, parent traversal, absolute paths, subdirectory addressing, governed-artifact sources, and non-CSV sources to implementation choice. The Council now makes the boundary intentionally narrow: one exact root-level physical filename, only analyst-owned CSV or governed CVT CSV as permitted source classes, no path traversal, no subfolder addressing, and no Store-within-Store source reuse through COL or other governed artifacts.

This keeps WASM-002 portable, deterministic, and faithful to the flat visible Suitcase model while preserving the already-frozen ability to use a successfully converted CVT artifact in a later analytical Work Order.

During later PRD integration, the W002-UI-006 phrase editable human alias where applicable is replaced with:

read-only governed alias where applicable

This is a wording correction, not a new capability or a semantic change.

The Suitcase Directory may display the governed alias associated with an artifact where the applicable MAP or registry supplies one. That display is orientation metadata only.

The Directory must not introduce an inline alias editor, a second alias-storage path, or any mutation mechanism that bypasses the governed Work Order / MAP lifecycle already frozen for WASM-002.

W002-UI-019 and W002-UI-024 already establish that aliases shown in the Directory are read-only. F-27 therefore reconciles the stale adjective in W002-UI-006 with the behavior the reviewed contract already enforces.

No syntax, artifact class, publication rule, lifecycle state, diagnostic, or acceptance mechanism is added by this resolution.

Claude identified a wording hazard: one requirement described an alias as editable while two later requirements made the same Directory alias read-only. The Council accepts the read-only model and removes the contradictory adjective.

An implementer therefore has one unambiguous rule: the Suitcase Directory shows governed aliases where available; alias mutation occurs only through the separately governed mechanisms defined elsewhere in WASM-002.

Where an in-scope WASM-002 HTML artifact is described as branded or brandable, later PRD integration must replace that wording with:

uses the canonical built-in Data Sculptor presentation

This applies to the HTML certificate and HTML Help report references identified by Claude. The built-in presentation may visibly identify Data Sculptor / Red5Sorcery; it is not user-configurable branding.

Plain-text governed artifacts such as Inventory TXT are governed by their frozen byte/serialization contracts, not by a visual branding contract. Stale wording such as branded, UTF-8 TXT must therefore lose the branding adjective during PRD integration.

This does not change the Inventory TXT encoding, grammar, provenance, filename identity, or other artifact semantics already frozen elsewhere.

F-28 does not reintroduce Brand Manifest into WASM-002. No configurable brand manifest, theme file, customer logo setting, white-label switch, or presentation override becomes an in-scope requirement through this wording correction.

Any later configurable-branding capability must be specified in its own future scope rather than inferred from the word branded surviving in Revision BL.

Claude identified that Brand Manifest had been deferred while several in-scope requirements still used older branding language. The Council resolves the contradiction by distinguishing fixed built-in product presentation from configurable branding.

HTML artifacts may use the canonical built-in Data Sculptor presentation; TXT artifacts have no branding requirement; configurable branding remains deferred. No new WASM-002 feature, artifact class, syntax, lifecycle, or acceptance mechanism is introduced.

For the integrated PRD, the governing meaning of a requirement continues to come from its requirement ID and its explicit metadata, including SCOPE and STATUS. Moving a requirement beneath a corrected heading does not change its semantics, lifecycle status, build allocation, or acceptance obligation.

A section heading is a navigation and organization device. It must not contradict the requirement metadata beneath it.

During later PRD integration, in-scope WASM-002 requirements must not remain visually nested beneath headings that label them deferred, future-commercial, or otherwise unrelated to their actual subject matter.

The specific extraction artifacts Claude identified — including in-scope UPDATE ALIASES, CLEAR, RESET, the Work Order contract, conversion and Help acceptance gates, WKO identity/MAP/CER requirements, and non-composition acceptance gates — must be placed under headings that accurately describe their current WASM-002 role.

The integrated PRD's section headings must use one coherent, non-duplicated sequence. Out-of-order numbering and duplicate section numbers are removed.

Requirement IDs are not renumbered solely to make the document cosmetically sequential. Their identities are part of the governed project record and remain stable unless a separate explicit requirement-level decision requires otherwise.

No requirement is added, removed, re-scoped, or semantically rewritten merely because headings and section numbers are corrected under F-29.

If later integration exposes a genuine requirement contradiction, missing rule, or scope question, that issue must be handled explicitly rather than hidden inside editorial restructuring.

Claude identified that inherited extraction headings could cause a careful reader to conclude that several in-scope WASM-002 requirements were deferred or belonged to unrelated future-commercial sections. The section numbering was also visibly out of order and duplicated.

The Council resolves that clarity defect by requiring the integrated PRD structure to follow actual requirement scope and subject matter, while preserving requirement metadata and IDs as the authoritative governed record. This is structural cleanup only; it does not change WASM-002 capability.

Claude identified that EVID-W001B-UTF8-003 in W002-ENC-006 stops mid-sentence and runs directly into the next evidence item. During later PRD integration, the complete statement may be restored only from an authoritative preserved source: the official source master or another byte-verifiable predecessor that contains the intact evidence text.

Data Sculptor project records must not complete the missing sentence from context, memory, likely wording, or semantic inference. If the authoritative wording cannot be recovered, the damage remains explicitly unresolved rather than being silently invented.

Where a requirement title is a mechanically split sentence fragment that continues directly into the requirement body, later PRD integration may move text across the title/body boundary to restore a complete, readable presentation.

That editorial repair must preserve the requirement ID, SCOPE, STATUS, normative meaning, and substantive wording. F-30 does not authorize polishing, paraphrasing, shortening, expanding, or otherwise rewriting a requirement merely because its presentation is awkward.

The empty heading Design rationale — why Help is part of the workspace must be checked against the authoritative master during integration.

• If authoritative rationale text exists, restore it faithfully.
• If the authoritative source itself genuinely contains an empty heading, remove the empty heading rather than inventing new rationale during reconciliation.

No new design rationale is authored under F-30.

PRD integration must include a targeted document-integrity sweep for the same class of extraction damage, including:

• abruptly truncated sentences or evidence statements;
• two evidence items or requirement fragments accidentally concatenated;
• empty inherited headings or blocks;
• mechanically split title/body text; and
• other obvious extraction defects of the same kind.

The purpose of this sweep is to identify and restore damaged source text, not to conduct a new semantic rewrite of Revision BL.

If an authoritative intact source cannot be found for damaged text, the integrated record must identify that condition explicitly as unresolved source damage. The missing text must not be silently completed or replaced by a newly authored approximation.

This preserves the project's evidence discipline: where the record is incomplete, the record says it is incomplete.

Claude found a damaged evidence statement, mechanically split requirement titles, and an empty rationale heading. The Council resolves the finding by freezing an evidence-first restoration rule rather than guessing what missing text probably said.

Authoritative preserved text may be restored; presentation boundaries may be repaired; unrecoverable damage remains explicit. No WASM-002 product semantics, scope, requirement identity, or capability are changed by this resolution.

Existing requirement IDs are not renumbered merely to eliminate gaps in a WASM-002 review cut or later integrated PRD. Stable identifiers preserve historical references, QA findings, acceptance evidence, cross-document links, and the audit trail across revisions.

A numbering gap is therefore acceptable when it reflects the authoritative state of the Product Backlog. What is not acceptable is leaving the reason for that gap unknowable from the scoped review record.

The front matter of the WASM-002 cut, and of future scoped QA cuts produced under the same method, must include an Omitted Requirement IDs table covering IDs absent between retained siblings.

For each omitted ID, the table records the authoritative metadata available in the Product Backlog master, at minimum:

• the requirement ID;
• its current SCOPE;
• its current STATUS; and
• where the authoritative master explicitly provides it, the reason for omission or the requirement's destination.

The omitted-ID table must be generated from, or explicitly checked against, the authoritative Product Backlog master. Data Sculptor project records must not infer that a missing ID is out of scope, deferred, retired, superseded, or otherwise non-operative merely because it does not appear in the scoped cut.

If an expected identifier cannot be found in the authoritative source, the cut records that fact explicitly as UNRESOLVED / NOT FOUND IN AUTHORITATIVE SOURCE. It must not silently assign a plausible scope or status.

An omitted requirement remains outside the normative WASM-002 body when its authoritative metadata says it does not belong in the cut. The omitted-ID table is an audit surface only; it does not change scope, status, requirement semantics, implementation obligation, or acceptance obligation.

Likewise, F-31 does not authorize adding missing requirements simply to make numbering continuous.

Future scoped extracts must preserve the same traceability rule so an independent reviewer can tell the difference between an intentional omission and an extraction failure without opening the entire source master.

This keeps scoped review documents compact while preserving a verifiable path back to the authoritative backlog.

Claude identified that the WASM-002 cut skips multiple requirement IDs and that the cut itself does not establish whether those siblings were deliberately excluded or accidentally lost. The Council resolves that audit gap without renumbering the retained requirements.

Stable requirement IDs remain intact, while an authoritative omitted-ID table makes every gap explainable. If authoritative metadata cannot explain an expected ID, the uncertainty remains explicit rather than being guessed away.

MAP is the canonical name of the governed artifact class. The governed physical filename class token remains MAP. WASM-002 does not create new physical artifact classes such as STOREMAP, WKOMAP, or equivalent variants merely to distinguish the profiles.

Capitalization is canonical: MAP, not “Map”.

Store MAP means the MAP profile that governs Store state, including RID lineage, materialized COL bindings, Store aliases, provenance, and the other Store-state facts frozen elsewhere in the WASM-002 contract and this reconciliation log.

When normative prose, acceptance criteria, examples, diagnostics, or Help-related requirements refer specifically to those semantics, they must say Store MAP rather than bare MAP.

WKO MAP means the MAP profile that governs the Work Order registry, including current/deprecated authority and alias-to-WKO bindings under the frozen F-02 lifecycle model.

When normative prose, acceptance criteria, examples, diagnostics, or Help-related requirements refer specifically to that registry profile, they must say WKO MAP rather than bare MAP.

Bare MAP is permitted only when the statement genuinely applies to the artifact class in general or to both MAP profiles. It must not be used where the reader must know whether Store-state semantics or WKO-registry semantics are intended.

This preserves one physical class while making the two logical profiles unambiguous in the specification.

During later PRD integration, WASM-002 normative text retires ambiguous or stale expressions including “Store Map”, “Store / Artifact Map”, and “Store Map/Index” in favor of the canonical terms above.

The Store Index terminology remains retired under the already-frozen F-11 resolution. F-32 is a terminology-normalization decision and must not resurrect the redundant Store Index concept by wording.

Later PRD integration must perform a terminology sweep across normative requirements, acceptance gates, examples, headings, rationale, and Help-related references so the same concept is not renamed differently in different parts of the contract.

This cleanup does not change requirement IDs, governed artifact classes, physical filenames, schemas, scope, status, acceptance obligations, or product semantics. It changes the words used to refer consistently to concepts that are already frozen.

Claude identified terminology drift among “Store Map”, “Store MAP”, “MAP”, “Store / Artifact Map”, and “Store Map/Index”, and noted that bare MAP had become ambiguous because the MAP class now has two profiles.

The Council closes that ambiguity with one linguistic invariant: MAP = artifact class; Store MAP and WKO MAP = profiles. The distinction improves human and LLM readability without creating a new artifact type or changing behavior.

A governed artifact class may remain registered for architectural continuity without being produced by every release. Registration alone does not require WASM-002 to invent a producer, serialization contract, validity contract, lifecycle, or acceptance gate for that class.

If a later build activates a currently reserved class, that build must deliberately define its producer, serialization and validity rules, lifecycle, and acceptance coverage before the class becomes emitted product behavior.

DGN remains a registered/reserved artifact class but is not emitted by WASM-002. WASM-002 therefore defines no standalone DGN artifact producer, serialization contract, or validity contract.

Diagnostics continue through the already-frozen diagnostic, Receipt, Help, and UI mechanisms. Nothing in F-33 creates a second diagnostic-artifact path merely because the DGN class token exists in the registry.

RCV also remains reserved but is not emitted by WASM-002. During later PRD integration, any Revision BL wording that implies WASM-002 creates, promotes, or retains an RCV artifact must be retired or corrected.

F-33 does not reopen the F-14 publication decision. Store candidate publication continues to follow the already-frozen All-or-Refuse publication discipline and any required SCR staging/evidence rules. F-33 simply refuses to manufacture an undefined RCV lifecycle on top of those rules.

If a physical filename has governed Data Sculptor form but its class token is unknown to the current WASM-002 build, Data Sculptor must preserve that file unchanged.

• The file must not be trusted, executed, mutated, deleted, renamed, or interpreted as a known governed artifact merely because its filename has governed form.
• Unknown class does not mean invalid data; it means this build has no authority to interpret that class.
• The presence of an unknown governed class is informational rather than an error merely because the class is unknown.

Whenever a WASM-002 operation performs the governed Suitcase scan/enumeration relevant to an unknown governed-class file, the condition must be surfaced through a canonical INFO diagnostic rather than being silently ignored.

INVENTORY must include the physical file rather than hiding it. Where the Inventory contract carries classification, the file is identified as an unknown/unrecognized governed class without guessing its meaning or assigning it the semantics of a known class.

WASM-002 does not require a Suitcase Directory annotation for this condition because the governed DIR feature is deferred beyond WASM-002. A later DIR implementation may render the same underlying fact; it must not create a second competing truth.

The acceptance coverage already required by F-23 must prove both sides of the unknown-class rule:

• an unknown governed-class file survives the relevant WASM-002 operation byte-for-byte unchanged; and
• the analyst is truthfully informed that the unknown-class file exists through the governed reporting path.

The implementation must not silently discard the file, silently reinterpret it as a known class, or manufacture unsupported semantics from the class token.

Claude identified that DGN was registered with no WASM-002 producer, RCV was referenced without creation mechanics, and PB-STOR-009 required unknown classes to be “reported” without saying where or when.

The Council closes all three ambiguities with one boundary: registered does not mean emitted; unknown does not mean invalid. Reserved classes remain dormant until deliberately specified, while unknown governed-class files are preserved, not interpreted, and reported truthfully.

The vague phrase explicitly permitted run-specific fields is replaced by a closed-world rule. Help may interpolate only facts declared by the applicable governed diagnostic contract plus fields explicitly defined by the governed HLP provenance schema.

There is no open-ended runtime field bag. Help must not pull arbitrary source values, browser state, implementation state, hidden application state, or other available values merely because they exist at render time. This follows the already-frozen F-17 boundary: diagnostics own governed facts; Help renders those facts.

data_sculptor_build must identify the exact Data Sculptor build that produced the governed result. The literal value WASM-002 by itself is insufficient when two materially distinct patch/build artifacts could exist under that milestone.

The same exact build identifier used by the running product must be retained in acceptance evidence so a result can be tied to the tested implementation. WASM-002 freezes uniqueness and reproducibility, not one mandatory identifier syntax: SemVer, a build number, a source revision identifier, or another deterministic scheme may be used if it unambiguously identifies the exact build.

W002-INV-005's optional wording is retired. WASM-002 Inventory must report immediate child directories present at the selected Suitcase root and must not recurse into them.

The deterministic TXT grammar gains DIRECTORY_COUNT followed by contiguous DIRECTORY_001, DIRECTORY_002, and so on after the file entries. Directory names use the already-frozen quoted-text serialization and are ordered by exact ascending UTF-8 filename bytes, consistent with deterministic file ordering.

This is an Inventory fact only. It does not pull the richer governed Suitcase Directory (DIR) feature into WASM-002.

W002-STOR-014's human/LLM-readability intent remains a design and documentation principle, but it does not create a separate public-documentation artifact, publication workflow, or acceptance gate for WASM-002.

Formal public documentation packaging may be defined in later release/V1 work. F-34 does not invent a new governed class or deliverable merely to satisfy wording whose purpose is readability.

WASM-002 must expose a read-only Flight Recorder surface in the browser workspace over the governed Receipt/evidence artifacts already present in the Suitcase.

The UI does not create a second Flight Recorder database, mutable log, hidden cache, or competing history store. The governed artifacts in the Suitcase remain the source of truth; the browser surface provides analyst-readable access to that evidence.

There is no implicit global “current Store.” For a Store-bound operation, current governed context means the explicit Work Order/run plus the exact Store lineage and Store MAP deterministically resolved for that operation under the frozen routing and current-state rules.

For Suitcase-wide operations, the governed context may legitimately be Suitcase-wide. If several Store lineages or branch candidates exist and the operation has not deterministically selected one, Data Sculptor must not guess which lineage “current governed context” means; it must refuse or require the already-defined resolving context.

Governed success/status events such as Work Order saved or Suitcase validated are canonical INFO diagnostics when they participate in the governed Help/status/evidence system.

Ordinary decorative UI copy, labels, headings, tooltips, and explanatory prose do not automatically become diagnostics. The distinction is whether the message represents a governed event/condition with diagnostic identity and facts rather than ordinary interface text.

A run that emits several diagnostics does not automatically publish one HLP artifact per diagnostic. When the analyst requests a Help Report for a run, Data Sculptor publishes one HLP for that report request.

That HLP contains the applicable diagnostics for the run in deterministic order, preserving each diagnostic's own identifier, severity, governed facts, and rendered Help content. A later independent Help Report request may publish a separate successor HLP under the ordinary governed artifact rules.

Governed Help template selection, governed-fact interpolation, fallback behavior, escaping required for artifact correctness/safety, and canonical HLP artifact serialization belong in the shared Rust core.

The browser layer presents the resulting Help content and supplies host-specific UI interaction. It must not become a second, independently interpreted Help-semantics engine. This preserves one semantics across browser and future native surfaces.

Claude's original F-34 note referred to the older implied RID header, but the later frozen Store/cardinality reconciliation now makes the canonical RID header N=<value>.

For N=0, a valid Data Sculptor-authored RID therefore contains the frozen UTF-8 BOM required by the RID serialization contract, followed by exactly N=0, followed by LF, with no data records. In byte-form shorthand:

UTF-8 BOM + N=0\n

The zero-row case is not a separate grammar. It is the ordinary RID serialization with row count zero.

WASM-002 must not hard-code the assumption that CER will always have the longest governed filename. The path-length acceptance fixture must calculate and exercise the maximum physical filename length among every artifact form actually emitted by the WASM-002 build, including any staging/candidate filename form used by the frozen publication contract.

RCV does not participate because F-33 freezes it as reserved-not-emitted. If an emitted SCR/staging form is longer than CER, that emitted form becomes the governing acceptance case. Future emitted classes or filename forms must update the calculation rather than inheriting a stale 73-character assumption.

Claude grouped eleven individually minor ambiguities under F-34 and observed that, together, they distinguish a contract from a strong draft. The Council has now assigned deterministic behavior to each point while respecting the decisions already frozen elsewhere in Pass 1.

The package adds no new analytical operation. It closes residual uncertainty about Help facts, exact build identity, Inventory directories, documentation scope, Flight Recorder presentation, governed context, INFO diagnostics, HLP multiplicity, Help implementation ownership, zero-row RID bytes, and filename/path acceptance.