Skip to content
Dead Water In development
Back to the devlog
Pre-production by Kit

What the region saw about you

The shared-propagation step for patrol evidence started with a refusal: uploaded solo reports are not region truth. So the region now keeps its own facts instead. When the authoritative region simulation begins pursuing your hull, that pursuit records itself into your own captain archive, server-side, and survives process death.

The design review for C9’s propagation step landed blunt: letting a client upload its solo patrol reports and calling them region evidence would launder untrusted assertions across the solo and account realm boundary. Uploading your own diary about me does not make it my history. So the honest minimal slice is smaller, and it is real.

The region already runs an authoritative patrol simulation. When it genuinely begins pursuing an account’s hull, that pursuit-start edge now records itself into that captain’s own retained store. The bytes go through the exact production queue the solo archive uses, so the receipts, revision monotonicity, rotation and vault guarantees are the same audited contract, not a parallel simplified one. Every identity in the record is bound to the account realm from server context. Nothing on this path reads a client payload, and no client can browse, acknowledge or influence these stores yet.

Each captain gets a delivery watermark: a packed pair of rotation count and revision, persisted durably. The rotation half matters because rotation restarts the live revision at zero, so a notice acknowledged by plain revision alone could be faked or hidden by a store rotating underneath it. An ack that claims progress ahead of the truth refuses. A regressing ack is kept as history but never clears pending progress. And a store that cannot be opened is treated as unknown, never as delivered.

The verification loop earned its keep twice. First, the roster trap: crews are pairs and share one hull, so “the second captain” in the fixture was actually the first captain’s own crewmate, and his record was landing in the wrong archive. The fixture now keys on each vessel’s owning account, and cross-captain isolation became a real assertion instead of an accident. Second, and better: service reads consulted a lazily-opened queue dictionary, so a restarted region server judged watermarks that had never been loaded, vacuously passing, and a killed run’s pending journal was never replayed. Every read now goes through one opening seam that seeds the watermark and completes unfinished writes first. That one was a product bug, not a fixture bug, and the restart test caught it.

Verification is a native two-round scenario on private six-account worlds: record legs, the full watermark ladder, hard process exit, then a fresh process that must restore both the durable watermarks and the rows themselves through the owner-gated read seam. A clean two-round cohort ran green on the final binary with seven processes each, and an independent Node audit re-derived the round-two stores from raw bytes: graph counts, realm and owner pinning, both durable watermarks, no stray accounts. Full tooling stayed at 2,504. Failed attempts are retained on disk, each one the diagnostic that fixed the next bug.

What this is not, yet: no notice travels the wire to an online captain in this increment, no captain sees another captain’s archive, no case outcomes, no deletion. Delivery of the bounded notice over the authenticated connection is the next increment. The region just keeps very careful notes about you in the meantime, and it can prove them after a crash.

No storefront, no wishlist button

Follow the build

We email when something real happens, which is rarely. The devlog covers the rest.

We will not sell your address, and this list is for the game only. No trading talk, no price talk. If we ever break that, unsubscribe and tell us why.