Open Memory Interchange — Formal Specification

Spec ID:

OMI-AI/0.1-draft

Status:

Public Review Draft / not a stable 1.0 release

Format version:

0.1

Primary file extension:

.omi.json

Primary media type:

application/vnd.omi+json

Streaming file extension:

.omi.jsonl

Streaming media type:

application/vnd.omi+jsonl

JSON Schema:

JSON Schema Draft 2020-12, with L0 and L1 schemas in Appendix B

Canonical release posture:

small, neutral, snapshot-first memory interchange floor

Name and acronym are provisional. “Open Memory Interchange” and “OMI-AI” are working names. The floor’s value is neutrality, not ownership or branding. Before public launch, the working group should resolve naming, domain, repository ownership, and governance. The format was previously named “Open Memory Record” (OMR), but that acronym collided with the widely used acronym for Optical Mark Recognition, so it has been renamed to “Open Memory Interchange” (OMI-AI); do not lock the acronym until searchability and standards-positioning have been checked. A memory portability floor adopters do not perceive as one author’s front door is the floor most likely to be adopted.

0. Abstract

Open Memory Interchange is a minimal, vendor-neutral JSON format for exporting and importing AI, assistant, and agent memory between tools. Its only job is portability: a producer can emit an OMI-AI file, and a consumer can read that file without sharing a storage engine, query language, governance model, ontology, vector index, or vendor-specific runtime.

OMI-AI is deliberately thin. It defines:

1. a file envelope;
2. a human-readable memory record;
3. a small set of optional descriptive fields;
4. an extension object, ext, for everything above the floor;
5. two serializations of the same model: a single JSON document and a JSON Lines streaming form.

OMI-AI does not define a query language, schema language, lifecycle model, full provenance graph, integrity/signature scheme, embedding standard, storage engine, sync protocol, or notation language. Those concerns are real, but they belong in optional profiles layered on top of the floor.

The core invariant is simple:

A floor-only OMI-AI record remains legible from content alone.

A record may carry type hints, source hints, validity dates, tags, entities, relations, language metadata, and extension profiles. But a consumer that understands none of those still receives a readable memory.

This document is not a claim that OMI-AI is stable. It is a formal public-review draft. A stable 1.0 should require implementation feedback, conformance fixtures, at least two independent import/export implementations, and a governance home.

1. Design goals and non-goals

1.1 Goals

1. Portability above all. A file is self-describing and tool-independent.
2. A floor anyone can reach. Existing provider exports, assistant memories, agent memories, CRM notes, local knowledge-vault notes, and application-specific memory stores can be converted into OMI-AI without adopting a theory of memory.
3. Snapshot-first interchange. OMI-AI core represents export/import snapshots. Incremental synchronization, tombstones, mutation operations, and conflict policies are optional profile concerns.
4. Human-readable anchor. Every record has content: a readable text anchor. The record is not only an opaque structured object.
5. Open memory type vocabulary. type is an open string. OMI-AI recommends semantic, episodic, and procedural, but does not require or exhaust memory taxonomy.
6. Forward and outward compatibility. Unknown extension profiles do not make a file invalid. Lossless round-trip processors preserve unknown extensions.
7. Profile pressure valve. Governance, integrity, schema, provenance, retrieval, and sync live in named profiles under ext, not in the core.
8. Large-export viability. OMI-AI supports both ordinary JSON files and JSON Lines for large exports and streaming pipelines.
9. Boring on purpose. Plain JSON, no custom syntax, no required cryptography, no required ontology, no required embeddings, no required hosted registry.

1.2 Non-goals

OMI-AI explicitly does not specify, and a floor implementation MUST NOT require, any of the following:

• A query or traversal language. Searching and querying memories are consumer/runtime concerns.
• A schema, shape, or ontology language. Per-domain validation belongs in the optional schema profile. OMI-AI core only validates the generic interchange envelope and record floor.
• A governance or lifecycle model. States, review workflows, immutability-with-supersession, effective views, and acceptance semantics belong in the optional governance profile. In OMI-AI core, a relation with type supersedes is a link hint only.
• An integrity, hash, seal, or signature scheme. OMI-AI core defines no hash field. Content-only hashes create false assurance because they do not protect record metadata, source, validity, relations, or extensions. Hashing, canonicalization, sealing, and signatures belong in the optional integrity profile.
• An embedding or vector portability model. Embeddings are model-specific retrieval artifacts. They are not portable memory substance. Embedding vectors and vector references belong in the optional retrieval profile.
• A sync protocol. Delta exports, tombstones, deletes, last-write-wins, conflict resolution, cursors, and operations belong in the optional sync profile.
• A storage engine, index, transport, or authorization model. OMI-AI defines file interchange, not runtime infrastructure.
• A canonical claim graph. Strong claim immutability, provenance chains, authority, formal composition, and governed query/mutation are higher-layer concerns, not OMI-AI core.

These exclusions are a commitment, not an omission. They are what make OMI-AI politically and technically small enough to be a shared floor between parties who disagree about everything above it.