# Local node prototype, schema 1

## Inspected baseline

The September 29 deployed release is a self contained Cloudflare public Worker with no storage bindings. Source was supplied as a release directory, not a Git repository. The homepage is frozen for this phase. Browser code performs all record operations. The Worker delivers public HTML and JavaScript; it does not receive record payloads. The separate Continuity Field is a scripted localStorage demonstration, not a network.

The existing record store is IndexedDB `arkosom-local-record-v1`, object store `records`, key `document`. A single readwrite transaction compares the expected snapshot before replacement, preventing lost updates between tabs. Record schema 1 has ordered versions, sequence, previous fingerprint, kind, device timestamp, text and SHA256 fingerprint. Deletion leaves time and count. Six record tests plus other model, route, offline and editorial tests comprise the 22 test baseline. JC-001 also has a separately executable parent process evidence fixture.

## Smallest architecture

DESIGNED: portable model -> compare and swap persistence adapter -> simple Preserve / Ask / Verify interface. This phase retains IndexedDB and its database name so migration is an atomic replacement, never a second retained payload copy. It wraps the existing unchanged version chain in a versioned node snapshot. The browser node is an implementable layer for a future native storage adapter, not a claim of filesystem durability.

The logical Node ID is a random UUID, not a hardware serial, person, owner, signing key or authorization. Record ID is another UUID. No owner identity is collected. Restoring a transfer retains its logical Node ID; simultaneous restored copies are clones, not independently identified peers. No synchronization or reconciliation is implemented. A future transport must carry a node ID, record ID, expected head and explicit authority decision and must not silently merge or overwrite.

## Open transfer format

UTF8 JSON, `format: org.arkosom.local-node`, `schema: 1`. Fields are `nodeId`, `createdAt`, `recordId`, `source`, `record`, and `fingerprint`. The embedded record retains schema 1. Unknown keys and versions are rejected. Source is a bounded description of the capture mechanism, never a verified author. Migration labels existing history as legacy browser content. Existing version fingerprints are preserved exactly.

The node fingerprint is lowercase SHA256 of canonical JSON of all other fields. Canonicalization recursively sorts object keys using JavaScript default string sorting, preserves array order and uses JSON.stringify encoding without whitespace. Version fingerprints retain the historical algorithm: SHA256 of JSON.stringify({sequence,previous,kind,time,text}), in that property order. Hashes use UTF8. Verification status is recalculated, not imported as authority. A matching snapshot detects uncoordinated metadata edits and chain truncation, but an attacker can recompute it.

Import has a 16 MB byte limit, strict field validation and full snapshot plus chain verification before any write. It is available only on an unused node with no saved versions or deletion receipt. Restoring into a clean profile explicitly resumes the exported logical node. Import never replaces a used node. A malformed or conflicting import leaves current storage unchanged. Export requires successful verification and contains retained state only. It is not encrypted.

Deletion replaces the entire snapshot atomically, removes all text and old version hashes, rotates the record ID and source, retains logical node identity and only the existing minimal time/count receipt about removed content. No old record ID, source, content digest or hidden archive is retained. A later preserve starts a new chain. Import into a node with a deletion receipt is blocked, including old backups. A fresh profile cannot know about deletion in another profile: old exports, browser backups and other copies remain outside this policy. No physical erasure is claimed.

## Platform and security boundary

IndexedDB commit and reopen are the supported browser persistence boundary. Transactions request strict durability where supported, with a compatibility fallback. Browser storage persistence can be requested by an explicit user action, but a grant does not guarantee survival of profile deletion, device loss, storage faults or compromise. No filesystem fsync, crash recovery, encrypted vault or backup guarantee is claimed. Offline delivery remains the existing service worker public cache. Initial delivery and updates require network access. Once cached, the local loop requires no central account or Arkosom storage service.

Show the Record displays all retained versions, transitions, timestamps, provenance, record/node IDs and current verification evidence. Ask remains deterministic text comparison. Capabilities confer no permission. Anyone controlling this origin, browser profile or host can read data, alter history and recompute every digest. There is no trusted timestamp, signature, external witness or rollback anchor. User deletion can remove evidence; that is deliberate.

NOT YET PROVEN: native database durability, power loss recovery, physical erasure, cross browser persistence guarantees, malicious host resistance, independent author attribution, device ownership transfer, multiple node synchronization and reconciliation. Blututh integration requires a native persistence adapter and explicit permission model using this portable format; no OS is built here.

## Deployment and evidence

The build embeds static assets and a revisioned offline cache in the existing Worker. Deployment must preserve its bindings, compatibility settings and rollback version, and compare production responses with the locally tested build. Record data never enters the deployment package. Test outcomes are recorded separately after execution; the design above is not test evidence.