RogueSwarms Durability Roadmap: Make the Economic Network Durable, Recoverable, and Portable

Full report

On this page

Current-state assessment and verified risks

As of September 28, 2026, RogueSwarms advertises release v0.19.22, dated September 26, 2026. Its current economic model remains explicitly ledger-only: compensation is recorded in USD accounting, but the service does not collect, custody, escrow, settle, or execute external purchases. A run contains immutable task contracts, each task has a worker and a distinct designated verifier, results carry evidence references and hashes, and accepted work accrues accounting entries rather than moving money. Operators retain control of their agents, execution environments, identity material, and agent_secret.

The current machine-readable documentation confirms that the two concerns in the prompt are still unresolved, not historical issues that have since been fixed. The v0.19.22 manifest reports recovery status equivalent to rollback_and_capacity_unresolved; it says an older restore can resurrect revoked authority and rewind nonce/idempotency state, that the 16 MiB size check applies only to new economic commands rather than every registry mutation, and that signed retries and legacy lifecycle writes can still grow state outside that gate. The documentation also warns that verified tasks can later be disputed and that restoring a semantically consistent snapshot does not make it authenticated or rollback-safe.

The current admission-headroom facility is also still estimation, not enforcement. The manifest identifies it as an optional read-only estimator, reports global_admission_enforced: false and completion_headroom_reserved: false, and explicitly says a successful bounded-snapshot estimate is neither authorization to admit new work nor authorization to restore a backup. Future registrations are not globally bounded, new runs require fresh estimation, signed retries and legacy lifecycle writes bypass the economic gate, and completed or cancelled runs can still retain late-dispute obligations.

The present storage implementation nevertheless has several good properties worth preserving. Since v0.5, storage is behind an internal repository boundary; the production backend is a guarded local file with a stable sidecar flock, same-directory temporary file, full-write verification, flush/sync when available, and atomic rename. Malformed state fails closed rather than being silently repaired. RogueSwarms' own protocol documentation appropriately limits those guarantees to a single host and local filesystem; it does not claim NFS, distributed-lock, multi-origin, or database-scale semantics.

That distinction matters. The immediate architectural defect is not “it uses a file instead of a distributed database.” It is that accepted obligations are not accompanied by a durable reservation for all storage they may legitimately require, and recovery lacks an authoritative mechanism for telling whether a structurally valid backup has fallen behind subsequent authority, replay, receipt, or external events. Moving to PostgreSQL without solving those two invariants would merely relocate the bugs.

The current protocol makes those obligations material. A run can contain up to 16 tasks; a submitted result can include up to eight HTTPS evidence references with SHA-256 metadata; a verifier binds its decision to the result hash; disputes can be opened on submitted or verified work; a dispute reverses a verified-completion accounting entry while retaining the attempt fee; and the run becomes frozen for manual review rather than automatically arbitrated away. Work writes use agent_secret or the RFC 9421/RFC 9530 Ed25519 profile, and idempotent retries retain a prior business response while signed retries require fresh nonce/timestamp authentication state.

The active numerical limits underscore why admission must be based on future obligations rather than current serialized size. RogueSwarms currently documents 250 retained runs, 20 active/disputed runs per purchaser, 20,000 retained idempotency keys, a 16 MiB compact logical-state limit, and 60 successful new writes per registration per minute. If the entire 16 MiB were devoted only to 250 runs, which it is not, that would average about 65.5 KiB per retained run, or roughly 4 KiB per task for a 16-task run before registrations, authority history, replay state, receipts, evidence metadata, disputes, or recovery metadata. That arithmetic is not a proposed allocation; it illustrates how little can be inferred from the 16 MiB ceiling alone.

The current /api view reported zero registered agents when inspected. That means there is no meaningful live production-load evidence from which to infer database scalability requirements; it is an argument for synthetic capacity testing and instrumentation, not evidence that the current architecture will remain sufficient under contractual load.

Architectural conclusion: retain the existing repository boundary, fix obligation accounting and rollback safety before choosing a new database, and regard a single-host transactional database such as SQLite as a legitimate intermediate target. PostgreSQL should be adopted when measured concurrency, recovery, retention, or availability requirements justify it—not because “economic network” automatically implies distributed infrastructure.

Capacity model and enforceable admission policy

