Open protocol · built for auditors who won't just take our word for it
An auditor should be able to verify a receipt without ever calling us.
That's the design constraint the whole protocol is built around. Every Decision Receipt, capability registration, and memory record SynOI handles is a signed object: identified by hash, signed with hybrid Ed25519 + ML-DSA-65 (post-quantum), encoded in canonical JSON. The spec is open, the reference store (SynOI Vault) ships under an OSS license, anyone can verify offline with a standard cryptographic library, and public-log anchoring is planned for Q4 2026 (OpenTimestamps / Rekor).
The governed action lifecycle (how any actor declares a capability, receives a grant, invokes it, and receipts the result) is specified in GAP (Governed Action Protocol), an open wire protocol with an IETF Internet-Draft in flight (draft-shovan-gap-00).
GAP itself sits on a more basic substrate: each signed object handled here (receipt, capability grant, memory record) gets its content-derived identity from SRAID (Self-Routing Addressable Identity Data), the open L0 content-addressed object and identity layer GAP is built on. SRAID ships today as an MIT-licensed reference library, @synoi/sraid on GitHub.
The three pieces
Protocol, format, and the application most teams meet first.
01 · Protocol
Provenance Protocol Specification
The protocol semantics: object identity (OID), content-addressed provenance, hash-chained mutation history, supersession links, point-in-time query model. Canonical JSON wire format; a CBOR profile is reserved for a future version. The novelty lives here; the bytes are standards-based.
02 · Format
Decision Receipt Format
The hybrid-signed audit record produced for every governed AI action. Canonical JSON body (RFC 8785 JCS), hybrid Ed25519 + ML-DSA-65 signatures, verifiable offline against the published public keys with no SynOI dependency. A full check needs both signature algorithms, not Ed25519 alone. A hosted verification surface at oid.synoi.systems is planned, not yet deployed.
03 · Application
Supply Chain Guard Architecture
The first vertical application of the provenance protocol outside the gateway: publisher-side HITL on npm/PyPI publish (roadmap, Q1 2027). Wrap `npm publish` for out-of-band approval. Publish-side interceptor and registry mirror Q1 2027.
Design intent
Content-addressed, append-only, point-in-time queryable.
Governed objects are identified by the hash of their canonical encoding. Same content, same identity. Different content, different identity. There is no "edit" - a new version is a new object that supersedes the prior one. The history is the data.
This is the same shape as sigstore Rekor, AWS QLDB, Google Trillian, and IPLD - the category of transparency log, not of database. We chose it because AI audit needs the same property package: tamper-evidence, time-travel queries, and third-party verifiability.
Properties
Content-addressed identity
OID = SHA-256 of canonical payload. Identical content collides by design; different content cannot.
Supersession, not mutation
New version = new record; supersession links point backward. That is the object model's design property today, not yet a proven guarantee against retroactive rewriting: the consistency proof and an independent public witness for that guarantee are on the roadmap.
Point-in-time replay
"What was true at T?" - answerable directly from the log without snapshots or restore.
Public anchor (planned Q4 2026)
Hash roots will anchor to OpenTimestamps / Rekor / sigstore so tamper-evidence survives even if operator infrastructure is compromised. Not yet live.
Standards-based wire
Canonical JSON bodies (RFC 8785 JCS), hybrid Ed25519 (RFC 8032) + ML-DSA-65 (FIPS 204) signatures. Verifying the classical half offline needs an Ed25519 library plus JCS canonicalization, and for v2 receipts DSSE PAE encoding; the post-quantum half needs an ML-DSA-65 verifier.
Where the spec stands
The honest version of "is this real yet?"
Decision Receipt v1 format
In production behind SynOI Gateway. Public verifier live at /verify.
Receipt Verifier (public)
No-auth surface. Paste any receipt URL, see hybrid Ed25519 + ML-DSA-65 math.
Provenance protocol white paper
Public draft Q4 2026; RFC submission path Q1 2027.
SynOI Vault reference store
Operator-authoritative substrate. Implements the SRAID provenance protocol. Powers Gateway cache, Decisions, Evidence Journal.
Post-quantum signature path
Hybrid Ed25519 + ML-DSA-65 signing and native verify shipped in Gateway (PR #126). Decision Receipts carry both signatures. Full deployment on Node 24 + OpenSSL 3.5 native path is the production target.
Public log anchoring
OpenTimestamps / Rekor anchor cadence configurable per tenant.
Standards alignment
We did not invent the cryptography.
The protocol semantics are SynOI's contribution; the wire bytes, the signatures, and the transparency-log shape are IETF / NIST / OpenSSF / CSA standards. Every name in the row below is a verifiable upstream, not a logo wall. Procurement and security teams should be able to map every SynOI claim to a public standard.
- CSA· STAR for AI - submission in preparation
- OpenSSF
- sigstore· Rekor + cosign - receipt anchoring (planned)
- in-toto· attestations - SCG produces SLSA-compatible artifacts
- IPLD - content addressing prior art
- IETF· RFC 8949 · CBOR - reserved · future profile
- IETF· RFC 8152 · COSE - reserved · future profile
- IETF· RFC 8032 · Ed25519
- NIST· FIPS 204 · ML-DSA - PQ migration path
- NIST· AI RMF
- ISO/IEC· 42001 - planned
- Linux Foundation· Open Invention Network - planned membership
Full alignment matrix with status and surface for each entry: /standards →
Read the papers
Drafts in flight. Read them; argue with them; cite them.
Public draft · ~40 pp
SynOI Provenance Protocol
Object identity (OID), content-addressed provenance, supersession, point-in-time queries, and canonical JSON wire format. Frames the protocol as a transparency-log primitive in the sigstore Rekor / AWS QLDB / Google Trillian category.
Read the paper →Spec live · Architecture white paper
Supply Chain Guard Architecture
Publisher-side human-in-the-loop (HITL) approval on every npm / PyPI publish, registry-mirror state-divergence detection on the consume side, GitHub App PR-bot, OID Resolver public attestation service. Designed to defeat the Mini Shai-Hulud worm class at publish time. Supply Chain Guard is in active development; public beta Q1 2027.
Read the paper →Draft · ~25 pp
SynOI Trust Model
What you are trusting, in what order, and where you can verify without us. Threat model, custody chains, signature trust roots, anchoring strategy, post-quantum migration path, and the explicit list of properties SynOI does not guarantee.
Read the paper →All papers, including Decision Receipt cryptography, tenant-encrypted deployment, and the SynOI trust model: /whitepapers →
Read the spec. Verify a receipt. Decide for yourself.
The white-paper drafts and the public verifier are linked below. Neither requires an account, an NDA, or a sales call.