Markov Mesh Vault For KV Replacement

This note scopes a Gnosis-backed, Vault-like storage service that can eventually replace Cloudflare KV as the compatibility backend for x-ranger.

What the repo already has

• The finite-state mesh stack formalizes a control surface from MeshMarkovKernel through Dobrushin contraction, Buleyean floor, quorum certification, and reconstruction boundaries (../FORMAL_LEDGER.md).
• The unscheduling mesh and VoidStash formalize storage-like behavior more directly: vent-as-write, reverse-fold-as-read, and bounded stash growth (../src/unscheduling-mesh.ts, ../lean/Lean/ForkRaceFoldTheorems/VoidStash.lean).
• x-gnosis already proves a useful pattern: a KV-shaped API can sit on top of a different body store. EscXGnosisTier accepts a pluggable EscBodyStore, and fabricEscBodyStore uses immutable fabric storage with an optional local KV warm cache (../../x-gnosis/src/esc-cache-bridge.ts, ../../x-gnosis/src/fabric-esc-body-store.ts).
• x-ranger currently emulates KV with a JSON-backed in-process Map (../../x-ranger/src/platform-proxy.ts).

Main conclusion

The Markov mesh is a good fit for the control plane of a KV replacement: placement, repair, certification, quorum, and replica selection.

It is not the right primitive to use as the byte store itself.

For the storage/data plane, the closest native fit in this repo is the unscheduling/void-stash family:

• vented payloads become persisted objects
• reads become explicit reconstruction or reverse-fold
• capacity and auditability are first-class
• immutable or content-addressed bodies fit naturally

That leads to a layered design:

1. VaultBodyStore Stores bytes by content address. First local cut can use disk or SQLite. Distributed cut can add knotchain/fabric or replicated stash shards.
2. VaultIndex Maps logical KV keys to versioned body references, metadata, TTL, and list cursors.
3. MeshControlPlane Uses the Markov mesh and certification surfaces to choose replicas, govern repair, and expose confidence/quorum state.
4. KvCompatNamespace Presents the Cloudflare-shaped get/put/delete/list surface to x-ranger, x-gnosis, and worker code.

Why this is the honest cut

Good fit

• Replica choice and rebalance policy: the Markov kernel already models row-stochastic transitions and composition.
• Repair routing: Dobrushin/Buleyean machinery gives a principled way to prefer stable, non-collapsing repair paths.
• Quorum/certification: the distributed-cert boundary already describes quorum progress and completion.
• Observability: reconstruction is already treated as an explicit boundary, not a hidden side effect.

Bad fit

• A local KV emulator in x-ranger does not need probabilistic routing to read one JSON file from disk.
• Using the dark fork directly as the first persistence engine would force scheduling semantics into the hot path before we have a clean storage contract.
• The existing DarkSectorVault and DarkSectorSafe surfaces are closer to sharded concealment/reassembly than Cloudflare KV compatibility (../src/dark-atomized-encryption.ts, ../src/dark-sector-safe.ts).

Gap against current x-ranger

x-ranger's current KV shim is intentionally small. It persists values and metadata, but it does not yet model the broader contract used elsewhere in the repo:

• no TTL expiry behavior
• no getWithMetadata
• no ReadableStream write path
• no cursor/limit pagination semantics beyond a complete local scan
• no content-addressed body separation
• no repair, audit, or certification lane

The richer contract already exists in shared-utils via AeonKVNamespace (../../../shared-utils/src/aeon-os/machine/bindings/kv-namespace.ts).

Recommended service shape

Logical records

interface VaultKvHead {
  key: string;
  version: number;
  bodyRef: string;
  valueEncoding: 'text' | 'json' | 'bytes';
  metadataRef?: string;
  expiresAt?: number;
  lastModified: number;
}

interface VaultBodyRecord {
  ref: string;
  bytes: Uint8Array;
  contentType?: string;
}

interface VaultReplicaWitness {
  bodyRef: string;
  replicaId: string;
  state: 'fresh' | 'stale' | 'repairing';
  certified: boolean;
}

Local first cut

• VaultBodyStore: local filesystem or SQLite blob table
• VaultIndex: SQLite or append-only JSON index
• KvCompatNamespace: replaces XRangerKvNamespace
• MeshControlPlane: stubbed to a deterministic single-node policy

This keeps x-ranger honest: local emulation first, distributed mesh later.

Distributed cut

• bodies stored in stash/fabric shards
• index heads replicated across a bounded shard set
• Markov mesh selects read quorum / repair target / prefetch target
• distributed cert marks a head or replica set as globally readable

This is where the mesh theorem stack starts doing real work.

Concrete integration path

x-ranger

• Add a storage abstraction under ../../x-ranger/src/platform-proxy.ts instead of letting XRangerKvNamespace own persistence directly.
• Keep the existing JSON Map backend as the default fallback backend.
• Add a vault backend that uses the body/index split.
• Expand the generated KV types in ../../x-ranger/src/cli.ts to match the contract we actually use in-worker.

gnosis

• Introduce a runtime-facing vault contract near the existing storage/caching surfaces, not inside the theorem-only files.
• Use VoidStash / unscheduling-mesh semantics for body storage and recovery.
• Use the Markov mesh theorem family as the policy and certification layer, not as the byte codec.

x-gnosis

• Reuse the EscBodyStore pattern for pluggable body storage.
• A future vaultKvBodyStore can look structurally similar to fabricEscBodyStore.

Risks

• If we bind x-ranger directly to a distributed mesh too early, local dev becomes harder and parity gets worse, not better.
• If we keep the body and head in one mutable JSON object, we lose the main advantage of a vault design: auditability, dedupe, and immutable bodies.
• If we promise Cloudflare parity before implementing TTL, metadata retrieval, and pagination semantics, the replacement will be nominal rather than real.

Recommendation

Build the KV replacement as a vault-backed compatibility layer:

• VoidStash / stash-style storage for the data plane
• Markov mesh for routing, repair, and quorum on the control plane
• x-ranger adapter as the compatibility plane

That preserves the useful parts of the gnosis theorem stack without forcing the local worker runtime to pretend it is already a distributed storage mesh.

Immediate next cut

The smallest useful implementation is:

1. factor XRangerKvNamespace behind a KvBackingStore interface
2. add getWithMetadata, TTL handling, and cursor/limit pagination
3. add a VaultBodyStore + VaultIndex local backend
4. keep Markov-mesh policy hooks as optional fields until the distributed cut is real

That gives x-ranger a better Cloudflare replacement path now, while keeping the door open for the darker mesh-backed service later.