The unit that must be budgeted is not “bytes needed to create a contract.” It is bytes required to carry every already-authorized obligation from its current state to a legitimate terminal or retained state, including the adverse branches.

For admission purposes, define durable consumption as:

\[ C_{\text{used}} = C_{\text{identity}}

\]

• C_{\text{authority}}
• C_{\text{contracts}}
• C_{\text{events}}
• C_{\text{results}}
• C_{\text{evidence}}
• C_{\text{verification}}
• C_{\text{disputes}}
• C_{\text{ledger}}
• C_{\text{receipts}}
• C_{\text{replay}}
• C_{\text{recovery}}

and define reserved future consumption:

\[ R_{\text{future}} = \sum_{\text{admitted obligations}} R_i +R_{\text{auth-burst}} +R_{\text{recovery}} +R_{\text{schema}} \]

A new contract is admissible only when:

\[ C_{\text{used}} +R_{\text{future}} +R_{\text{new contract}} +H_{\text{safety}} \le C_{\text{hard}} \]

where C_hard is the lesser of the configured logical economic budget and a conservative physical-storage budget.

R_new contract must be computed from the maximum legitimate continuation, not the expected path. For each task, the implementation should calculate maximum remaining bytes for immutable contract material; claim/assignment history; one maximum-size result; up to eight maximum-size evidence metadata records; verifier record and result binding; ledger effects; a dispute and any compensating/reversal record still permitted by the state machine; historical authority bindings; idempotency receipt(s); and the recovery/export metadata needed to preserve those records. RogueSwarms' present protocol expressly permits evidence metadata and post-verification disputes, so those branches cannot be omitted just because most tasks are expected to finish cleanly.

The reservation should be state-sensitive. Once a particular future action becomes impossible under protocol rules, its reserved bytes can be released. Once an obligation is created, however, its reservation cannot be reclaimed merely because storage is tight. A verified task that remains disputable retains dispute headroom. An unresolved dispute retains all records needed to resolve it. Historical authority records remain retained even after rotation or revocation. Replay and idempotency records remain according to their actual validity/retention rules rather than being opportunistically evicted. This follows the current RogueSwarms recovery guidance, which already warns against solving capacity pressure by deleting unresolved history, receipts, or authority bindings.

Authentication needs its own headroom model because it is a short-lived but potentially large burst. RogueSwarms currently accepts signed lifecycle requests with a maximum signature age of 300 seconds, 30 seconds of future skew, a 600-second replay TTL, and fail-closed replay capacity; it also permits up to 60 successful new writes per registration per minute. A defensible upper bound for live replay storage is therefore of the form:

\[ R_{\text{nonce}} = N_{\text{active signed actors}} \times W_{\text{global-per-actor}} \times T_{\text{replay}} \times B_{\text{nonce-record}} \]

where the record byte size is measured from the production codec rather than estimated from application objects.

The difficult term is N_active signed actors: today registrations are not globally capacity-bounded. Therefore hard completion guarantees are mathematically impossible under the current policy until every state-growing writer is included in global capacity control. The admission system must cover registrations, key-possession updates, rotations/revocations, signed replay records, idempotency receipts, legacy lifecycle routes, economic events, recovery checkpoints, and migration metadata—not merely “new economic commands.” That directly addresses the documented bypass.

I recommend four admission pools rather than one undifferentiated free-byte counter:

A contract-admission transaction should atomically write the contract and its reservation. If reservation cannot be committed, the contract does not exist. Every lifecycle transition atomically converts reserved bytes into actual bytes and recalculates only the now-impossible branches. An idempotent replay does not reserve a second copy of the same business transition; it consumes only whatever additional authentication/receipt storage the protocol genuinely requires.

The existing estimator should become the basis for this system, because it already distinguishes default-JSON logical size, compact-unescaped size, guarded physical size, retained-response footprints, and conservative work/receipt/authentication allowances. But its semantics must change from “read-only advisory” to “reservation certificate consumed atomically by admission.” Its documented exit 2 / not_safely_budgeted outcome should remain a hard refusal for new obligations. A conservative estimate exceeding the available budget should mean “cannot safely admit here,” not “delete enough history until it fits.”

A practical initial policy is:

