CADR-WEB-303 ABI 1.2 headless WebAssembly core reimplementation specification

Status and reconstruction claim

Nonclaim: this profile reserves all historical-binary, full-boot, interactive, and hardware-timing compatibility beyond the expressly named M3 gates.

CADR-WEB-303/ABI1.2/M3 is a new, headless WebAssembly hosting profile for the portable System 303 core. It defines a reproducible bare wasm32 module, one dedicated-worker ownership domain, a fixed request protocol, and a native/WASM comparison transcript. It preserves the selected U303 microengine semantics only to the extent proved by the M1/M2 core and this document's conformance gates.

C-M3 is closed for the bounded CADR-WEB-303/ABI1.2/M3 profile. The release record below proves fixed-width ABI1.2 behavior, deterministic CDRSTATE1/2/3 observation, and browser-worker transport compatibility for its declared M3 operations. It does not claim a historical CADR binary interface, a historical browser interface, hardware-cycle or wall-clock identity, a completed disk-controller boot, display, input, persistence, audio, Chaos networking, or compatibility with arbitrary System 303 media. The selected base disk remains an excluded local import. Those stronger compatibility claims are explicitly reserved for later milestones.

Normative language, profile, and evidence

MUST, MUST NOT, SHOULD, and MAY have their usual requirements meanings. They apply to an independent implementation of this reconstruction profile, not to the historical machine. When source and this portable contract differ, the source is evidence for U303; the stated portable rule controls CADR-WEB-303.

The release profile is CADR-WEB-303: LM-3 System 303 source check-in 4df393c68d7f083ce42d5c377039d26043cc18a9031ace28258dc97f4137eb91, selected usim check-in 330d8248ec2e12af071e287920e681600f75df9ffd854aada5f8a64c9adad64d, and the M0 manifest cadr-web-303.json. The manifest's base disk is 269,562,880 bytes with SHA-256 bb16e46ad81decfe1efe691d36b6aa4ce3fd4ffb82474365de3520989d397cb5 and is unresolved-local-import; it MUST NOT enter a public bundle.

Architecture, ownership, and lifecycle

main-thread client -> versioned MessagePort request
                         -> one dedicated worker
                              -> one bare WebAssembly.Module instance
                                   -> one opaque cadr_machine
                                        -> CDRSTATE1 / CDRSTATE2 / CDRSTATE3

The main thread owns module acquisition, transferable byte buffers, and UI policy. The dedicated worker owns the one instantiated module and serializes every request. The module owns the sole cadr_machine; neither JavaScript side may read or write machine structures directly. The core owns guest state, and the M2 state formats remain its only portable continuation boundary. No worker operation accepts a host file handle, callback, pathname, clock, socket, or mutable guest pointer.

The lifecycle is:

UNINSTANTIATED --instantiate--> COLD --verified artifacts--> POWERED
POWERED --boot--> RUNNING --run--> RUNNING
RUNNING --snapshot restore--> RUNNING (fresh replacement)
any well-formed rejected request --> same machine state, next request id,
  except documented artifact-stream abort/discard transitions clear stream scratch
worker termination --> volatile state discarded; it is never reported as saved

instantiate is accepted exactly once. A second well-formed attempt consumes its request identifier and returns CADR_STATUS_INVALID_ARGUMENT; it MUST NOT replace the existing machine. A malformed envelope or a non-monotonic identifier emits cadr-error and MUST NOT consume the expected identifier. A well-formed request, including one rejected by the core, consumes exactly one consecutive positive safe integer identifier in 1..2^31-1.

ABI1.2 module and worker protocol

The ABI major remains 1 and ABI minor is 2. ABI1.2 accepts only records at or above minor 2 for M3 additions; older M1/M2 record validation remains where those operations are used. Fixed-width uint32_t, uint64_t, and byte arrays are the portable C boundary; C structure bytes, pointer values, padding, and host endian layout MUST NOT be serialized or exposed.

