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)

Seven canonical files, produced and verified with the reference implementation. A conforming reader MUST accept the three valid vectors and reject all four 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. Identity-only signature (spec §9.1).
valid-level2-manifest-signed.ctxpkg Accept. Manifest signature (signature.manifest_value, spec §9.1) over a manifest with map-form dependencies, a 1.0 float and non-ASCII text; coverage manifest.
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-manifest-signature.ctxpkg Reject: manifest signature verification failed. visibility changed after signing; signature.value alone still verifies.
invalid-missing-required.ctxpkg Reject: parse error. Required manifest field integrity is absent. 
# fetch the vectors
for f in valid-level1 valid-level2-signed valid-level2-manifest-signed \
         invalid-integrity invalid-signature invalid-manifest-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 four invalid vectors fail (LeanCTX 3.11.5+)

# independent second opinion, written from the spec text alone
# available with LeanCTX 3.11.5 — not yet on npm
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.

Status: @ctxpkg/verify 1.1.0 is a release candidate. It is published on npm, with its source public at github.com/yvgude/ctxpkg-verify, together with LeanCTX 3.11.5; until then the npx command above returns a 404. From source, once the repository is public: git clone https://github.com/yvgude/ctxpkg-verify && cd ctxpkg-verify && npm ci && npm run build && node dist/cli.js *.ctxpkg. The released LeanCTX 3.11.4 fails the two vectors with map-form dependencies (valid-level2-manifest-signed, invalid-manifest-signature); 3.11.5 is expected to pass all seven.

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.