ctxpkg.org

Conformance

Conformance levels

Claim rule: level N requires all of levels 1…N

In plain terms: conformance is how a tool proves it speaks CTXPKG correctly. Pick a level, pass the checks, run the test files below — then say so publicly.

Progressive adoption is the point: a tool earns value from the standard on day one and grows into deeper levels when its users need them. A reader claiming level N MUST satisfy every lower level.

1

Basic

Editors, CLIs, any JSON-capable tool — implementable in a day

Must

  • Parse the JSON container and manifest
  • Verify integrity hashes; reject on mismatch
  • Load flat nodes (id, type, content) into agent context
  • Preserve unknown fields and node types on round-trip

May

  • Ignore edges, activation, decay
2

Graph

Context engines, MCP servers, registries

Must

  • Everything in Level 1
  • Honor typed edges; expose relationships to consumers
  • Resolve dependencies via SemVer ranges
  • Compose multiple packages via graph merge (§6 of the spec)
  • Surface contradicts conflicts — never silently drop a side
  • Verify Ed25519 signatures when present

May

  • Treat activation as a hint rather than a budget input
3

Cognitive

Full context runtimes (reference: lean-ctx)

Must

  • Everything in Level 2
  • Honor activation energy under token budgets
  • Maintain Hebbian edge weights and co-activation counters
  • Apply temporal decay from decay_half_life_days
  • Round-trip full cognitive state without loss

Registry conformance

Registries have their own checklist: the required endpoints and the six publish verification steps in the registry protocol — including server-side secret scanning with hard rejection.

Test vectors (golden files)

Five canonical files, produced and verified with the reference implementation. A conforming reader MUST accept both valid vectors and reject all three invalid ones:

Vector Expected behavior
valid-level1.ctxpkg Accept. v1 schema, knowledge layer — exercises the v1 compatibility mapping (spec §10).
valid-level2-signed.ctxpkg Accept. v2 graph with typed nodes, Ed25519-signed by the CTXPKG maintainers.
invalid-integrity.ctxpkg Reject: content_hash mismatch. One node was modified after hashing.
invalid-signature.ctxpkg Reject: signature verification failed. Signature bytes corrupted after signing.
invalid-missing-required.ctxpkg Reject: parse error. Required manifest field integrity is absent. 
# fetch the vectors
for f in valid-level1 valid-level2-signed invalid-integrity \
         invalid-signature invalid-missing-required; do
  curl -sO https://ctxpkg.org/conformance/vectors/$f.ctxpkg
done

# reference verdict, per check (structure, content hash, package hash, signature)
lean-ctx pack verify *.ctxpkg          # exit 1 — the three invalid vectors fail

# independent second opinion, written from the spec text alone
npx @ctxpkg/verify *.ctxpkg

Both verifiers print a per-check verdict — compare your implementation's output check by check, not just the final yes/no.

Claiming conformance

"CTXPKG-conformant, Level N" may be claimed publicly once your implementation satisfies the checklist for that level and the test vectors above against the current specification version. Then submit it for listing — every entry on the implementations page counts toward the shared-governance trigger.