We invent no protocols. We assemble the ones that already work — in the open.
Every layer of the measurement rail is an existing, permissively licensed standard wired together and published: model-context tooling, agent-to-agent messaging, decentralised identity, and content provenance. You can read the parts, swap them, or rebuild the whole thing without us.
Measurement, not certification. Board unreachable from this browser — read it yourself at /api/gspc
Nothing here is a protocol we made up
A measurement rail that depends on a private format is not a rail — it is a lock-in with a nice diagram. So every layer is an existing open standard under a permissive licence, assembled rather than invented. If we disappear tomorrow, the pieces keep working and someone else can run the same instrument.
- PainAssurance tooling that only works while you keep paying the vendor
- PainBespoke formats nobody else can read, verify or fork
- You getOpen standards end to end — no proprietary wire format anywhere
- Only hereEvery dependency is named with its licence, in public
One gateway in front of many tools
Measurement needs to reach a lot of small, boring capabilities: fetch a provision, hash a corpus, run a grader, check a signature. Rather than one monolith, those sit behind a single aggregating gateway that routes into protected namespaces and holds downstream credentials so the agent layer never sees them. It is deliberately unglamorous infrastructure.
- PainEvery integration means another key pasted into another agent
- You getOne endpoint in front of many tools, with namespace isolation
- You getDownstream credentials are held at the gateway, not handed to models
- Only hereStateless by design, so scaling never depends on sticky sessions
Vertical for tools, horizontal for agents
The two protocol families do different jobs and it is worth not blurring them. The model-context layer runs vertically — one agent reaching down into typed tools. The agent-to-agent layer runs horizontally — separate services finding each other and delegating, each identified by a signed agent card served from a well-known URL. Mixing them up is how architectures rot.
- Pain"Agent platforms" that fuse tool-calling and federation into one bespoke blob
- You getTool invocation and agent federation stay separable and replaceable
- You getIdentity is a signed card at a published address, not a shared secret
- Only hereBoth layers are public standards — your agents can talk to ours without a contract
The key comes from the domain, not from us
Everything downstream hangs on one resolvable anchor: the DID document published at csoai.org, which carries the Ed25519 public keys used to sign boards and cards. You fetch it from the domain itself — there is no key exchange, no account, and nothing to ask us for. And the separation matters as much as the key: identity assertions are kept out of the measurement engine, so who you are can never move what the instrument says.
- PainVerification that requires an account with the party being verified
- You getPublic keys resolvable straight from the domain
- You getIdentity and measurement stay strictly separated
- Only hereWe sign the measurement — we never sign a certification, because we issue none
The private key never travels
The obvious way to build this is also the wrong one: ship telemetry to a central service and let it sign. That puts a key on the wire and a single point of compromise in the middle. Instead the signing runs client-side in a worker thread, and only finished, verifiable envelopes cross the network. A small, boring command-line kernel does the same job locally.
- PainCentral signing services concentrate every key into one target
- You getSignatures are produced where the data is, not where the vendor is
- You getOnly verifiable envelopes cross the network
- Only hereSigning today is Ed25519; the ML-DSA-65 (FIPS-204) signer is built but not shipped, and we will say so until it is
Marking generated content — and what we measured about it
Article 50(2) of the EU AI Act requires machine-readable marking of synthetic content, and the C2PA manifest is the standard way to do it: a signed, hashed JSON-LD record of who made a thing, with what, and from which ingredients. Then we measured whether marking survives contact with the real world. It largely did not: across our published provenance bench, none of the marked assets kept a verifiable manifest through ordinary compression and re-encoding. We published that result rather than the diagram.
- PainMetadata manifests are routinely stripped by compression, re-encoding and social transit
- PainA marking pipeline can be correct at creation and worthless three hops later
- You getA measured survival rate instead of a compliance promise
- Only hereWe published our own marking failing, including that our test certificate is not on the C2PA trust list
If the manifest is stripped, the asset should still be findable
The answer the standards community is converging on is a durable payload carried in the content itself, so a stripped file can still be matched back to its signed manifest. That is the right direction and we contribute tooling and test vectors to it. It is not, today, a solved problem — and a page that told you it was would be doing the thing this whole site exists to stop.
- PainA stripped file is an orphan: no manifest, no provenance, no recourse
- You getDurable payloads that can survive the transforms metadata does not
- Only hereWe contribute running code and test vectors, and we publish where it still fails
Input, compute, identity, output — all four in the open
A request comes in over an open event wire. It is routed into the agent ring for the actual work. The action is signed client-side against the key published at csoai.org. The result leaves wrapped in a provenance manifest. Four steps, four public standards, no proprietary link in the chain — and a measured account of which links are strong and which are not yet.
- You getEvery stage is an open standard you can inspect or replace
- You getThe ring topology is published as design, with no capacity claim attached
- Only hereWhere a link is weak we publish the measurement, not the roadmap slide
What this page does not claim
We publish the limits with the results. Everything below is something a reader could reasonably assume from a page like this one — and each is something we cannot presently evidence, so we say so rather than let the assumption stand.
- We do not claim generated content is "natively compliant at the millisecond of creation". Our own provenance bench measured 0 of 20 marked assets surviving ordinary transforms (0 of 180 measured cells), and our test certificate chains to a private root that is not on the C2PA trust list — so issuer resolution is 0% there by construction.
- We do not claim membership of, or a seat on, any standards working group. We publish tooling, test vectors and a resolvable did:web; anything beyond that would need a record we do not have.
- We do not publish adoption counters for the components we build on — star counts, org counts, adoption dates. Those numbers are not ours to evidence, so they are not on this page.
- We do not claim post-quantum signing. Signing is Ed25519 today; the ML-DSA-65 (FIPS-204) signer is built but not shipped, and the label will change only in the commit that ships it.
- We do not reproduce an example manifest with invented identifiers. If you want to see a real one, verify a real card.
Coverage on this page is never typed by hand. Board unreachable from this browser — read it yourself at /api/gspc Corrections to anything we have published live in the refutation ledger — append-only, never a silent edit.