Verified Frame Worlds

Local applications as deterministic projections of append-only content-addressed histories

Kody Wildfeuer · RapterBox LLC · First public disclosure: August 29, 2026

RAPP paper. This format combines cited technical claims and explicit limitations with embedded proof exercises and copyable prompts that let a reader reproduce or challenge each mechanism using any LLM. The embedded puzzles are explanatory models; the pinned source, executable gates, and live applications are the reduction-to-practice evidence. Conceived and reduced to practice in the browser-based Workroom system. The evidence release is pinned at 2815ba24d9fbeeba247ffd5b8b06f115820e559e and tagged verified-frame-worlds-v1.0.1. The underlying rapp/1 frame protocol and the distributed orchestration methods called frame chains are published separately. © 2026 RapterBox LLC.

Abstract

Most interactive applications keep mutable state as the authority and write an event log beside it. The log can describe what happened, but deleting the state and replaying the log is rarely the operation that reconstructs the product. We present verified frame worlds, an inversion in which an append-only content-addressed frame chain is the sole origin-persisted application record, while boards, rooms, matches, timelines, and exports are deterministic projections of that chain. Recordings are nondeterministic media artifacts associated with explicit frame anchors and byte hashes. The implementation is a static browser application with no application server and no build step. Human and agent actions enter through the same transition validator, and the writer and verifier enforce the same lifecycle rules. The Workroom board atomically commits its current record, per-stream high-water marks, and recent archived dimensions; the smaller Nexus and Arena worlds atomically commit their active stream and preserve rejected bytes separately. Concurrent writers serialize through Web Locks and fail closed when safe exclusion is unavailable. Any verified frame can become the branch point of a new dimension whose genesis names its parent frame.

The architecture was reduced to practice as four connected rapp/1 surfaces—a collaborative Workroom board, its frame-broadcast studio, a shared 3D room, and a first-person arena with causal shot/hit/death frames—plus a comparative three-dimensional heist built on a custom content-addressed snapshot chain. The evaluation deliberately treated green tests as suspects. Mutation checks removed hash validation, disabled rendering, weakened transport, altered provenance, and reintroduced callback-count clocks. Additional probes denied storage, filled the origin quota, corrupted serialized bytes, raced tabs, throttled rendering, cancelled queued work, and supplied valid-but-older chains. The resulting release passes thirteen executable gates from a clean dependency install, uses pinned reference vectors generated by rapp.py and committed as rapp-1-reference-vectors.json, and preserves rejected bytes or the last verified world at every tested failure boundary. The result is a family of local worlds whose state claims can be independently replayed.

1 · Introduction

A conventional interface asks the user to trust a mutable object graph, database row, or server response. An audit log may exist, but it is downstream: it reports what the application says occurred. A verified frame world makes the history upstream. If the current board is deleted, replaying the accepted frames recreates it. If a watcher receives the frames instead of pixels, the watcher can verify and rebuild the same board. If the user stands at frame k, the system can create a new stream whose genesis records that exact parent and re-derive a new world from there.

The central engineering requirement is therefore stronger than “events are stored.” Every mutation surface must obey the same rules as every read surface. A frame accepted by the writer must be accepted by a fresh verifier. A failed persistence operation must publish no state. A stale tab must never erase a newer head. A replay, fork, export, or recording must identify the chain that actually produced what the user saw.

2 · Frame-world model

2.1 One record, many projections

Let F = [f₀, f₁, …, fₙ] be a stream of eleven-key rapp/1 frames [3]. Each frame contains a payload hash, its predecessor's payload hash, and a wave hash over the complete canonical frame pre-image, using the JSON Canonicalization Scheme and SHA-256 [1] [2]. Application state at sequence k is not stored separately:

Pₖ = reduce(F[0..k])

The live world is Pₙ. Replay selects successive prefixes. Scrubbing selects one prefix. A watcher computes the same reducer over a transported copy. The renderer may interpolate between states, but interpolation never enters the chain.

2.2 One transition rule at both doors

Hash validity is necessary but insufficient. A correctly re-hashed frame can still assert an impossible transition: moving a card that was removed, joining outside a room boundary, consuming one shot three times, or declaring death under a different attacker. Verified frame worlds apply one semantic transition function at append time and again during replay. The rule is:

accept(fₙ₊₁) only if
  cryptographic_shape(fₙ₊₁) is valid
  and transition(reduce(F), payload(fₙ₊₁)) is valid
  and atomic_origin_commit(F + fₙ₊₁ | expected_head(F)) succeeds

There is no privileged agent path. Autonomous actors click or call the same append surface as the person. A bot cannot create a world state the human's own write door would refuse.

2.3 Atomic local authority