Every request is a record {version: 1, id, op, ...}. Every normal reply is {type: "cadr-response", version: 1, id, op, status, ok, ...}; a protocol error is {type: "cadr-error", version: 1, id|null, code, message}. status is the fixed CADR status value, and ok is true exactly for status zero. Inputs are copied into module memory before their operation; response byte arrays are copied out and transferred, so no response aliases live module memory.

request root
├─ instantiate(module: WebAssembly.Module)
├─ input(bytes: ArrayBuffer|view) -> import(artifactKind:u32, byteCount:u32)
├─ stream-begin(artifactKind:u32, byteCount:u64 BigInt)
│  └─ stream-chunk(offset:u64 BigInt, bytes) ... -> stream-finish | stream-abort
├─ cold-power-on -> boot -> run(clockSlots:u32)
│  ├─ boundary-digests
│  ├─ boundary-digests-v3
│  ├─ run-digest-batch(clockSlots: 1..4096)
│  ├─ run-digest-batch-v3(clockSlots: 1..4096)
│  ├─ machine-info
│  ├─ host-next-request
│  ├─ host-complete(operation, hostStatus, generation, requestId, bytes)
│  └─ disk-observation
├─ portability-probe
├─ trace-start(transportMode:u32, capacity:u32,
│              selectorMask:u64 BigInt, eventMask:u64 BigInt)
│  ├─ trace-header | trace-drain | trace-digest
│  ├─ trace-count
│  └─ trace-finish(reason:u32)
└─ snapshot-size -> snapshot-save -> snapshot-restore
   └─ snapshot-restore-import(snapshot bytes)

The request tree is exhaustive for protocol version 1. Unknown operations return INVALID_ARGUMENT. Operations before instantiation return NOT_READY, except instantiate; core lifecycle errors retain their core status. run requires a nonzero u32 budget. The legacy batched form produces zero to 4,096 complete 64-byte digest pairs; run-digest-batch-v3 produces the corresponding 96-byte CDRSTATE1/2/3 records. Neither form pads an incomplete batch. All JavaScript u64 stream, selector, and event-mask fields are BigInt; a Number, negative value, or value above 2^64-1 is rejected before splitting it into low/high u32 words.

Protocol version 1 remains frozen at this exact M3 tree. ABI1.3 media support does not add operations or response fields to it; the separately specified boot-media controller profile uses worker protocol version 2. A version-1 session rejects those M4-only operations with INVALID_ARGUMENT and retains the payload-free host-next-request response shape above.

Streamed artifact verification and failure semantics

ABI1.2 adds streaming only for the selected immutable base disk. It permits that excluded import without requiring a duplicate 269 MB JavaScript/WASM transfer buffer. stream-begin validates ABI, cold lifecycle, inactive stream, inactive trace, kind BASE_DISK, and the manifest byte count. It then creates an internal SHA-256 state, offset zero, and an unpublished artifact stream.

Each chunk MUST be nonempty, at most 1 MiB, start at the exact current offset, and fit within the declared length. The core hashes bytes in order and advances only the stream offset. stream-finish requires exact final length and exact manifest SHA-256; only then does it atomically set base_disk_verified. Out-of-order, overflowing, short-final, hash-mismatched, or failed stream input clears the stream scratch state and leaves every artifact-presence bit unchanged. While a stream is active, power-on, host request issuance, trace start, snapshot save/size, and both boundary digest operations reject rather than observing a half-verified artifact. The worker additionally aborts the core stream before rejecting any malformed offset or transfer larger than 1 MiB. Therefore a protocol-level rejected chunk cannot strand the module in an active-stream state; a new stream-begin may follow. stream-abort exposes the same discard transition for an otherwise well-formed but deliberately abandoned import; it publishes no artifact bytes and permits subsequent snapshot operations on the unchanged machine.