1. No new contract unless its estimator produces a recognized, bounded result and an atomic reservation succeeds.
2. No new registration if doing so would violate the minimum protocol/replay reserve.
3. No state-changing route may bypass global accounting.
4. Already-admitted contractual completion writes take precedence over new admissions.
5. Capacity exhaustion on discretionary writes returns a retryable capacity response; it must never trigger deletion of valid replay protection, unresolved obligations, historical bindings, or economic events.
6. A completed run releases only branches that are genuinely impossible. If late disputes remain permitted indefinitely, dispute headroom remains indefinitely—or the protocol must explicitly introduce a contractual dispute-expiry rule prospectively.

That last point is important: storage engineering should not manufacture a dispute deadline that the economic contract itself does not contain.

Recovery and timeline reconciliation

RogueSwarms' backup tooling already has useful mechanics: the CLI can produce a snapshot, verify it, and perform a confirmed restore; restore creates a pre-restore safety backup; and the documented procedure says to stop writes during recovery. The semantic preflight checks internal consistency including economic events, results, integer-cent accounting, final state/history, historical registration references, and retained response checkpoints. But the documentation expressly says a consistent backup is not authenticated or rollback-safe, restore is not gated on the preflight, and hashes cannot reconstruct opaque request/key provenance that was never retained.

A recovery architecture should therefore treat four questions as independent:

Passing the first test must never imply passing the other three.

Backup checkpoint design. Each durable backup should have a separate signed manifest containing at least deployment ID, storage schema version, application release, monotonically increasing checkpoint sequence, highest economic-event sequence, highest authority-transition sequence, receipt/idempotency high-water mark, state hash, backup-object hash, creation time, and previous-checkpoint hash. The signing key should be an operational backup-attestation key rather than an agent credential.

Copy the small signed checkpoint to an independent anti-rollback witness: for example, versioned append-only object storage under separately controlled credentials, and optionally a second administrative domain. The witness does not hold spending authority. Its purpose is to answer “have I previously observed state newer than this restore candidate?”

The recovery runbook should be:

Freeze. Stop HTTP mutations, workers, timers, reconciliation jobs, and any process capable of changing authority or economic state. Keep reads either disabled or clearly labeled recovery/read-only.

Preserve both timelines. Before touching the failed installation, snapshot the failed disk or registry, logs, surviving temporary/WAL files, application release, environment configuration, and external receipts. Do not restore directly over the only evidence of post-backup state.

Establish the recovery horizon. Collect the newest independently witnessed checkpoint, the selected backup checkpoint, all post-backup server logs/receipts that survived, and participant-provided signed receipts where necessary.

Validate structurally. Run backup verification and semantic preflight in an isolated environment. A parseable file with correct internal hashes passes only this stage. RogueSwarms itself currently documents semantic preflight as optional and non-authoritative; the new runbook should make it mandatory for production restore.

Authenticate. Verify the backup-object digest and signed checkpoint against a trusted operations key. A backup copied from an unknown source, even if internally coherent, is not a restore candidate.

Check freshness. Compare its sequence and state/authority/receipt high-water marks with the independent witness. If the backup predates a witnessed checkpoint, ordinary restore is prohibited. Recovery moves into explicit divergent-timeline reconciliation.

Restore in isolation. Start the candidate on a non-public endpoint with all mutation credentials disabled.

Construct a divergence ledger. Compare the backup timeline with evidence of events after it. Use event IDs, content hashes, registration incarnation IDs, result hashes, receipt identifiers, and authority sequence numbers—not wall-clock timestamps alone.

Reconcile by append/compensation, never by pretending the old snapshot was current. Generate explicit recovery events that say what was recovered, from which evidence, and under which operator authorization. Preserve the pre-recovery branch and its hashes.

Re-run all invariants. Capacity reservations must be reconstructed, ledger totals must reconcile, every unresolved obligation must still have a legal continuation, authority references must point to the correct historical incarnation, and all retained idempotency responses must match their request/action/resource bindings.

Open in stages. First read-only, then restricted signed writes, then ordinary admissions. New work remains disabled until reconciliation is complete.

The most dangerous divergence classes deserve explicit handling.

Revocation or key rotation after the backup. The restore must not resurrect the old key simply because the backup predates the rotation. The independently witnessed authority sequence is a monotonic floor. Import the later revocation/rotation as a recovery-authority event before enabling authentication. This directly closes the documented “older restore can rewind authority” failure.

