An open standard · v2 draft

Agent knowledge deserves a file format.

Every AI-agent session learns things — facts, decisions, lessons. Today that knowledge evaporates when the session ends. A .ctxpkg file saves it: structured, sealed against tampering, ready for any tool that speaks the standard. Your agent's knowledge becomes something you can keep, share and build on.

Read the specification JSON Schema Browse the registry ↗

The layer the agent stack was missing

Almost every layer of the modern agent stack has an open standard — except the most valuable one: the knowledge a session produces. Right now that knowledge is lost when the session ends, locked inside one vendor's product, or left in notes no tool can check or combine. CTXPKG closes that gap.

Layer	Standard	Question it answers
Tool invocation	MCP	"How do I call this tool?"
Procedural know-how	Agent Skills	"How do I perform this task?"
Agent communication	A2A	"How do agents talk to each other?"
Declarative knowledge	CTXPKG	"What is true about this system — and can I verify it?"

Knowledge with structure

Facts, decisions and hard-won lessons are stored as connected, typed pieces — not a wall of text. Tools can tell what supports what, and what contradicts what.

Tamper-proof by design

Every package carries cryptographic seals (hashes and a signature). If anyone changes a single character after publishing, every tool notices — before loading anything.

Packages combine cleanly

Install two packages and they merge into one knowledge graph, predictably. When they disagree, the disagreement is recorded openly — nothing gets silently overwritten.

Start small, grow naturally

Three conformance levels. Level 1 is simple enough to implement in a day. Level 3 captures how knowledge strengthens and fades over time. You choose your depth.

One file. Everything an agent needs to trust it.

A .ctxpkg is one readable file with two parts: a manifest — the label, saying who made it, what's in it, and carrying its seals — and a knowledge graph — the knowledge itself.

Before a tool loads anything, it checks the seals: do the hashes match? Does the signature verify? Knowledge steers what your agent does, so a package that fails even one check is simply rejected. No exceptions.

Manifest reference →

auth-service.ctxpkg

{
  "manifest": {
    "schema_version": 2,
    "name": "@acme/auth-service-context",
    "version": "1.3.0",
    "conformance_level": 2,
    "integrity": { "sha256": "9f2c…", "content_hash": "b41a…" },
    "signature": { "algorithm": "ed25519", "value": "…" },
    "provenance": { "tool": "lean-ctx", "tool_version": "3.7.5" }
  },
  "content": {
    "context_graph": {
      "format": "ctxpkg-graph-v2",
      "nodes": [
        { "id": "F1", "type": "fact",
          "content": "Sessions are HttpOnly cookies, 30d TTL" },
        { "id": "G1", "type": "gotcha",
          "content": "Refresh tokens rotate — cache invalidates" }
      ],
      "edges": [
        { "from": "G1", "to": "F1", "type": "elaborates" }
      ]
    }
  }
}

Where the standard stands

Specification

v2 published as draft

Graph-native data model, three conformance levels, signing and integrity normative. Read it.

Reference implementation

lean-ctx 3.6+

Creates, signs, verifies, merges and installs Level 1–3 packages. leanctx.com ↗

Public registry

ctxpkg.com — live

Signed publishing, server-side secret scanning, verified publishers, anonymous installs of free packages. Browse ↗

TypeScript verifier

@ctxpkg/verify

A second reader, written from the spec text alone — zero dependencies, passes all five test vectors. Proof the spec is implementable. Vectors

Test vectors

5 golden files

Canonical packages every conforming reader must accept or reject — download them and test your implementation in minutes. Conformance

Your implementation

The door is open

Build a reader, writer or registry in any language — then get listed. The first independent implementation triggers shared governance — that promise is written down.

Vision

The governed context supply chain

Code went from copy-pasted snippets to a governed supply chain — packages, registries, signatures, provenance. Context is making the same journey, and it needs the same three layers. Each one is independently replaceable; that is what makes it a standard rather than a product.

01 · Law

This standard

One format every tool reads the same way — integrity, signatures, attestations, deterministic merging. Defined here, testable against golden vectors.

02 · Distribution

Registries

Permanent names, immutable versions, public trust reports, verified identity. The protocol is open — the public registry is one implementation of it.

03 · Enforcement

Context engines

Policy-gated installs, redaction, audit trails, signed evidence. Engines turn the standard’s verifiable claims into enforced behavior.

Read the full vision →