In the Workroom board implementation, browser storage is one versioned envelope containing the current stream, its frames, per-stream high-water marks, and recent archived dimensions. Mutations serialize in one operation queue and across tabs through Web Locks [9]. The commit compares the stored raw revision and head inside the lock before replacing the Web Storage envelope [7]. If storage is full, the board opens a verified seeded example in a labeled read-only mode rather than presenting an empty world as healthy.

Nexus and Arena use smaller atomic envelopes for the active stream rather than the board's archive and high-water map; recovery quarantine is maintained separately. When storage or safe exclusion is unavailable, they report the limitation and acknowledge no mutation. Across the implementations, malformed bytes are not equivalent to missing data: they are excluded from projection and preserved for recovery rather than overwritten by automatic boot.

2.4 Time travel and dimensions

Because state is a prefix reduction, historical views require no snapshots. A fork from frame k mints a new random stream identifier, records the parent stream, sequence, and wave hash in genesis, then emits fresh frames that re-derive the selected world. The Workroom retains up to eight recent parent streams locally and can return to them after re-verification. Nexus and Arena replace their active local record while retaining child provenance; DOGG Heist branches its custom chain by truncating the abandoned future. In those worlds, export-before-fork is required when the parent must remain locally available.

3 · System

3.1 Workroom

The Workroom is a four-lane collaborative board that opens on real, pre-sealed example chains rather than an empty canvas. People and autonomous agents append the same card events. Rebuild discards the board projection and derives it again from frame zero. Replay animates each accepted transition. The dry run performs work through the public append path, emits one artifact per completed card, and produces a receipt containing the complete independently verifiable chain and artifact hashes.

3.2 Broadcast studio

The Studio transports frames rather than pixels. The local board sends committed frames to its containing studio; optional remote watchers receive them through PeerJS [10], independently validate schema, hashes, lifecycle, stream identity, and per-stream high-water, then rebuild the board with their own reducer. A rejected frame or rollback leaves the last good chain and board intact. Recording produces a WebM and a sidecar of ordered, independently verified stream segments frozen at the stop boundary, while the interface states only that browser downloads were requested because a page cannot prove where the browser saved them.

3.3 Three playable worlds

4 · Adversarial method

The engineering process assumed that a builder cannot reliably see its own blind spots. Separate reviewers owned disjoint surfaces, reproduced failures in Chromium, and were not allowed to edit until their findings were accepted. The governing rules were: inspect the assertion before changing the implementation; measure visible output rather than an intermediate variable; treat an unmeasurable check as failure, not skip; and prove critical assertions can turn red through mutation.

This method mattered. An initially green Arena checker allowed one shot to justify three hits. A Studio test rejected a tampered frame for a broken predecessor while claiming it had tested the payload hash. A Nexus replay check compared the product's reducer with itself. The final review, after every suite was green, still found stale Heist authority, a no-lock Nexus race, a recording sidecar that excluded recorded actions, a valid Studio rollback, a recovery export that discarded corrupt bytes, and an undeclared external dependency in the parity test. Each was reproduced, repaired, and assigned a regression.

5 · Reduction to practice

1. Protocol parity. The shipped JavaScript canonicalizer and hash functions are extracted independently from Workroom, Studio, Nexus, and Arena, then checked against eight committed vectors generated by rapp.py at kody-w/rapp-1@67dacce4f8ce5909aa1fd6dd401d0f8183d730a8. Mutations prove the gate turns red. Gate · vectors
2. Clean installation. A clean directory containing only release 2815ba24d9fbeeba247ffd5b8b06f115820e559e completed npm ci, installed Chromium through Playwright, and passed the complete npm test command without another repository or private symlink. The recorded release environment was Node 25.2.0, Playwright 1.62.1, Chromium 151, and macOS 26.6.2. GitHub Actions then passed the full Chromium gate and Chromium, Firefox, and WebKit smoke jobs for the same commit. CI evidence
3. Thirteen executable gates. The release command runs protocol parity; the board's corruption, seed, replay, playback, artifact, fork, studio, gate, and archive checks; and the Heist, Nexus, and Arena world checks. Command ledger
4. Atomic failure. Controlled write failures, malformed JSON, hash-invalid chains, quota exhaustion, stale tabs, and cancelled queued replacements preserve either the prior verified envelope or the original recovery bytes. Replacement gate · quota gate
5. Concurrency. Barrier-driven two-tab tests show one acknowledged writer and one explicit stale refusal under Web Locks. Where safe exclusion is absent, the affected world acknowledges zero writes. Nexus concurrency · Arena concurrency
6. Causality. Arena frames bind each hit to one exact, unconsumed shot and each death to one exact lethal hit from the same attacker. Re-hashed wrong-target and wrong-attacker mutations are refused. Causality gate
7. Wall-clock behavior. Bounded Chromium smoke tests show the Heist advancing close to ideal elapsed-time ticks under normal execution, 20× CPU throttling, and a 1.5-second main-thread stall. Nexus resident activity remains stable under slowed rendering. Arena's pure movement budget produces identical distance for equal elapsed schedules and caps stalled samples. Heist timing · Arena timing
8. Independent projection. Watcher, Nexus, and Arena tests compare rendered output with independent reducers rather than the production projector. Render-killed and constant-projector mutations fail. Studio oracle
9. Recording provenance. Chain-replacing controls are blocked in single-authority worlds while same-lineage Step/Play may continue. Studio recordings that cross streams preserve ordered verified segments. Sidecars freeze at stop and carry complete chain material, explicit frame boundaries, and the produced video's byte length and SHA-256. Runtime recorder failures emit no success-shaped evidence. Recording gate
10. Responsive operation. Bounded browser checks exercise every public surface at a narrow viewport, while CI boots all five surfaces in Chromium, Firefox, and WebKit. Browser smoke gate

