[chain] governance

Context that steers agents needs a chain of custody.

Code learned this lesson the hard way: a package you cannot trace is a liability, and supply chains got signatures, provenance and policy. Context is next — it decides what your agents do, and most of it still travels as untraceable markdown.

This registry is one link in a governed supply chain that runs from the machine that distills knowledge to the agent that consumes it. Every hand-off is verifiable.

[supply chain] five links

Five links, each one checkable

01

Distill

your machine

A context engine distills knowledge from your code and sessions into a typed package. Before anything leaves the machine, a secret scan blocks credential-shaped content from ever being exported.

lean-ctx pack export --sign · client-side secret scan

02

Seal

author key

The package is hashed over its exact document text and signed with the author’s ed25519 key. From this moment, changing one byte breaks the seal — verifiably, on any machine, offline.

SHA-256 integrity (spec §8) · ed25519 signature (§9)

03

Publish

this registry

The server re-runs everything it can check: name and version binding, both hashes, the signature, plus a hard secret scan that rejects high-confidence findings. The verification report is recorded permanently and is public.

Six server-side checks · immutable versions · public trust report

04

Verify

every install

Your machine re-hashes the download, re-checks the signature and pins the exact fingerprint in ctxpkg.lock. Nobody on the path — including us — can swap what your team installs.

Local re-verification · ctxpkg.lock pinning · read-only ctxr_ tokens for CI

05

Enforce

your context engine

Policy decides what an agent may consume: which namespaces, which visibility, which checks must have passed. The reference engine gates installs by policy packs and writes signed evidence of what context entered which session.

Policy-gated installs · audit trail · signed evidence bundles (LeanCTX)

[live] running now

Live today — not a roadmap

Everything below is running in this registry right now. The trust page documents each mechanism in depth.

signature verified

Server-side on publish and locally on every install — really checked, not just "present".

public trust reports

The publish-time verification report of any version is a public API object. Audit any release, any time.

verified identity

DNS TXT proof binds a namespace to a domain. Two minutes, cryptographically checkable.

immutable versions

Releases can be yanked, never replaced. Reproducibility beats convenience.

hard secret gate

High-confidence credentials in content reject the publish with HTTP 422 — protecting publishers from their worst day.

scoped tokens

ctxp_ publishes, ctxr_ only reads. CI never holds a key that can ship context.

[enforcement] engines

The enforcement layer

A registry can prove what a package is. Only the engine that loads context can decide what an agent may see — and prove later what it saw. That is the enforcement layer, and it is where governance becomes real.

The reference engine, LeanCTX, ships this today: policy packs that gate which context enters a session, framework compliance reports (EU AI Act, ISO/IEC 42001, SOC 2), tamper-evident audit trails, and Ed25519-signed evidence bundles auditors verify offline. The contract is being opened up as the Open Context Protocol — so any engine, not just ours, can enforce the same guarantees.

The missing piece between registry and engine is standardized provenance: signed statements about how a package came to be — source, builder, redaction checks, review. RFC 0002 proposes exactly that for the open standard, and this registry will surface attestations the moment the spec lands.

Governance is a chain.
Join it where you stand.

How verification works The standard's vision ↗ Compliance & evidence ↗