The nonstreamed input plus import path remains limited to 1 MiB, copies bytes into the module, and uses the M1 exact-ingress validation. It does not retain the input after import. An M3 artifact verifier is not a disk controller: it verifies identity only. Disk reads, writes, timing, and persistence are M4/M10 work.

Portable integer and memory contract

The portable core MUST use explicit widths. CADR microinstructions occupy a uint64_t carrier, but every instruction import, control-store write, OA merge, trace field, snapshot field, and exported value MUST mask to 0x0000ffffffffffff. Micro-PC is 14 bits, virtual addresses are masked to their specified 24-bit domain, and arithmetic that represents a 32-bit CADR register uses uint32_t modular arithmetic. Shifts have a validated nonzero count where C would otherwise shift by the width; rotate counts are reduced modulo 32 and a zero count returns its input. Wire fields are explicit little-endian byte sequences.

The portable reconstruction MUST NOT depend on signed overflow, implementation- defined right shift of a negative value, host long, time_t, off_t, pointer width, alignment, or C structure padding. It uses raw two's-complement bit patterns for signed ordering and magnitude, widened int64_t only where the result is representable, and unsigned comparisons for defined wrap/borrow behavior.

CDRSTATE transcript, trace, and snapshot bridge

At every requested outer clock-slot boundary, the M3 runner records exactly 96 bytes: CDRSTATE1[32] || CDRSTATE2[32] || CDRSTATE3[32]. CDRSTATE1 is the frozen M1 canonical boundary digest; CDRSTATE2 is the byte-stable ABI1.1 continuation digest with derived Merkle caches rebuilt as necessary. CDRSTATE3 is the ABI1.2 domain-separated digest of that exact CDRSTATE2 value plus every M4-D0 disk semantic field. Introducing disk state MUST NOT silently change CDRSTATE2 schema 1. None of the three is a raw C-state hash.

CDRM3TR1 is an evidence transcript, not a historical or general trace format:

32-byte header: magic, record_bytes=96, expected_count=slots+1, requested_slots
96-byte records: S0 through S<slots>, CDRSTATE1 then CDRSTATE2 then CDRSTATE3
32-byte footer: magic, actual_count, terminal_status=OK

The comparator MUST validate both framing/count equations and terminal status before comparing byte-for-byte. It reports the first unequal S<n> and whether CDRSTATE1, CDRSTATE2, or CDRSTATE3 differs. It MUST NOT trust file length alone. The native runner and worker runner start from the same verified artifacts, write S0 after boot, then write one pair after each one-slot run. A requested complete transcript has exactly slots + 1 records.

The maintained-usim oracle does not use the portable continuation-digest schemas: its CDRSTATE1 includes live tree and device roots that the M1 portable profile freezes, and it has no CDRSTATE2 or CDRSTATE3. M3-P2 therefore MUST NOT compare those opaque hashes or describe self-parity as an upstream oracle. It uses three separate, explicitly adapted streams:

• CDRM3AD1 contains one SHA-256 projection for every S0 through S1,000,000. Its preimage is the domain CDRM3AD1\0, schema, S ordinal, executed/inhibited phase, and the exact 60 common scalar tags already defined by the pinned native oracle. Each tag carries its explicit four- or eight-byte width; 48-bit words are masked and booleans are normalized.
• CDRM3BUS1 contains every guest physical-word read or write in order, with its post-slot S, intra-slot sequence, address, input or result, and resulting bus error and interrupt latches.
• CDRM3DISK1 contains every disk-register access and controller action in order, including full controller/selected-unit state and an explicit assert/deassert/request/block/completion disposition.

The two implementations emit these through observational, native-only hooks. They are absent from the public ABI and bare Wasm module. A release gate MUST prove the hooks leave the preexisting boundary/mutation witnesses unchanged, validate contiguous S ordinals and canonical framing, compare typed event fields, and reject a deliberate scalar or event perturbation at its first S/sequence. An empty request/block/completion stream is accepted only when both sides emit the stream metadata and the gate pins the observed zero counts.