6 · Observed failure classes

7 · Related work and position

The architecture is an application-level use of event sourcing [4], deterministic simulation, content addressing, and tamper-evident append-only logs [8]. Its distinction is the strength of the boundary: the frame history is the primary application record; browser UI, 3D scenes, watcher replicas, and exports are downstream projections, while recordings are observational artifacts bound back to frame anchors. CRDTs provide convergence under concurrent updates [5]; this work instead serializes one stream's authority and represents intentional divergence as a new, explicitly parented dimension. The local ownership goal follows the local-first tradition [6]. The companion Frame Chains paper extends the same substrate to distributed orchestration, succession, re-attachment, and estate-scale homeostasis.

8 · Limitations

• The demonstrated memory streams use sig: null. Content integrity and causal linkage are verified relative to the retained chain and high-water evidence; writer identity is not cryptographically authenticated, and hash linkage alone cannot prevent wholesale replacement when no trusted checkpoint survives.
• Persistence remains browser-origin storage. The tests cover successful and failed Web Storage operations, not process crashes, power loss, browser eviction, profile clearing, or physical durability. Quota exhaustion and blocked storage fail safely, but a read-only fallback is not persistent progress.
• Safe concurrent writing depends on Web Locks in the demonstrated browser implementation. Unsupported browsers fail closed rather than attempting weaker exclusion.
• Remote Studio viewing uses PeerJS signaling. The board and local studio remain static/local; remote rendezvous is not serverless.
• The deep adversarial evaluation is one implementation exercised primarily in Chromium. Chromium, Firefox, and WebKit smoke jobs establish boot-level compatibility, not equivalent behavioral coverage or a long-duration multi-engine scale study.
• The 3D worlds demonstrate frame authority, replay, causality, and failure handling within their tested transition models. They are deliberately small simulations, not general-purpose physics or networking engines.
• DOGG Heist uses the custom dogg-frame-v1 snapshot format. It demonstrates single authority, verified projection, branching, and replay, but is not an implementation of the eleven-key rapp/1 frame shape or its event-transition model.
• Recorded WebM bytes and rendered pixels are not deterministic across browsers, codecs, GPUs, or timing. Their sidecars provide content hashes and frame anchors rather than pixel equivalence.
• Fork provenance is recorded and shape-validated in the child. Independent proof of a parent hash requires access to the parent stream, and only the Workroom retains recent parents for in-app return.

9 · Conclusion

A log becomes an authority only when the application is willing to throw its world away and rebuild from it. Verified frame worlds make that operation testable. The board, watcher, shared room, and arena derive visible state from verified rapp/1 histories; the Heist demonstrates the same authority-and-projection discipline with a custom content-addressed snapshot chain. This arrangement makes replay auditable, fork provenance explicit, corruption non-destructive, recordings attributable to frame boundaries, and autonomous actors subject to the same transition rules as people.

References

1. R. Rundgren, B. Jordan, and S. Erdtman. RFC 8785: JSON Canonicalization Scheme, 2020.
2. National Institute of Standards and Technology. FIPS PUB 180-4: Secure Hash Standard.
3. K. Wildfeuer. rapp/1 specification and reference implementation, rev-6, 2026.
4. M. Fowler. Event Sourcing, 2005.
5. M. Shapiro et al. A Comprehensive Study of Convergent and Commutative Replicated Data Types, 2011.
6. M. Kleppmann et al. Local-first software: You own your data, in spite of the cloud, 2019.
7. WHATWG. Web Storage.
8. B. Schneier and J. Kelsey. Secure Audit Logs to Support Computer Forensics, 1999.
9. Web Incubator Community Group. Web Locks API.
10. PeerJS contributors. PeerJS documentation.
11. K. Wildfeuer. Frame Chains: Self-Healing, Leader-Redundant Orchestration of a Distributed AI Estate, 2026.
12. K. Wildfeuer. Workroom source and executable acceptance gates, release 2815ba2, 2026.