Verified Memory

Verified Memory is the property that an AI agent's memory — the claims it records, derives, and retrieves over time — is cryptographically signed, tamper-evident, and provable by a third party. It is delivered by the Osyra Memory Engine (OME / "Osymem", service AP00011).

Ordinary agent memory is a database row: trustworthy only to the extent you trust the operator who can edit it. Verified Memory makes that trust explicit and checkable. Every remembered fact is a signed claim; the workspace's committed key/value state is bound to a Jellyfish Merkle Tree (JMT) root; and the whole record can be exported as a self-contained, signed .ome archive that anyone with the real out-of-band trust anchor can re-verify offline.

Why it matters

Osyra frames this category as Mnemonic Sovereignty: an enterprise's institutional agent memory is owned by the enterprise (cryptographically anchored to its DID), portable across vendors (an exported .ome bundle re-imports bit-identically), supports erasure via cryptographic redaction (its characterization as discharging a GDPR Article 17 request is pending counsel review — see below), and makes substitution or omission from a committed key/value state detectable against a trusted root. The JMT root is a set commitment, not a temporal history commitment; scoped completeness witnesses and any ordering evidence are separate proofs.

The economic precedent OME follows is X.509 / PKIX and Visa: the underlying artifact is a boring, composable cryptographic algebra, and the value accrues to whoever publishes and reference-implements the spec. The substrate is open; the verification algebra is the moat.

How it works

OME provides four cryptographic phases that compose into one coherent algebra. The V1 substrate implements all four phases:

| Phase | Capability | Primitive | |---|---|---| | Phase 1 | Signed claims | Ed25519 over a canonical-CBOR Form B preimage with the domain-separation tag osyra-ome-claim-v1 | | Phase 2 | Authenticated state commitment + redactable proofs | Radix-16 Jellyfish Merkle Tree (JMT) per workspace; inclusion and non-membership proofs; tombstone redaction via an era-derived salt | | Phase 3 | Completeness witness | Ed25519 over a Form B preimage tagged osyra-ome-cw-v1; gap proofs over the JMT | | Phase 4 | Portable bundle (.ome) | A single bundle-level COSE_Sign1 signature over the manifest and tree metadata; deterministic ZIP layout |

1. Every claim is signed

A claim is recorded by signing it with Ed25519. The bytes that get signed are not raw JSON — they are the canonical CBOR encoding of a domain-separated array (the "Form B preimage"), with a tag string at the first position that names exactly which kind of object is being signed. Canonical CBOR (RFC 8949 §4.2.1) guarantees that the same logical content always produces the same bytes, which is what makes signatures reproducible across languages and platforms.

2. Memory state is committed to a Merkle tree

Each workspace has its own Jellyfish Merkle Tree. Its root commits the exact key/value set at that state. Anyone holding a trusted root can be given a short inclusion proof that a specific key/value pair is in the tree, or a non-membership proof that a key is absent — without being shown the rest of the tree. Changing or dropping a committed pair changes the root.

The root is deliberately insertion-order independent: inserting the same pairs in a different order produces the same commitment. The JMT therefore does not, by itself, prove event order or detect a reordered history. A temporal claim needs a separately bound sequence or write log; a completeness witness proves only the interval and gap statement its signed preimage names.

3. Redaction without breaking proofs

An erasure requirement (such as GDPR Article 17, the "right to erasure") and a tamper-evident append-only log are in tension: you must be able to delete, but deletion must not look like tampering. OME addresses this with tombstone redaction — a claim's body is cryptographically erased using an era-derived salt, while sibling proofs continue to verify. The record stays complete and checkable; the redacted content is genuinely unrecoverable.

4. The whole record exports as one signed bundle

A workspace's memory exports as a .ome archive: a deterministic ZIP whose manifest, tree metadata, and the digests of every claim and tombstone are all covered by a single COSE_Sign1 bundler signature. The signature is computed over a five-element Form B array:

preimage_value = [
  tstr("osyra-ome-bundle-v1"),    ; domain-separation tag at position [0]
  Manifest,                        ; the manifest map
  TreeMetadata,                    ; tree metadata
  ClaimsDigest,                    ; SHA-256 over the sorted claim bytes
  TombstoneDigest                  ; SHA-256 over the tombstone list
]

Covering the claim and tombstone digests inside the signed preimage means a single signature verification detects tampering of any claim or tombstone byte — no separate root-recomputation pass is required.

The offline re-verification property

A defining architectural fact of .ome is that an exported archive is re-verifiable completely offline — using only the archive bytes and a published trust anchor, with no server call, no network, and no database.

This is not a marketing claim layered on top of the design; it is structural. Osyra ships a standalone reference verifier (docs/architecture/ref/cmd/ome-verify) whose transitive import closure is asserted in CI to contain no net, net/http, database/sql, gRPC, Redis, or cloud-SDK package. The offline guarantee is therefore enforced by the build, not promised in prose.

How Verified Memory relates to the rest of Osyra

OME is the substrate that other Osyra pillars anchor into. Continuous Attestation (AP00012) periodically anchors per-tenant MMR roots into OME; each root collectively commits the preceding behavioral-attestation records (60 records at the current default cadence). The Verifier-of-Record (AP00016) reuses the same canonical-CBOR Form B and COSE_Sign1 primitives for its receipts. Verified Memory is the foundation the other pillars prove against.

AP00012 uses OME's typed bare-anchor contract for that commitment. Its deterministic canonical path is mapped to an RFC 9562 UUIDv8 anchor ID and the record's value hash is inserted into the JMT. A bare anchor is not a memory Claim: OME does not synthesize a Claim row, issuer DID, Ed25519 signature, or CLAIM_WRITTEN billing event for it.

Scope and roadmap

Phases 1 through 4 — signed claims, the JMT commitment, completeness witnesses, and the portable .ome bundle — are implemented in the V1 substrate. That does not imply that every customer or cross-service transport is activated: for example, the private broker-signing alias remains disabled until its workload mTLS, live KMS, rotation/revocation, outage, and durable-write activation evidence passes. Broader ecosystem capabilities (additional SDK languages, expanded read-side surfaces) continue to land on the roadmap; this page describes the cryptographic substrate, not the release state of every path that uses it.