If a one-slot call applies an already queued host completion it reports zero guest slots and OK; this is a valid between-slot transition and MUST NOT consume a batch budget or emit a boundary record. The worker continues until it obtains one guest slot or a terminal status. If the slot completed and the same call also reports a terminal condition, its completed boundary is retained once and the batch then stops.

M2 CDRGTRC1 and CDRSNAP1 cross the ABI1.2 boundary through the worker's trace/snapshot leaves. Trace outputs are copied out in at-most-1 MiB chunks; snapshot save copies its exact byte count out, and restore-import copies exact input bytes into a separately allocated region before fresh atomic restore. A snapshot restore creates a fresh core machine and replaces the module's old pointer only after cadr_machine_snapshot_restore succeeds; on failure the old machine remains usable, its allocator transaction is rolled back, and a corrected snapshot may be retried. Tests MUST exercise multiple late, internally checksummed failures before a valid restore, rather than relying only on a trivially truncated input. At most one restore may succeed in one module lifetime; later restore attempts return NOT_READY, preventing the monotonic allocator from exceeding the stated bound. M3 does not redefine M2 record ordering, terminal rules, or state-cache validation.

Legacy CDRSNAP1 format minor 0 remains byte-stable and is legal only when the disk is in its implied canonical quiescent default; an ABI1.1 save MUST reject a nondefault disk rather than omit it. An ABI1.2 snapshot uses CDRSNAP1 format minor 1 and a required type-9 disk chunk carrying the disk semantic fields and their CDRSTATE3 witness. A minor-0 restore constructs the documented default disk state; a minor-1 restore validates and publishes the decoded disk state atomically with the rest of the replacement machine.

Exact startup bus prefix and M4-D0 dependency

The selected System 303 startup performs a read and, two clock slots later, a zero-valued write at physical word address 017377400. A direct maintained-usim debugger observation found them at raw pre-execution machine_cycles 505,068 and 505,070, hence post-slot boundaries S505069 and S505071. In a CDRM3TR1 file, which also contains S0, their completed record counts are 505,070 and 505,072; those counts are not boundary ordinals. Pinned bus-adaptor.c identifies both exact accesses as the extra page-zero parity location made by PAGE-0-PARITY-FIX, suppresses both warnings in a release build, returns zero for the read, and ignores the write. ABI1.2 therefore returns 0/OK for a guarded read and OK for a guarded write of exactly 017377400, emits no external-device event, and sets the Xbus-NXM error latch just as the pinned bus adaptor does. Apart from the exact source-defined startup controls and M4-D0 operations named below, unimplemented bus addresses remain fail-closed with UNIMPLEMENTED_DEVICE; this exception neither activates the disk controller nor broadens the device compatibility claim.

The next observed native operations are not optional probes. At raw cycle 505,074 the PROM writes 04 to physical 017773005, mapped to diagnostic Unibus register 0766012; at raw cycle 505,078 it reads disk status at physical 017377774. The corresponding post-slot boundaries are S505075 and S505079, and the first disk START write occurs at raw cycle 505,198/post-slot S505199. The first command is 0405 (at-ease plus fault-clear), so that START itself performs no media transfer, but it requires real disk register and controller-state semantics. A processor-only M3 therefore cannot honestly reach S1,000,000.

M4-D0 names the minimum forward slice of M4 required to close M3: every actual disk register read and write, command-5 action, encoded status result, and interrupt-deassert attempt exercised through S1,000,000. The observed prefix has seven disk-register reads, nine writes, two deassert attempts, no interrupt assertion, and no CCW, DMA, media request, block, or completion. Those zero counts are negative reachability evidence, not validation of the implemented media path. This is an explicit forward dependency, not permission to replace the boot fixture with a synthetic processor loop. CCW walking, DMA, range service, writable-overlay semantics, and completion timing remain M4 work. Full M4 is reserved pending a separately declared C-M4-BOOT-MEDIA gate and later C-LMFS-MOUNT overlay profile; it is not coupled to a host filesystem mount.

