Skip to content

registry.md

Latest commit

 

History

History
87 lines (68 loc) · 4.29 KB

registry.md

File metadata and controls

87 lines (68 loc) · 4.29 KB
Raw

Conformance registry

This page lists providers that are Context Graph Protocol (CGP) conformant — green on contextgraph-conformance's suite for their declared capability set (see running-conformance.md) — with a reproducible, checkable report backing the claim. It exists so "conformant" stays a verifiable fact about a specific build, not a badge anyone can paste in.

Listings here are also load-bearing for governance: the move from single- maintainer stewardship to a group drawn from independent implementers is triggered by adoption — independent implementations passing the suite — not by a calendar date (GOVERNANCE.md). This registry is where that count becomes checkable.

Conformant providers

Provider Author Transport Declared capabilities Data flow Protocol version Last verified Report
contextgraph-example-docs CGP maintainers (bundled reference fixture) stdio kinds=[doc, snippet], graph, verify, correlation, embeddings_fingerprint=bge-small-en-v1.5/384/l2 reads-only, egress=false (local-only) contextgraph/1.0 2026-08-30 14/14 checks passed — report

This founding entry is the reference fixture bundled with contextgraph-conformance itself (SPEC.md §11 seed providers) — it exists to prove the table and the submission flow work end to end. Third-party providers land the same way, via the PR flow below.

The listed report is a byte-for-byte capture of:

cargo install contextgraph-conformance
cargo build -p contextgraph-conformance --bin contextgraph-example-docs
contextgraph-inspect stdio --json -- ./target/debug/contextgraph-example-docs

(Run from a checkout of this repository, since contextgraph-example-docs is a dev-only fixture binary, not something published to crates.io — see the publish = true override note in contextgraph-conformance/Cargo.toml.)

How to get listed

There is no submission form and no self-attestation — a listing is a pull request that a maintainer can independently re-run.

  1. Run the suite against your provider with contextgraph-inspect ... --json (see running-conformance.md) and confirm every check is pass (a skip is fine — e.g. malformed-input-tolerance on an HTTP or in-process target — a fail is not).
  2. Open a pull request adding one row to the table above and, if it's convenient to share, the JSON report file it links to. State the exact command you ran — the PR template has a Registry submission checklist item for this; a listing with no reproducible command attached will not be merged.
  3. Add the badge (optional, see below) to your own README once the PR merges.

A maintainer re-runs the check before merging. A listing that stops passing — because the provider regressed or the protocol moved — gets a follow-up PR to fix it or remove the row; this registry is a live claim, not a one-time certificate.

The badge

Once your provider has a merged row in the table above, you can put this in your own README:

![CGP conformant](https://raw.githubusercontent.com/macanderson/context-graph-protocol/main/assets/badges/conformant.svg)

which renders as:

CGP conformant

The badge is a static, hand-authored asset — not a live third-party redirect — so it never depends on anyone's site being up, and never phones home. It names the protocol family the badge claims (contextgraph/1.0), not a specific provider version; the row in this table is what backs the specific claim.

The URL is this repository's GitHub-raw path because this repository does not deploy a website: contextgraphprotocol.org is served by macanderson/cgp-website and carries nothing under /badges/, which is why the previously advertised cgp.oxagen.sh/badges/conformant.svg 404ed for every author who pasted it. GitHub serves the file as image/svg+xml, so it renders anywhere a README does. See ADR 0008 for the host boundary and why it is permanent here.