Continuity
In plain words: Blockworld: Recovery after interruption
Where each kind of truth lives (world, app records, mission/action records, volatile adapter state) and how Blockworld reconciles an uncertain action after a crash or restore before continuing.
- 1World state lives on the server; mission cursors and action receipts live in the database (Memory Vault).
- 2One action record survives pauses; deleting a checkpoint cannot delete the action's recovery truth.
- 3On return, missing acknowledgements are resolved first; an unverified effect never grants permission to repeat.
Designed Recovery contract; no live server or deployed mission recovery.
Words on this page, decoded click one for its card
The server accepted a block, but the adapter disappeared before receiving acknowledgement. On return, Blockworld must discover that consequence before advancing or repeating anything. A remembered story and a paused process cannot answer for the world.
Four homes
| Truth | Home |
|---|---|
| Blocks, entities, inventory, game time | Managed world volume and Sentinel journal, or authoritative attached server. |
| Inhabitant, relationships, projects, memory candidates and meaning | Blockworld application records. |
| Mission cursor, budgets, pending work and action receipts | Blockworld mission and action records in Phylactery, bound to the exact RunJob Record and PatternWorkflow revision. |
| Socket, pathing, animation and unacknowledged buffers | Volatile adapter state. |
Boot reconciles server identity, world epoch, Sentinel cursor, bot UUID, and the last receipt before a Mission resumes. Sentinel resolves missing acknowledgement first. An unverified_effect cannot become permission to repeat.
One action across a pause
Revision 2 retains one native action record for the prepared placement. Blockworld owns its meaning and lifecycle; PhylacteryMemory Vault owns its durable schema and transaction boundaries. The record holds the immutable command and disclosure-approved review binding, its ConsentApproval Step identity, issuance disposition, and eventual receipt or exact non-completion. Core's RunJob Record ledger continues to own RunJob Record identity and status. A GraphStep Map checkpoint carries the reference and expected binding; deleting that checkpoint cannot delete the action's recovery truth.
Run and ConsentApproval Step identities remain immutable references in the retained action. Their deletion does not erase the frozen command, review binding, issuance judgment, or recovery disposition. A prepared action whose RunJob Record or ConsentApproval Step is unavailable cannot issue. On re-entry, an action that has acquired its pending claim can only reconcile, including when its checkpoint or Core records are gone. The first bounded placement schema retains mission and action records until a separately owned export or deletion operation exists.
Commit preparation and its one ConsentApproval Step binding together before exposing the review or parking GraphStep Map. Any consumed preauthorization belongs to the same transaction. This gives re-entry one identity to recover: the same native action resolves the committed preparation and ConsentApproval Step, while changed content conflicts instead of replacing them.
Repeated validation of the same call returns those retained records without minting another action. If the commit itself is unconfirmed, reconcile it by that identity before admitting further work.
Before invoking the adapter, conditionally mark the exact action pending against the current mission cursor and limits. Competing resumptions must recover that claim rather than acquire another one for the action or cursor.
The database transaction cannot include the server effect. Once invocation may have begun, a pending or unknown acknowledgement therefore requires reconciliation of the same action. A new GraphStep Map hop or missing reply cannot authorize another placement.
A matching response plus either an authoritative event or sufficient resulting-state proof permits verified settlement. The receipt and its corresponding mission cursor and budget update commit together; repeated settlement returns the same result. An observed adapter invocation, a completed RunJob Record, or the desired block appearing without sufficient attribution cannot manufacture that receipt. Missing proof remains exact non-completion.
Restoration changes the ground
A managed cold backup follows orderly save and stop. Only the MagusYou, the Operator restores a named snapshot; restoration increments the world epoch and invalidates old leases and assumptions. An attached client cannot snapshot or restore the server. It detects external generation change, invalidates leases, and obtains newly attested truth.
Recovery must also check compatibility across independently versioned server, protocol, Sentinel, adapter, controller, PatternWorkflow, and application schemas. Incompatible parked work drains, migrates explicitly, or settles non-complete.
For export or deletion, inventory both application custody and material derived from the world. Deleting a relationship cannot erase a world event from the journal. Restoring the blocks likewise cannot rewrite the purpose for which a mission existed.
Proving return
Use a flat private world, server-enforced 7×7 plot, non-operator bot, controlled chest, and reviewed blueprint. Expose the exact five reads and five effects. Verify placements from Sentinel sequence and final plot diff, then interrupt after accepted placement but before acknowledgement. Recovery must create one receipt and no duplicate block. Repeat against an attached fixture with no console, files, lifecycle, snapshot, or mod capability; unsupported administration must refuse before a request reaches the server.