Required conformance and release evidence

U01 through U05 are source-grounded vectors, not a proof that the maintained System 303 runtime loaded every same source body. The M1 regression and million slot gate compare outer clock slots, including inhibited slots, rather than treating every slot as a retired microinstruction. The million gate is the M3 boundary gate; the M1 regression remains mandatory because it ties the new larger run to the already frozen native witness.

python3 scripts/compare-cadr-m3-upstream-adapter.py build/cadr-oracle/m3-p2-upstream-s1000000-det-a/adapter.cdrm3ad1 build/cadr-m3-p2-portable-s1000000/adapter.cdrm3ad1 build/cadr-oracle/m3-p2-upstream-s1000000-det-a/bus.cdrm3bus1.ndjson build/cadr-m3-p2-portable-s1000000/bus.cdrm3bus1.ndjson build/cadr-oracle/m3-p2-upstream-s1000000-det-a/disk.cdrm3disk1.ndjson build/cadr-m3-p2-portable-s1000000/disk.cdrm3disk1.ndjson --expected-slots 1000000

Reproducible build and comparison procedure

The tracked build script requires Guix channel 230aa373f315f247852ee07dff34146e9b480aec, Clang 21.1.5, and LLD 21.1.5. It compiles the explicit freestanding source closure with --target=wasm32-unknown- unknown, -nostdlib, no entry point, exported memory, fixed 128 MiB memory, and only the declared adapter exports. The build MUST be invoked separately for O0 and O2. Determinism is assessed per same optimization level; this specification does not require O0 and O2 module bytes to be identical.

1. Verify the M0 profile and local artifact identities; make a disposable output location without copying licensed payload into version control.
2. Build native cadr_m3_native, O0 wasm, and O2 wasm from the declared source closure.
3. Run U01--U05 natively and retain their pass/fail output.
4. Produce native and worker CDRM3TR1 transcripts with identical inputs and slot count; compare them with compare-cadr-m3-transcripts.py.
5. Repeat for M1's 100,000 slots, then the one-million-slot gate, and repeat the relevant comparison under O0 and O2.
6. Run trace/snapshot cross-target checks, reproducible-build/export/import audit, Node worker tests, and the Chromium smoke under a local HTTP server.
7. Store only aggregate hashes/results in tracked documentation. Keep disks, transcripts containing guest state, and raw browser data in ignored build trees.

Known unknowns and nonclaims

• TODO-RUNTIME-M3-MEDIA: M3 executes the selected startup disk-register and command-5 prefix, but that prefix reaches no CCW, DMA, block service, filesystem, or Listener. Synthetic media-path tests do not substitute for the M4 boot-media oracle.
• TODO-RUNTIME-M3-RESOURCE: the static proof bounds the declared operation sequence, but a later browser profile should also retain measured high-water evidence; the fixed M3 limits are not a user-facing capacity guarantee.
• TODO-RUNTIME-M3-BROWSER-MATRIX: one Chromium smoke is a transport probe, not a browser compatibility matrix or an accessibility/interactive test.
• The exact current checkout's administrative Git identifier is not substituted for the profile's asserted Fossil pins. A fresh source-identity verification remains part of release evidence.
• The headless profile has no application keybinding tree or pointer gestures; M8 and M9 own their future guest-input inventory. The worker request tree above is host protocol, not a historical CADR user interface.

Artifact identities and rights boundary

Sources

• CADR browser/WebAssembly roadmap, M0--M3.
• System 303 macroinstruction and microarchitecture specification, selected U303 profile.
• Native CADR instruction-boundary oracle design.
• ABI1.1 deterministic tracing and snapshot specification.
• Pinned usim m32.h lines 3--20 and uexec.c lines 51--57, 541--705, inspected 2026-07-28.
• Tracked M3 build, worker, adapter, transcript comparator, and tests, inspected 2026-07-28.