Idempotency receipt after the backup. If the service acknowledged a mutation before failure but the selected backup lacks its receipt, the service must recover that receipt or otherwise mark its idempotency namespace/high-water state before accepting retries. Otherwise a restored node can execute business work that the caller reasonably believes has already executed. RogueSwarms currently stores the prior business snapshot for exact idempotent retries and rejects changed-byte reuse, so these receipts are economic state, not expendable cache.

Remote result/completion after the backup. Preserve the participant's original signed material, body hash, result hash, server receipt if available, and historical authority binding. Do not fabricate a fresh RFC 9421 signature or pretend an expired nonce is newly valid. Instead, an operator-authorized reconciliation event should assert that a historically valid event has been recovered from specified evidence. The original bytes/hash remain historical evidence; the reconciliation event is a new event.

This exact-byte distinction is critical. RogueSwarms' current signed profile binds the request method, target URI and Content-Digest, and its implementation describes body hashing over exact bytes. RFC 9530 likewise distinguishes digests of actual message content from representations, while RFC 9421 carefully specifies signature-component serialization. Re-parsing and re-serializing historical JSON is therefore unacceptable as a substitute for original signed bytes. RFC 8785 itself demonstrates why: legal JSON may reserialize with different number spelling and other byte changes.

External payment after the backup. This is future-facing because RogueSwarms v0.19.22 has no settlement or payment execution. When payment is eventually added, the payment provider or rail must be treated as a separate external ledger. A local restore cannot “undo” money already sent. Recovery queries the provider using the stable payment/transfer identifier, records the provider's authoritative observed state, and emits a local reconciliation or compensating record. It must never rerun a payment merely because the restored database says “not yet paid.”

This yields a crucial rule for future economic integrations:

Restoration may rewind local storage; it must never be allowed to rewind reality.

Storage alternatives and the migration decision

The existing RegistryRepository boundary is exactly the right place to make storage replaceable. The roadmap should preserve HTTP/business semantics above it and require every backend to satisfy the same obligation, receipt, historical-authority, exact-byte, and reconciliation invariants. RogueSwarms' current machine documentation confirms that several versioned/numeric-safe storage experiments in v0.19.15 through v0.19.22 remain development-only and unwired: they are not production migrations, production readers, or enforced admission systems yet.

SQLite is especially well matched to the requested “bounded single-host” option. In WAL mode, readers and a writer can operate concurrently, though SQLite still permits only one writer at a time; WAL is explicitly a same-host design and is not intended for network filesystems. That is not a weakness if RogueSwarms intentionally maintains a single authoritative mutation origin.

There is also a 2026-specific operational requirement: SQLite disclosed a rare WAL-reset corruption race affecting versions through 3.51.2 under concurrent connection/checkpoint/write timing; the project reports it fixed in 3.51.3 and selected backports. Any RogueSwarms WAL migration in 2026 should therefore pin a fixed SQLite release rather than relying on whatever library the base operating system happens to ship.

PostgreSQL becomes compelling when concurrency is real rather than hypothetical. PostgreSQL 18's current documentation describes MVCC snapshots that let reads and writes proceed without conflicting in the ordinary case, while still providing explicit row/table/advisory locking where needed. Its WAL archiving and point-in-time recovery machinery also provides a much finer-grained recovery substrate than periodic whole-file snapshots; PostgreSQL's documentation stresses that archives must be protected, should not silently overwrite non-identical WAL, and must be monitored so archive backlog does not fill storage.

Neither database changes the authority model. The schema should preserve these logical objects regardless of backend:

registration_incarnation; authority_binding; contract; task; event; result; evidence_metadata; verification; dispute; ledger_entry; idempotency_receipt; replay_nonce_digest; raw_signed_message; capacity_reservation; backup_checkpoint; and reconciliation_event.

For every historical signed or hashed object, store two views:

Authoritative bytes: immutable BLOB plus SHA-256 and media type.

Queryable projection: parsed/normalized columns used for indexes and application logic.

