Open protocol · v0.1-draft

Context governance needs
a wire format.

Agents are infrastructure — and infrastructure interoperates through open protocols. The Open Context Protocol specifies the five objects a governed context pipeline exchanges with the parties that must trust it: what entered context, who may do what, which rules applied, what provably happened, and what is happening now.

Read the spec JSON Schemas (Apache-2.0)

Status: v0.1-draft, pre-review. The five parts and their schemas are published and stable enough to implement against; structural feedback is welcome and can still shape v0.1. Until release, cite the draft — not a finished standard.

The protocol

Five parts, one trust boundary.

Each part is a self-contained wire object with a normative JSON Schema (draft 2020-12). Together they cover the full conversation between a context pipeline and anyone who must trust it: engineers, auditors, dashboards, other pipelines.

Part 1 · context-ir.schema.json

Context-IR

What entered the model’s context? A bounded, redacted, hashable intermediate representation: per-item source attribution, token accounting, safety flags and excerpt verification hashes.

Part 2 · capabilities.schema.json

Capability Vocabulary

What may an agent do, on whose authority? Standard capability identifiers, grant sets per subject and machine-checkable capability check results — the language of default-deny.

Part 3 · policy-pack.schema.json

Policy Packs

Governance expectations as reviewable data: tool allow/deny, context budgets, audit retention and redaction patterns, with single inheritance — policy as code, portable across pipelines.

Part 4 · evidence-entry.schema.json

Evidence Chain

Tamper-evident history: hash-chained audit entries with Ed25519 provenance signatures and a typed event registry — including the agent identity lifecycle. Anyone can replay the chain offline.

Part 5 · event.schema.json

Event Vocabulary

Governance-relevant runtime events on the wire: tool calls, policy violations, budget warnings and exhaustion, role changes — the stream dashboards and SIEMs consume.

Design principles

Strict where trust lives, open where it grows.

The protocol draws a hard line between the governance surface (closed, schema-enforced) and everything else (forward-compatible, additive registries).

Implementation-neutral

No engine internals, no compression heuristics, no product features — only the wire objects two independent parties need to agree on. The protocol/product boundary is documented in ADR-0001.

Schema-first

JSON Schema (draft 2020-12) is normative; where prose and schema disagree, the schema wins. RFC 2119 key words throughout. Closed governance surfaces are marked additionalProperties: false.

Offline-verifiable

Evidence chains replay without the producer’s help: SHA-256 hash chains plus Ed25519 signatures. The standalone leanctx-verify tool is an independent second implementation of Part 4.

Forward-compatible

Consumers ignore unknown fields; registries (source kinds, capabilities, event types) grow additively. Breaking changes require a new major version — drafts are labelled as drafts.

Reference implementation

Conformance is tested, not asserted.

LeanCTX implements all five parts and validates its own runtime output against the published schemas in CI — real IR documents, capability grants, resolved packs, audit entries and events, on every commit.

The evidence side goes further: leanctx-verify, the standalone audit tool, re-implements Part 4 from the specification text alone — no shared code with the engine. When it verifies a LeanCTX evidence bundle, that is two independent implementations agreeing on the spec. Mutation tests prove a single flipped byte fails verification.

See it end to end: lean-ctx audit evidence --from … --to … produces a signed bundle; leanctx-verify bundle.zip replays the chain offline. Details on the compliance & evidence page.

Governance

Maintainer-led now, shared by design.

Phase 1: LeanCTX maintainers edit the spec, all changes public, issues and merge requests open to anyone. The governance document commits to Phase 2 — shared governance with named external maintainers — once two independent implementations exist. Licenses: CC-BY 4.0 (prose), Apache-2.0 (schemas).

Implementing OCP in your pipeline? Tell us — the second independent implementation triggers the shared-governance phase, and early implementers shape the registries. Open an issue →

FAQ

The protocol, answered.

What is the Open Context Protocol?

An open specification for governed context exchange between AI pipelines and the parties that need to trust them: five parts covering context observability (Context-IR), capability grants, policy packs, tamper-evident evidence chains and a governance event vocabulary. All wire objects are JSON with normative JSON Schemas, published under CC-BY 4.0 (prose) and Apache-2.0 (schemas).

Why does context exchange need a protocol?

Agent pipelines are becoming infrastructure, and infrastructure needs interoperable seams: an auditor should verify evidence without installing the vendor’s product, a dashboard should consume governance events from any engine, and a policy pack should be reviewable independent of the runtime that enforces it. A protocol makes governance claims portable — and falsifiable.

Is OCP a LeanCTX standard?

LeanCTX maintainers edit the spec and LeanCTX is the reference implementation, but the protocol deliberately contains no LeanCTX concepts: ADR-0001 documents the protocol/product boundary, and anything engine-specific stays out. Phase 1 governance is maintainer-led; the governance document commits to shared governance once there are two independent implementations.

How is conformance proven rather than claimed?

LeanCTX validates its own runtime output against the published schemas in CI on every commit: real Context-IR documents, capability grants, resolved policy packs, audit entries and events are generated and checked with a JSON Schema validator. The standalone verifier (leanctx-verify) additionally re-implements Part 4 from the spec text alone — a PASS means the specification holds, not that two copies of the same code agree.

Can I implement OCP in my own pipeline?

Yes — that is the point. The schemas are Apache-2.0; start with Part 4 (evidence chain) or Part 5 (events), which give auditors and dashboards immediate value. The spec repository takes issues and merge requests, and the draft status means structural feedback can still shape v0.1.

Build on the protocol.

Read the five parts, validate against the schemas, or see the reference implementation govern real pipelines — free forever, locally.