Operations and recovery

An operator must preserve scientific identities, durable ordering, private archives and financial uniqueness across deployments. A new binary or website does not justify an empty database, new signing identity or discarded cache.

Readiness and trust#

Verify the expected source revision, public deployment identity and signed readiness before linking a frontend to a service. Match exact HTTPS origins in CSP/CORS. Keep authority, wallet gateway and query services behind their reviewed process and proxy boundaries.

A health response proves the tested service is reachable. It does not prove complete-model computation, wallet extension compatibility or a physical-device performance claim.

Validation participants maintain separate worker identities and complete-model runtimes. Operations check model hashes, signed reports, transport health, durable task state and recovery behavior for each participant.

Persistent state#

Maintain separate external persistent locations for model files, authority SQLite/WAL, private signing configuration, candidate/replay archives and public projection. Keep customer inputs and signed financial journals private.

The browser's saved state is a separate domain. Do not replace the model, OPFS results or browser profile when publishing a new interface. History views and retained resources should remain usable after a stage is complete.

Coherent backup and restore#

For a coherent authority snapshot, stop writers or use the reviewed consistent snapshot method and preserve database, WAL, objects, configuration and identities from the same point. Copying only a live SQLite main file is insufficient.

Read back the backup, verify its checksum and restore into a separate private location first. Check task/claim/winner counts, archive roots, beneficiary/payment uniqueness and projection consistency on loopback before using it as a live restore.

Historical backup, restart and old-binary rollback checks have passed. The full snapshot disaster-recovery drill remains outstanding and should not be described as completed.

Scoped website deployment#

Build a distinct complete release from reviewed source. Validate the full retained atlas, all routes and assets, CSP, compression and file manifest. Record the remote baseline and changed-file hashes, archive replaced files, then deploy only the verified changes.

The documentation release does not require a new model download, database reset, token issuance or financial transaction. Static pages and local search are independent of those stateful operations.

Financial reconciliation#

Keep accepted liabilities and signed transport durable. If RPC becomes unavailable, retain trusted finalized evidence. Scientific completion must not terminate reconciliation of an accepted payment.

Read permanent unit/intent state, actual transaction history and recipient evidence together. Unknown is a state to reconcile, not a reason to release the same budget twice. Never recreate the existing mint or repeat initialization/adoption to repair a read fault.

Future funding and capacity#

Each rewarded stage uses calibrated goals, prospective budget reservation and reviewed admission. Queue capacity, archive retention and measured cost determine its operating limits. The live task manifest identifies currently available work.

Mainnet, production payments and formal emission remain inactive. Full operating agreements, asset identities, authorities, finite budgets, security review and actual acceptance must precede their activation.