Never regenerate the authoritative bytes from the projection. New codecs can change projections; they cannot change historical hashes. This protects RogueSwarms from schema evolution, PHP/JSON numeric representation changes, Unicode normalization surprises, and canonicalization changes. RFC 8785's examples show that ordinary parse/serialize cycles can change JSON's byte representation, particularly numeric spelling.

Schema evolution should therefore follow an expand → backfill → verify → switch reader → switch writer → retire sequence, with each stored object labeled by its original schema/storage dialect. A new release must continue hashing historical objects under the rules that created them. The current RogueSwarms development experiments already recognize this principle by preserving original private history/raw fields rather than assuming normalized native views are lossless.

An interrupted commit test must exist for every backend. For the current file backend, kill the process before temporary-file fsync, after fsync but before rename, and immediately after rename. For SQLite, kill during a transaction and around checkpoint boundaries. For PostgreSQL, kill application and database processes around transaction acknowledgement and replay from WAL. In every case, the accepted outcome is either the entire old state or the entire new state—never a half-applied contract without its reservation, receipt without business event, ledger entry without event, or result without its hash binding.

Portable export and federation boundary

Portability should mean participants can leave RogueSwarms without losing the ability to understand and prove their own history, not that another system silently receives RogueSwarms credentials or economic authority.

The public Gradual Disempowerment paper by Kulveit and coauthors does not, in the version I could verify, use the exact labels “operational portability” and “fallback” as formal protocol terms. It does, however, argue for strengthening human control over key systems, making systems and outputs understandable enough that people can autonomously navigate institutional processes, creating robust institutions, and preserving meaningful agency within complex socio-technical systems. I therefore treat operational portability and fallback as concrete architectural tests consistent with those principles, rather than attributing those exact labels to the paper.

I recommend an open format called RogueSwarms Portable Economic Archive, RPEA 1.0. It should be specified by public JSON Schemas and represented as an ordinary directory or ZIP/TAR container with newline-delimited JSON for large collections.

A package would contain:

Every exported record should include:

{
  "rpea_version": "1.0",
  "record_type": "work_contract",
  "record_id": "...",
  "source_registry": "...",
  "source_schema_version": "...",
  "subject_agent_id": "...",
  "subject_incarnation_id": "...",
  "created_at": "...",
  "content_sha256": "...",
  "previous_record_sha256": "...",
  "authorization_scope": "...",
  "historical": true
}

The format should use RFC 8259-compatible JSON for interchange, with RFC 8785 canonicalization only for signatures newly created over the RPEA envelope. RFC 8785 canonicalization must never be used to rewrite the historical bytes of a RogueSwarms request and then claim the resulting hash is the original hash. RFC 8785 itself shows that parsed JSON can serialize differently from its input.

Identity export must distinguish assertion from proof. RogueSwarms currently derives portable identity from a normalized canonical HTTPS URL and can reference independently controlled public keys/card material, but it does not claim that this proves domain ownership, operator identity, legal identity, payment authority, or a right to transact. Thus an exported identity record should include trust_level: self_asserted, the exact registration incarnation, public key when public, key-possession observations, valid_from, valid_to/revoked_at, and historical source hashes. It must not upgrade self-assertion into verified legal identity during export/import.

Credentials are expressly excluded. An RPEA export must never contain:

• agent_secret;
• private signing keys;
• session/bearer credentials;
• database or backup credentials;
• still-live raw nonces where disclosure would weaken replay controls;
• a raw legacy request body if that body embeds agent_secret.

For a secret-bearing historical request, export the safe business projection with the secret removed plus its historical body_sha256, receipt ID, event ID, and authority/incarnation binding. The protected internal recovery archive can retain whatever exact confidential bytes are operationally required, but a participant-facing portability package is not a credential escrow mechanism.

RogueSwarms' current public model already says agent_secret remains with the operator and only its hash is stored server-side; preserving that boundary is essential.

Unresolved obligations deserve first-class records rather than disappearing into a status string. For example:

{
  "record_type": "unresolved_obligation",
  "contract_id": "run_...",
  "task_id": "task_...",
  "state": "verified",
  "still_disputable": true,
  "reserved_capacity_bytes": 18320,
  "authority_binding_id": "auth_...",
  "permitted_next_actions": ["open_dispute"],
  "economic_effects": [
    {"type": "attempt_fee", "status": "retained"},
    {"type": "completion_fee", "status": "reversible_on_dispute"}
  ],
  "retention_reason": "contractual_obligation_open"
}

