Your roadmap's "Later" list includes "anchoring into an external transparency log, so this registry's own history is witnessed by something outside it." We operate exactly that and it's open to everyone: witness.agentactioncapsule.org — a vendor-neutral witness/Transparency Service (SCITT architecture, RFC 9943; COSE Receipts, RFC 9942) that counter-signs a submitted checkpoint and returns a receipt verifiable offline. It's payload-agnostic — it witnesses any log's checkpoints the same way, so this isn't a TRACE-specific arrangement; it's your log using neutral infrastructure that's open to all.
The right grain is checkpoints, not payloads. Once the CLL checkpoint work here (#51) is in, each checkpoint interval posts one signed commitment — the checkpoint's COSE_Sign1 with its accumulator commitment — and gets a receipt back. That externally witnesses your entire history at one small post per interval, with zero payload disclosure: your claim data never leaves your side. A third party then verifies any single record by chaining: your inclusion proof → your signed checkpoint → the witness receipt over it — against a service you don't operate, which is precisely the property your roadmap item names. (The checkpoint discipline itself is specified in the CLL Internet-Draft, posting shortly; #51 already implements its shape.)
One datapoint worth having on the record: the checkpoint verification here and our independent verifier already check each other's output bidirectionally — so this arrangement would also give the registry the second-implementor property your roadmap asks about, for the checkpoint layer at least.
No lock-in, stated plainly: receipts verify offline against open specs; you can witness into multiple services in parallel, mirror, or stop at any time; and witnessing a digest is attestation of inclusion and time, never an endorsement of content — the same rule our witness applies to everyone. If useful, we'll sketch the exact checkpoint→witness call once #51 lands — it's small.
Your roadmap's "Later" list includes "anchoring into an external transparency log, so this registry's own history is witnessed by something outside it." We operate exactly that and it's open to everyone: witness.agentactioncapsule.org — a vendor-neutral witness/Transparency Service (SCITT architecture, RFC 9943; COSE Receipts, RFC 9942) that counter-signs a submitted checkpoint and returns a receipt verifiable offline. It's payload-agnostic — it witnesses any log's checkpoints the same way, so this isn't a TRACE-specific arrangement; it's your log using neutral infrastructure that's open to all.
The right grain is checkpoints, not payloads. Once the CLL checkpoint work here (#51) is in, each checkpoint interval posts one signed commitment — the checkpoint's COSE_Sign1 with its accumulator commitment — and gets a receipt back. That externally witnesses your entire history at one small post per interval, with zero payload disclosure: your claim data never leaves your side. A third party then verifies any single record by chaining: your inclusion proof → your signed checkpoint → the witness receipt over it — against a service you don't operate, which is precisely the property your roadmap item names. (The checkpoint discipline itself is specified in the CLL Internet-Draft, posting shortly; #51 already implements its shape.)
One datapoint worth having on the record: the checkpoint verification here and our independent verifier already check each other's output bidirectionally — so this arrangement would also give the registry the second-implementor property your roadmap asks about, for the checkpoint layer at least.
No lock-in, stated plainly: receipts verify offline against open specs; you can witness into multiple services in parallel, mirror, or stop at any time; and witnessing a digest is attestation of inclusion and time, never an endorsement of content — the same rule our witness applies to everyone. If useful, we'll sketch the exact checkpoint→witness call once #51 lands — it's small.