01Protocol overview

How MOPS governs persistent memory.

MOPS defines how persistent memory is identified, changed, governed and verified.

An Agent expresses an intended action as an explicit M-OP Request. MOPS resolves the memory being addressed, applies the relevant Schema, Policy and operation rules, and returns a structured outcome. A successful mutation creates one new immutable State Instance and a verifiable record of the transition.

Because these rules sit at the protocol boundary, independent implementations can use different models, applications, runtimes and storage systems while preserving equivalent observable outcomes.

This page explains that operating model. The MOPS Specification and normative conformance artefacts remain authoritative for exact requirements.

02Intentional scope

MOPS standardises the memory boundary. Implementations choose how to build around it.

MOPS standardises

Identity and structure: Namespaces, versioned Schemas and canonical State.
Operations and outcomes: The closed M-OP operation set, ordered validation, State transitions, Responses and failures.
Governance and lineage: Agent attribution, Policy enforcement, immutable State Instances, Commit Records and Audit Trails.
Presentation and interoperability: Deterministic rendering semantics, synchronisation rules and conformance requirements.

Implementations choose

Models and reasoning: Inference, training, weights and context-window behaviour.
Agents and applications: Planning, orchestration, tools, interfaces and domain workflows.
Working context: Scratchpads, temporary reasoning buffers, caches and other ephemeral memory.
Technical infrastructure: Programming languages, runtimes, transport, deployment architecture, hardware and physical storage.

MOPS establishes shared meaning and behaviour at the persistent-memory boundary while leaving the surrounding AI and infrastructure stack open to implementation choice.

03Protocol model

The protocol separates identity, action, authority and persistence.

Identity and structure

Memory Object: The persistent logical object being governed.
Namespace: Provides a stable address.
Schema Version: Defines its valid structure.
State Instance: Captures its complete immutable content at one point in its history.

Action and authority

Agent · Request: An Agent proposes an action through a Request naming one M-OP Operation.
Policy: Determines the Agent’s authority and the governance outcomes that must be enforced.

Protocol functions

Reducer: Derives candidate State from declared inputs where required.
Template: Defines how governed State is rendered deterministically without mutation.

Lineage and persistence

Commit Record: When a mutation succeeds, MOPS creates one new State Instance. A corresponding Commit Record identifies the Agent and operation and links the prior and resulting State through their StateHashes.
Audit Trail: The verifiable, append-only history formed by those records.
Backing-Store Adapter: Persists and retrieves the canonical artefacts. Implementations may use local files, databases or distributed storage while preserving the same protocol meaning.

The separation is deliberate: MOPS governs memory semantics and behaviour; the storage layer provides durability.

04Governed operation path

Every operation follows one governed path.

M-OP defines a closed set of operations:

Mutating operationsCOMMIT · UPDATE · DELETE · REDACT

Read-only operationsQUERY · HISTORY · RENDER

Each operation crosses the same protocol boundary.

01
Express the Request
An Agent submits a closed Request containing the M-OP version, Namespace, one operation, explicit Agent identity and timestamp, and the fields permitted for that operation.
02
Resolve the governed inputs
MOPS resolves the addressed Memory Object, current authoritative State where one exists, applicable Schema Version, Policy and any required Reducer or Template.
The Namespace supplies the protocol address. Storage keys and other implementation details remain inside the storage layer.
03
Validate in a defined order
The Request passes through ordered checks for protocol grammar, Namespace, operation eligibility, Schema where applicable and Policy.
For mutations, the candidate State and transition record are also validated before becoming authoritative.
A failed check stops the operation at that point and produces a structured Response.
04
Construct the outcome
Each operation applies its defined semantics:
- COMMIT supplies complete State and can create a genesis Memory Object.
- UPDATE applies a partial Payload to existing State and validates the complete result.
- DELETE and REDACT produce their defined terminal State transition.
- QUERY, HISTORY and RENDER return governed results without changing State.
05
Record and respond
A successful mutation atomically creates exactly one new immutable State Instance, its StateHash and one corresponding Commit Record.
A successful read returns its governed result without creating a State transition.
If an operation fails, the prior State remains authoritative and no partial State transition or Commit Record is created. Policy may separately require a governance-relevant failure audit entry.
Every path ends in a structured Response describing the outcome.

05Preserved behaviour

Different implementations preserve the same protocol behaviour.

MOPS conformance is measured at the protocol boundary, not by an implementation’s internal design.

Equivalent outcomes

Identical governed inputs, configuration and prior State produce equivalent observable outcomes.

Immutable, schema-bound State

Accepted mutations create immutable State Instances under an explicit Schema Version and the applicable operation rules. Prior States remain unchanged, and partial transitions never become authoritative.

Deterministic ordering and failure

Validation, operation ordering, history and failure follow explicit rules. The same invalid operation fails at the same governed boundary.

Enforced Policy

Applicable Policy outcomes are part of the operation path and determine what each Agent is permitted to do.

Verifiable lineage

StateHashes, Commit Records and Audit Trails preserve the ordered relationship between accepted State transitions.

Storage-independent semantics

Storage can change in scale, performance and architecture while M-OP operations retain the same meaning and governed outcomes.

Semantic compatibility

Conformant implementations interpret shared MOPS artefacts and operations under the same protocol rules, preserving memory meaning and behaviour across different systems.

06Evidence

The protocol is published as rules, tests and a bounded executable reference.

Each artefact exposes a different part of the proposal.

01 / Rules

Normative Specification

The Specification defines the protocol structures, operations, invariants and conformance requirements.

Read the Specification →

02 / Tests

Conformance artefacts

Machine-readable vectors define expected canonicalisation, validation, StateHash, Request, transition and failure outcomes. Reference validator logic makes candidate admission mechanically testable.

Inspect the artefacts →

03 / Reference

MOPS-Lite 0.1.0

MOPS-Lite demonstrates a bounded single-runtime execution path in Python—from canonical Requests and validation through mutation, StateHash and Commit Record construction, QUERY, HISTORY and local persistence.

Explore MOPS-Lite →

Its role is deliberately limited. MOPS-Lite is a starter SDK rather than a hardened service, complete distributed implementation or proof of the entire protocol. Its current client does not execute RENDER or Schema migration through targetSchemaVersion, so it does not demonstrate the complete MOPS-Lite operation surface.

Together, these artefacts make the proposal inspectable, reproducible and open to technical challenge.

Read the Specification →Review on GitHub →