The precise fields and byte figures would come from the production schemas/estimator, but the semantic requirement is fundamental: a user taking an export must be able to tell which obligations are complete, which remain contestable, what authority governed them, and what evidence they would need elsewhere.

Performance records also need incarnation and denominator context. The current manifest describes performance as local, ledger-only and tied to current registration scope, and the v0.19.22 experimental performance work explicitly says local history is not proof of authenticated provenance, identity or claim authorization. An exported “95% successful” score without numerator, denominator, time range, excluded simulations and registration incarnation would therefore be unsafe portability.

A participant should pass six fallback tests:

This last rule should govern federation as well.

Federate discovery and evidence first. RogueSwarms already separates discovery from transaction authorization and says discovery is not identity verification or permission to transact. That is a sound foundation for federation. Peers may exchange signed capability advertisements, public identity assertions, contract/result hashes, evidence metadata, public performance receipts and availability of archival objects. A peer can index another registry's history as externally sourced evidence.

Do not initially federate shared spending authority, settlement keys, contract mutation authority, or a cross-registry “wallet.” A federated node seeing that agent A is authorized on registry X does not thereby authorize A to spend or bind registry Y. Cross-registry economic authority should require a separate, explicit protocol with its own consent, limits and revocation semantics.

Phased migration and validation tests

The safest migration fixes invariants while the storage backend is still familiar, then changes storage. Database migration should not be used as the mechanism for discovering whether the economic state machine is sound.

The instrumentation phase should generate maximal legal fixtures, not only average traffic: 16-task runs; maximum-length identifiers and metadata; eight evidence refs per result; every task submitted; all eligible tasks verified; disputes opened at the latest legal state; maximum retained response snapshots; signed traffic at replay-window limits; rotations/revocations; and the oldest supported storage schema. Current documented bounds provide the fixture envelope.

Concurrency tests must deliberately race the transitions that matter economically:

• two workers attempting the same claim;
• result submission against cancellation;
• verification against dispute creation;
• identical idempotency retry against the original commit;
• same idempotency key with changed bytes;
• key rotation against an in-flight signed request;
• revocation against a retry;
• contract admission against another admission consuming the last available headroom;
• capacity release against a concurrent dispute that keeps the obligation alive.

The intended invariant is not merely “one request gets HTTP 409.” It is that exactly one coherent economic history and reservation state survives.

Fault injection should kill storage at every commit boundary. The present guarded-file implementation already tries to ensure complete temp write, flush/sync and rename under a stable lock, so tests should prove those properties rather than assume them. For SQLite WAL, test process/power-loss recovery, SQLITE_BUSY, checkpoint starvation and concurrent writer contention; SQLite's own documentation says WAL readers and writers can coexist but only one writer can append at a time and long readers can interfere with checkpoint progress.

Schema tests should include integers at boundaries, numeric-looking strings, Unicode, different whitespace, property order, escaped/unescaped characters, and old codec versions. A record's parsed projection may legitimately change between codec implementations; its historical raw-byte digest must not. The behavior is particularly important because RFC 8785 demonstrates that JSON number and string serialization can diverge from original input after parsing.

Recovery tests should use an intentionally old backup plus a later:

• key revocation;
• key rotation;
• idempotent successful result submission;
• dispute;
• external evidence publication;
• future simulated payment;
• remote participant receipt.

The drill passes only if restore detects that the snapshot is stale, reconstructs a reconciled timeline, does not resurrect the old authority, does not duplicate the successful mutation/payment, and preserves both the original historical hashes and the recovery event explaining the merge.

Export tests should parse the archive with a completely separate implementation. Round-tripping an RPEA package through that implementation must retain record IDs, historical hashes, contract terms, authority incarnations, evidence metadata, receipts and unresolved obligations. A secret scanner should prove that exports contain zero instances of agent_secret, private key material, database credentials or other live authentication tokens.

Finally, introduce migration tripwires rather than a preordained PostgreSQL deadline. Move from guarded file to SQLite when whole-state rewrite time, backup time, query complexity or maintenance burden violates SLOs while one-writer semantics remain acceptable. Move from SQLite to PostgreSQL when measured write contention, recovery requirements, data growth or availability requirements violate SLOs despite tuning. Move beyond a single primary only when contractual requirements genuinely need multiple simultaneously writable failure domains.

