imran-siddique · Oct 8, 2026 · Oct 7, 2026 · Oct 7, 2026
@@ -1,6 +1,8 @@
 # Contributing
 
-One directory per integration, one PR per change. Self-serve: you do not need an invitation.
+This page explains how to add an integration, example or demo, and the rules
+every submission has to meet. You do not need an invitation: one directory per
+integration, one pull request per change.
 
 ## Examples and demos
 
@@ -33,7 +35,7 @@ These come from operating large OSS governance projects. PRs that break them are
 1. **Runnable against released packages.** Integrations target published PyPI releases (`cmcp-runtime`, `agentrust-trace`, `agent-manifest`, `weight-custody-manifest`), never forks or unmerged branches.
 2. **Every claim verifiable.** Download counts, user numbers, certifications, "merged into X" - if a reviewer cannot verify it in two minutes, it does not go in. We check. Inflated claims are the fastest way to removal.
 3. **One line of positioning, maximum.** Your README describes what the integration does technically. Marketing copy, comparison tables against competitors, and pricing belong on your site - link it in `integration.yaml`, not here.
-4. **Link only to what an anonymous reader can open.** The WCM source repository is private, so every `github.com/agentrust-io/weight-custody-manifest` URL 404s for anyone outside the org. A WCM integration cites [wcm.agentrust-io.com](https://wcm.agentrust-io.com) and the [PyPI project](https://pypi.org/project/weight-custody-manifest/) instead. Dead links in a README are a review blocker.
+4. **Link only to what an anonymous reader can open.** A link to a private repository, draft or internal page 404s for anyone outside the organization. For WCM, cite [wcm.agentrust-io.com](https://wcm.agentrust-io.com) and the [PyPI project](https://pypi.org/project/weight-custody-manifest/). Dead links in a README are a review blocker.
 5. **TRACE semantics are not negotiable.** If your product emits or consumes TRACE records, it must conform to [trace-spec](https://github.com/agentrust-io/trace-spec) and pass [agentrust-trace-tests](https://pypi.org/project/agentrust-trace-tests/) at the level you claim. A record without a verifiable signature binding is not a TRACE record; calling non-attested output "attested" gets the integration removed.
 6. **You maintain it.** The manifest names a maintainer contact. Integrations that break against a current release and stay broken for 60 days after notice are moved to `attic/`.
 7. **Humans submit, not bots.** Automated submission PRs and issue spam are closed on sight.
@@ -46,8 +48,9 @@ Want the **Verified** tier? Say so in the PR and include exact reproduction step
 
 ## Declaring a WCM integration
 
-WCM is a four-layer protocol, so a single conformance number would say nothing
-useful. Declare instead:
+WCM (Weight Custody Manifest) controls when the key that decrypts a model's
+weights is handed out. It is a four-layer protocol, so a single conformance number
+would say nothing useful. Declare instead:
 
 - `wcm_roles` - what the integration *does*: `manifest-producer`,
   `manifest-verifier`, `key-broker`, `protected-runtime`, `attestation-source`,

@@ -1,5 +1,7 @@
 # Maintainers
 
+This page lists who maintains this repository and reviews changes to it.
+
 ## Repository Maintainers
 
 | Name | GitHub | Appointment |

@@ -5,11 +5,11 @@
 
 Community updates and contributor highlights: [AgenTrust on LinkedIn](https://www.linkedin.com/company/agentrust-io/).
 
-One place to try and integrate cMCP, cA2A, TRACE, Agent Manifest, and WCM. Vendors and community projects integrate here, on their own terms, under published rules - while the core repos stay first-party.
+This repository is where you try the AgenTrust projects and connect them to the tools you already use. It holds runnable examples, short demos, and integrations: small pieces of code that link a product or agent framework to cMCP (rule checks on an agent's tool calls), cA2A (checkable handoffs of work between agents), TRACE (signed receipts of what an agent did), Agent Manifest (a signed record of how an agent is set up) and WCM (model-weight keys released only to checked hardware). Vendors and community projects add their own integrations here under published rules, while the core repositories hold only first-party code. New to the terms? See the [plain-terms list](https://agentrust-io.com/#plain-terms).
 
-Project support is recognized in [SPONSORS.md](SPONSORS.md). Sponsorship is
-separate from marketplace listing, verification tier, maintainership, and
-project governance.
+Sponsors are listed in [SPONSORS.md](SPONSORS.md). Sponsorship has no effect on
+marketplace listings, verification tiers, who maintains the repository, or how
+the project is run.
 
 ## Where things live
 
@@ -31,15 +31,17 @@ See [CONTRIBUTING.md](CONTRIBUTING.md) for the review rules for each directory.
 
 ## Tiers
 
-**Community** - structure-validated and listed. We check that the directory follows the layout, the manifest validates, the links resolve, and the description makes no claims we can falsify. We do not run your code. The listing says exactly that.
+Every listed integration has a tier that tells you how much we checked it.
 
-**Verified** - everything above, plus we ran the integration end-to-end against released packages and confirmed the documented behavior. Verified integrations get the badge in the index and are eligible for the awesome list. Request verification in your PR; re-verification happens at every release that touches your integration.
+**Community** - we checked the structure and listed it. The directory follows the layout, the manifest is valid, the links work, and the description makes no claim we can show to be false. We do not run your code, and the listing says exactly that.
+
+**Verified** - everything above, plus we ran the integration end to end against released packages and confirmed it does what its README says. Verified integrations get the badge in the index and can be listed on the awesome list. Ask for verification in your PR; we check again at every release that touches your integration.
 
 Tier is recorded in each integration's `integration.yaml` and is set by maintainers, never self-declared.
 
 ## The neutrality rule
 
-TRACE only works as a standard if it is genuinely neutral. Integrations are listed on technical merit under identical rules, including products that compete with anything we build. What gets a submission declined is never *who* you are - it is unverifiable claims, misrepresentation, or marketing dressed as documentation. See [CONTRIBUTING.md](CONTRIBUTING.md) for the precise rules.
+TRACE only works as a standard if it is genuinely neutral. Integrations are listed on technical merit under the same rules for everyone, including products that compete with anything we build. A submission is declined for unverifiable claims, misrepresentation, or marketing written as documentation, and never because of *who* sent it. See [CONTRIBUTING.md](CONTRIBUTING.md) for the precise rules.
 
 ## Index
 
@@ -95,6 +97,10 @@ TRACE only works as a standard if it is genuinely neutral. Integrations are list
 
 ### Framework coverage
 
+For each agent framework, this table shows which adapter covers it, where the
+evidence comes from, which released version CI actually runs, and what the
+adapter can and cannot see.
+
 | Framework | Adapter | Evidence source | Released framework exercised in CI | Evidence boundary |
 |---|---|---|---|---|
 | Google ADK | [Google ADK](integrations/google-adk/) | First-party `BasePlugin` lifecycle | Yes - Google ADK 2.7.1 `InMemoryRunner` | Callback-visible invocation, model, and available tool identity; no payloads, retries, agent graph, function-body execution, or policy enforcement |
@@ -105,8 +111,9 @@ TRACE only works as a standard if it is genuinely neutral. Integrations are list
 | Pydantic AI | [OpenTelemetry GenAI](integrations/otel-genai/) | OpenTelemetry GenAI transcription | Yes - Pydantic AI 2.35.1 `TestModel` with a tool call | Telemetry-reported model and tool identity; no payloads; absent `gen_ai.tool.type` is not inferred |
 
 "Adapter exists" and "released framework exercised" are separate claims here.
-First-party hooks produce self-origin records with no `origin` block. Telemetry
-transcriptions carry their weaker evidence boundary explicitly. Each adapter
+First-party hooks (code that runs inside the framework itself) produce
+self-origin records with no `origin` block. Records copied from telemetry are
+weaker evidence and say so explicitly. Each adapter
 README documents what its observation surface can support; a missing concept is
 not inferred into the TRACE record.
 
@@ -124,13 +131,16 @@ which owns fingerprinting, comparison, baseline sealing and the report honesty r
 
 Adapters that build a Trust Record from evidence **another system produced** share
 [`agentrust-trace-adapters`](packages/agentrust-trace-adapters). Records built through it
-carry `origin.kind: third-party-control-plane`, `runtime.platform: software-only` and
-`appraisal.status: none`, so the assurance downgrade is something a consumer reads from
-the record rather than from a README. None of the three is a parameter.
+are always marked as coming from another system, software-only and unappraised
+(`origin.kind: third-party-control-plane`, `runtime.platform: software-only` and
+`appraisal.status: none`), so a consumer reads the weaker assurance from the record
+itself rather than from a README. None of the three is a parameter you can change.
 
 **Note on the Copilot, Cursor, Windsurf and Gemini CLI entries.** Each is a
-pull-request status check rather than a session hook, because all four agents'
-composition lives in the repository rather than a developer's home directory.
+check that runs on pull requests rather than a hook in a developer's session,
+because all four agents' composition (the instructions, rules, skills and tools
+configured for the agent) lives in the repository rather than a developer's home
+directory.
 Each emits no TRACE record and no Agent Manifest, so each claims neither. None
 currently produces or consumes one of the supported AgenTrust artifacts or
 protocols, and asserting otherwise would be an unverifiable claim.

@@ -1,7 +1,11 @@
 # Sponsors
 
+This page lists who supports AgenTrust Integrations and how sponsorship is kept
+apart from listing and review decisions.
+
 AgenTrust Integrations is an open-source project. Sponsors provide funding,
-engineering time, infrastructure, or other in-kind support. Sponsorship does
+engineering time, infrastructure, or other in-kind support. OPAQUE Systems is the
+current sponsor, and further sponsors are welcome. Sponsorship does
 not confer project ownership, governance authority, marketplace preference, or
 control over technical decisions.
 

@@ -2,7 +2,7 @@
 
 Community updates and contributor highlights: [AgenTrust on LinkedIn](https://www.linkedin.com/company/agentrust-io/).
 
-Runnable demos for [cMCP](https://github.com/agentrust-io/cmcp), [TRACE](https://github.com/agentrust-io/trace-spec), and [WCM](https://pypi.org/project/weight-custody-manifest/). Ten demos, ~12 minutes total.
+Short demos you can run on your own computer to see [cMCP](https://github.com/agentrust-io/cmcp) check an agent's tool calls against policy, [TRACE](https://github.com/agentrust-io/trace-spec) produce signed receipts you can verify offline, and [WCM](https://pypi.org/project/weight-custody-manifest/) control the release of model-weight keys. Ten demos, about 12 minutes in total.
 
 Project support is recognized in [SPONSORS.md](SPONSORS.md). Sponsorship is
 separate from demo authorship, fixture identities, and project governance.

@@ -1,5 +1,9 @@
 # Ecosystem Evaluation: 2026-08-24
 
+This is a record of a review on 2026-08-24 of four outside projects. For each, it
+says whether the project only belongs on the governance resource list or whether
+AgenTrust should build a real, tested integration, and what has to happen next.
+
 Purpose: distinguish projects that belong in the governance resource list from
 projects for which AgenTrust has built and tested a real integration.
 

@@ -1,5 +1,9 @@
 # Examples and demos consolidation
 
+The separate examples and demos repositories were merged into this one. This page
+records what was copied from where, which licenses still apply, how review works
+now, and the steps for retiring the old repositories.
+
 The canonical working repository is agentrust-io/integrations. Its existing
 adapter and package paths remain supported. First-party scenarios live in
 examples/, short demonstrations in demos/, and vendor submissions in integrations/.

@@ -8,7 +8,7 @@
 
 Community updates and contributor highlights: [AgenTrust on LinkedIn](https://www.linkedin.com/company/agentrust-io/).
 
-End-to-end integration examples showing cMCP, Agent Manifest, and TRACE working together across deployment scenarios. Each example is self-contained and runnable on a fresh cloud VM. Running them shows how the projects compose: cMCP enforces policy at the tool call boundary, Agent Manifest carries the identity and capability declaration, cA2A attenuates authority at the agent-to-agent boundary, and TRACE emits a signed Trust Record for every tool invocation so you can see what the full audit trail looks like in practice.
+Complete, runnable scenarios that show the AgenTrust projects working together, for example in financial services, healthcare and agentic commerce. Each example is self-contained and runs on a fresh cloud VM. Running one shows how the pieces fit: cMCP checks each tool call against policy, Agent Manifest records who the agent is and what it may do, cA2A makes sure an agent handing work to another passes on no more authority than it has, and TRACE writes a signed Trust Record (a receipt) for every tool call, so you can see what the full audit trail looks like in practice.
 
 Project support is recognized in [SPONSORS.md](SPONSORS.md). Sponsorship is
 separate from example authorship, fixture identities, partner provenance,

@@ -1,8 +1,11 @@
 # AgenTrust for Codex
 
-A Codex plugin that fingerprints the agent configuration in each workspace,
-warns when that composition changes, and creates signed Agent Manifest and
-TRACE Level 0 records on request.
+A Codex plugin that tells you, at the start of each session, whether your
+agent's setup in this workspace (its instructions, skills, hooks, plugins and
+tools) has changed since you approved it. It does this by fingerprinting each
+part and comparing it with the approved baseline. On request it also creates a
+signed Agent Manifest (a record of the setup) and a signed TRACE Level 0 record
+for the session.
 
 ## Install
 

@@ -13,9 +13,9 @@ announces itself.
 This plugin fingerprints the things that run **without you watching** and warns
 you the moment any of them drifts from a baseline you approved:
 
-- **routines** — declared scheduled-agent specs: schedule, allowed tools, MCP
+- **routines**: declared scheduled-agent specs: schedule, allowed tools, MCP
   servers, prompt, model.
-- **hooks** — the commands in `~/.claude/settings.json` that auto-run on events
+- **hooks**: the commands in `~/.claude/settings.json` that auto-run on events
   (`SessionStart`, `PreToolUse`, …).
 
 ## Install
@@ -38,10 +38,10 @@ Run /schedule-manifest verify for detail, or /schedule-manifest approve to accep
 
 Then:
 
-- `/schedule-manifest verify` — show exactly what changed, in plain English.
-- `/schedule-manifest approve` — accept the current surface as the new baseline.
-- `/schedule-manifest show` — display the surface without touching the baseline.
-- `/schedule-trace` — write a signed, third-party-verifiable TRACE record.
+- `/schedule-manifest verify`: show exactly what changed, in plain English.
+- `/schedule-manifest approve`: accept the current surface as the new baseline.
+- `/schedule-manifest show`: display the surface without touching the baseline.
+- `/schedule-trace`: write a signed, third-party-verifiable TRACE record.
 
 ## Declaring a routine
 
@@ -68,15 +68,15 @@ approved file is the source of truth, and drift is any later change to it.
 
 ## What it records, and what it does not
 
-It records **names and fingerprints only** — routine, tool, MCP, and hook-command
+It records **names and fingerprints only**: routine, tool, MCP, and hook-command
 names, and SHA-256 hashes of prompts and settings. It never stores secrets, never
 reads your credentials file, and never records a hook command's output.
 
 ## Honest scope
 
 - This baselines the **declared** routine specs and the **on-disk** hooks, and
   detects drift in those declarations. It does not introspect a live cloud
-  routine's runtime behaviour — no software running on a normal dev box can prove
+  routine's runtime behaviour; no software running on a normal dev box can prove
   that.
 - On a normal dev box this is **software integrity, Level 0**, never presented as
   hardware-attested. `/schedule-trace` records `runtime.platform: software-only`

@@ -1,6 +1,6 @@
 # Shadow AI Discovery
 
-Compares enriched tool-call audit records against a separate agent-to-tools registry and reports unregistered agents and undeclared tools. It does not read cMCP output directly; see [Inputs and limitations](#inputs-and-limitations).
+Finds AI agents and tool use that nobody registered. It reads tool-call audit records (with agent IDs added) and compares them with a separate registry that lists each agent and the tools it is allowed to use, then reports agents that are not in the registry and tools an agent was never declared to use. It does not read cMCP output directly; see [Inputs and limitations](#inputs-and-limitations).
 
 This is standalone tooling, outside the integration index and Marketplace. It
 has no working cMCP or Agent Manifest adapter and claims neither integration.