From 7a45dbec69589644b90858b21243a64dd4fe2037 Mon Sep 17 00:00:00 2001 From: Imran Siddique Date: Mon, 7 Sep 2026 19:07:37 -0700 Subject: [PATCH 1/2] docs: add registry discovery and verified witness proof boundaries --- design-system.css | 8 +++++--- index.html | 17 +++++++++++++++++ registry/index.html | 21 +++++++++++++++------ 3 files changed, 37 insertions(+), 9 deletions(-) diff --git a/design-system.css b/design-system.css index 8935a0e..44dfb6e 100644 --- a/design-system.css +++ b/design-system.css @@ -2028,9 +2028,10 @@ html:has(body.agentrust-hub) { scroll-behavior: smooth; } .architecture-node { display: flex; flex-direction: column; justify-content: center; gap: .65rem; padding: 1.25rem; border: 1px solid var(--at-line); background: var(--at-white); min-width: 0; } .architecture-boundary { border: 2px dashed var(--at-navy); } .architecture-edge { align-self: center; font-size: .8rem; font-weight: 650; white-space: nowrap; } -.architecture-outcomes { display: grid; grid-template-columns: repeat(3, 1fr); border: 1px solid var(--at-line); background: var(--at-white); } +.architecture-outcomes { display: grid; grid-template-columns: repeat(2, minmax(0, 1fr)); border: 1px solid var(--at-line); background: var(--at-white); } .architecture-outcomes > div { padding: 1.25rem; } -.architecture-outcomes > div + div { border-left: 1px solid var(--at-line); } +.architecture-outcomes > div:nth-child(even) { border-left: 1px solid var(--at-line); } +.architecture-outcomes > div:nth-child(n+3) { border-top: 1px solid var(--at-line); } .architecture span, .architecture p, .architecture small, .architecture figcaption { font-size: .9rem; line-height: 1.6; } .architecture p { margin-bottom: 0; } .architecture figcaption { margin-top: 1rem; color: var(--at-muted); } @@ -2046,7 +2047,8 @@ html:has(body.agentrust-hub) { scroll-behavior: smooth; } .architecture-row, .architecture-outcomes { grid-template-columns: 1fr; } .architecture-edge { justify-self: center; margin-block: .25rem; } .architecture-edge .direction { display: inline-block; transform: rotate(90deg); } - .architecture-outcomes > div + div { border-left: 0; border-top: 1px solid var(--at-line); } + .architecture-outcomes > div:nth-child(even) { border-left: 0; } + .architecture-outcomes > div + div { border-top: 1px solid var(--at-line); } .agentrust-hub .hero-actions { gap: .75rem; } .agentrust-hub .hero-actions .btn { text-align: center; white-space: normal; } } diff --git a/index.html b/index.html index 651ce4d..8da9c95 100644 --- a/index.html +++ b/index.html @@ -213,6 +213,7 @@
  • Start here
  • Specifications
    • Technology overview
      • +
    • TRACE Registry
    • Runtime evidence (TRACE)
    • Agent identity (Manifest)
    • Tool-call governance (cMCP)
      • @@ -287,6 +288,7 @@

      Where policy runs. Where evidence goes.

      Deny → return an error

      The runtime does not forward a denied call to the tool server.

      Session record → TRACE verifier

      Check signed evidence against trusted keys, expected policy, and the required attestation level.

      +
      Optional anchoring → TRACE Registry

      Publish commitments and verify inclusion under signed checkpoints. Independent witness receipts add an external observation; they do not certify the record's claims.

      Optional delegation → cA2A peer

      A separate agent-to-agent path narrows delegated authority and links provenance across hops.

      Tool-call path and evidence path. Protecting the runtime does not put the model, agent process, or upstream tool server inside its TEE.
      @@ -482,6 +484,17 @@

      Specifications, protocols, and shared building blocks< + + +
      +
      +
      Evidence Infrastructure
      +
      TRACE Registry
      +
      A public, append-only registry of anchors, checkpointed on activity and signed by the registry key. Record holders retain their evidence; the published registry contains commitments. Offline verifier on PyPI; no hosted query endpoint. Supports independent witnesses, with one checkpoint receipt demonstrated.
      +
      +
      agentrust-io.com/registryLive
      +       +
      @@ -661,6 +674,10 @@

      Test Suite & Tooling

      What's Launched

      +
      +
      Registry briefing · September 9, 2026
      +
      TRACE Registry + verified checkpoint receipt
      +
      Attestation Standard
      TRACE v0.2
      diff --git a/registry/index.html b/registry/index.html index fe4f740..99893bd 100644 --- a/registry/index.html +++ b/registry/index.html @@ -77,9 +77,9 @@

      Check the published history
      of agent evidence

      2Published entries 1Signed checkpoint 0.3.1Verifier on PyPI - 225Tests passing + 1External checkpoint receipt
      -

      Historical snapshot at 4697f2c: two demonstration entries, one checkpoint, and 225 passing tests. These figures are not live counters. Check the repository for subsequent entries and test results.

      +

      Two published entries and one checkpoint, counted at registry commit 6138335. Neither entry is production evidence. Checkpoint 1 has a separately fetched, offline-verified external receipt. PyPI currently publishes trace-verify 0.3.1; the witness receipt tool and its dependency lock are in the registry repository.

      @@ -141,13 +141,22 @@

      The verifier checks append-only growth

      4

      A signed checkpoint commits to the history

      -

      The scheduled anchor pipeline emits a signed checkpoint carrying the log's size and root plus the previous checkpoint's size and root. That chained pair is what lets a third party check that each checkpoint extends the last rather than replaces it.

      +

      The scheduled anchor pipeline emits a signed checkpoint carrying the log's size and root plus the previous checkpoint's size and root. A verifier checks predecessor linkage and the MMR consistency proof, then recomputes the covered entries. Equality of the previous size and root alone does not prove append-only growth.

      +
      + Independent witnesses +

      One checkpoint, one verified external receipt

      +

      Checkpoint 1's signing-body digest is included under a Merkle root signed by a separately operated witness. The returned receipt and two independently fetched copies agree; verification runs offline against an explicitly pinned witness key. This was demonstrated on September 7, 2026, ahead of the September 9 briefing.

      +

      The response reports countersigned-observed. That grade is unsigned response metadata. The receipt has no signed witness timestamp and does not certify registry continuity. It authenticates inclusion of the signing-body digest, with the registry signature checked separately.

      +

      No recurring witness submission, reciprocal witnessing, or second witness is claimed. Parallel independent witnesses remain a deployment choice; original records stay with their holders.

      + Receipt, key provenance and offline verification +
      +
      Check our work

      The verification runs on your machine, not ours

      @@ -215,11 +224,11 @@

      What a registry entry is, and what it is not

      LimitWhy it stands Consistency, not coverageThe checkpoint chain proves the consistency of what it covers. It does not prove that the registry covers everything it could have. Completeness is a property of producers keeping their own records, not something a log can assert about itself. The June 2026 entry is outside the chainIt predates checkpointing and is deliberately not folded in retroactively, which is the same rule the chain verifier applies. Backdating an entry into a chain would make the chain say more than it checked. - No external witness receipt yetAnchoring the registry's own history into a transparency service the registry does not operate is in progress in public, and no receipt has come back and verified offline yet. Until one has, the anti-split-view property is a roadmap item, not a feature. + One receipt; bounded assuranceThe captured receipt proves inclusion of checkpoint 1's signing-body digest under the accepted witness key. It does not authenticate the response grade, establish a witness time, certify continuity, prevent split views, or cover the June entry. See the evidence packet and verifier results. One producer key is single-use by constructionThe producer key behind the first anchored record verifies that record and will never sign another, because the demo that produced it generates keys per run and never persists private ones. That is a property of that entry, not a general guarantee. -

      A witness attesting to more than it checked is worse than no witness. That principle is why the limits above are on this page instead of in a footnote, why the entry counts here are the real ones, and why an external receipt will be announced when it verifies rather than when it is arranged.

      +

      A witness attesting to more than it checked is worse than no witness. That principle is why the limits above are on this page instead of in a footnote, why the entry counts here are the real ones, and why the receipt announcement names exactly which properties were verified.

      Full limitations ↗Terms of use ↗Governance ↗Roadmap ↗

      @@ -229,7 +238,7 @@

      What a registry entry is, and what it is not

      Three ways in

      Register as a producer

      Publish anchors for your own signed trust records under your own key. The conventions, naming, and submission path are documented in the repository.

      Read the contributor guide →
      -

      Run a mirror or a witness

      Single-operator dependency is a weakness we name rather than hide. Independent mirrors and independent witnesses both remove it, and both are open to anyone.

      Mirroring guide →
      +

      Run a mirror or a witness

      Single-operator dependency is a weakness we name rather than hide. Independent mirrors and independent witnesses can reduce it when observers retain and compare evidence. Neither is a blanket guarantee against split views.

      Mirroring guide →

      Attack the claims

      The most useful contribution is a demonstration that something on this page overstates what the code actually does. Open an issue in public.

      Open an issue →
      From 580f13d4e405624e15029b2fca290a5cd11ce32a Mon Sep 17 00:00:00 2001 From: Imran Siddique Date: Tue, 8 Sep 2026 16:03:00 -0700 Subject: [PATCH 2/2] docs: pin the registry counts to the merged evidence commit Registry PR #68 merged as ee57e71, which is the first commit whose tree contains the witness evidence packet and the receipt tool. Point the proof note there so every claim in it holds at the pinned commit. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01RMuXK1es7dsRsPtvC5Tkpd --- registry/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/registry/index.html b/registry/index.html index 99893bd..1d13e42 100644 --- a/registry/index.html +++ b/registry/index.html @@ -79,7 +79,7 @@

      Check the published history
      of agent evidence

      0.3.1Verifier on PyPI 1External checkpoint receipt -

      Two published entries and one checkpoint, counted at registry commit 6138335. Neither entry is production evidence. Checkpoint 1 has a separately fetched, offline-verified external receipt. PyPI currently publishes trace-verify 0.3.1; the witness receipt tool and its dependency lock are in the registry repository.

      +

      Two published entries and one checkpoint, counted at registry commit ee57e71. Neither entry is production evidence. Checkpoint 1 has a separately fetched, offline-verified external receipt. PyPI currently publishes trace-verify 0.3.1; the witness receipt tool and its dependency lock are in the registry repository.