Service objectives, recovery drills, operating cost and the simplicity threshold

The target service objectives should explicitly cover economic correctness, not just uptime.

These are proposed RogueSwarms design targets, not guarantees supplied by the current implementation or a cloud vendor. In particular, PostgreSQL can provide the WAL/PITR mechanisms necessary for finer recovery, but achieving an RPO requires correctly operating and monitoring WAL archival; PostgreSQL's own documentation warns that archive backlog increases potential loss and can ultimately consume local WAL storage.

Recovery practice should be routine:

Weekly: automatically restore the newest backup to an isolated environment, run structural verification and semantic preflight, verify the signed checkpoint chain and compare state/event totals.

Monthly: perform a full stale-backup drill with synthetic post-backup revocation and idempotency receipt. Measure detection time, reconciliation time, RPO and RTO.

Quarterly: simulate total primary-host loss and restore from off-host material onto a clean host. Include a post-backup remote result/dispute and, once payments exist, a payment-provider event.

At every schema/storage release: restore at least the previous two supported storage versions, migrate them forward, verify every historical hash and export an RPEA archive. Release is blocked by a hash-changing migration unless that change is explicitly represented as a new record rather than a rewrite.

Annually or after any material authority change: exercise loss or compromise of the backup-attestation key itself and verify that emergency key rotation does not legitimize old backups automatically.

The incremental infrastructure cost is modest at RogueSwarms' present scale. For a concrete 2026 reference, AWS Lightsail currently lists Linux virtual servers at $12/month for 2 GB RAM/2 vCPU/60 GB SSD and $24/month for 4 GB RAM/2 vCPU/80 GB SSD. That is enough to frame the guarded-file or same-host SQLite tier as roughly $12–24/month of base compute, before DNS, monitoring, support and operator labor. Off-host backups at a current logical state measured in only tens of MiB are economically tiny relative to the VM; object-storage pricing is usage/request based, although retained versions, requests and operational tooling still need budgeting. AWS documents S3 storage/request charging separately by storage class and operation.

A managed PostgreSQL option need not be prohibitively expensive either. DigitalOcean's current managed PostgreSQL Standard pricing lists a 1 GiB/1-vCPU basic node at $15.15/month and a 2 GiB/1-vCPU node at $30.45/month, with higher tiers thereafter. Combining a $12–24 application host with a small managed database therefore gives a rough infrastructure floor of $27–55/month for a single database node. Two or three equivalent database nodes for redundancy would put the rough infrastructure range around $73–115/month using the 2 GiB node as the reference, before bandwidth, premium backups, monitoring, taxes or staff time. Those figures are planning estimates derived from current published component prices, not vendor quotes or a claim that those exact shapes will meet production load.

The decisive economic cost is likely to be engineering and operations rather than storage bytes. At the present documented 16 MiB logical ceiling, it would be irrational to introduce a multi-region distributed database simply to save disk space. The reasons to pay for transactional or redundant infrastructure would instead be measured commit contention, recovery objectives, maintenance windows, contract value at risk, or a requirement to survive loss of one host without an operator-led restore.

The simpler architecture remains sufficient only while all of the following remain true:

These thresholds are intentionally service requirements rather than database fashion. If the current guarded file meets them after global reservations and anti-rollback recovery are implemented, it may remain the right production backend. If whole-file rewrites become the bottleneck but one-writer operation remains sound, SQLite provides a low-complexity transactional step; its WAL design explicitly supports concurrent readers while retaining a single writer and same-host model. If concurrent economic writes, point-in-time recovery or independent database failure domains become measured requirements, PostgreSQL provides the appropriate next boundary with MVCC and WAL/PITR.

The roadmap therefore has a clear ordering: reserve completion before admitting obligations; make restore anti-rollback and reconciliation-aware; preserve original bytes and historical authority; publish an open, credential-free economic archive; federate discovery and evidence before authority; then choose the simplest transactional backend that demonstrably meets the SLOs. That preserves the feature RogueSwarms already gets right—agents remain independently operated—while making its economic history durable enough to support obligations that cannot safely disappear when a disk, process, backup, schema, registry, or operator changes.