diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index bafad21a..ab301020 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,5 +1,7 @@
 # Contributing to TRACE
 
+This page explains how to propose a change to TRACE and what reviewers will ask for. Small fixes such as typos and broken links can go straight to a pull request; changes to the rules every implementation must follow need more discussion and a named organization behind them, as described below.
+
 TRACE is an open specification. Contributions are welcome in four areas: the specification text, the JSON Schema, the examples, and the conformance test suite (in [trace-spec/conformance](https://github.com/agentrust-io/trace-spec/tree/main/conformance)).
 
 ## Running the reference-library checks
@@ -31,6 +33,8 @@ The check you just fixed is not that something.
 
 ## Before a pull request is reviewed
 
+In short: the automated tests must pass, and a bug fix must come with a test that would have caught the bug.
+
 A pull request gets a full review once every `test` job of the `CI` workflow,
 which runs the checks above, succeeds on its head commit. Other checks on the
 pull request, such as the maintainer-approval gate, do not hold a review,
@@ -86,7 +90,7 @@ This adds `Signed-off-by: Your Name <you@example.com>`. PRs without DCO sign-off
 
 ### Spec changes (normative text)
 
-Changes to `spec/trace-v0.2.md` that affect what implementations must do. Normative text is any statement using an RFC 2119 keyword in uppercase: what a conformant implementation MUST, SHOULD or MAY do. A normative change binds every implementation of TRACE, including implementations whose authors are not in the discussion.
+These are changes to the rules every TRACE implementation has to follow, so they carry the most weight and the most process. Changes to `spec/trace-v0.2.md` that affect what implementations must do. Normative text is any statement using an RFC 2119 keyword in uppercase: what a conformant implementation MUST, SHOULD or MAY do. A normative change binds every implementation of TRACE, including implementations whose authors are not in the discussion.
 
 **Anyone may propose a Normative Change, however only Normative Contributions with an organizational sponsor willing to implement and maintain that element in the specification will be accepted.**
 
diff --git a/LIMITATIONS.md b/LIMITATIONS.md
index bef48af1..98b3c7dc 100644
--- a/LIMITATIONS.md
+++ b/LIMITATIONS.md
@@ -1,35 +1,37 @@
 # Known Limitations
 
-This document describes what TRACE does not do, and where layered defenses are needed. Honest scope boundaries prevent misplaced trust.
+This page lists what TRACE does not do, so you know where you still need other safeguards. Read it before you rely on a TRACE record for anything that matters. A TRACE record (also called a Trust Record or claim) is a signed receipt describing one AI agent run; most of what follows is about the gap between "this receipt is genuine" and "what it describes really happened".
 
 ## What a TRACE claim does not prevent
 
 **Operator-forged software-only records**
-A TRACE claim at Level 0 (software-only signing) is signed by a key held in software. A privileged operator with root access can produce a valid-looking Level 0 record for a run that never happened, or that violated policy. Level 0 is suitable for development and audit-trail tooling only, not for third-party verification.
+Level 0 is the entry level, where a record is signed with an ordinary software key and no hardware evidence. Whoever runs the machine can read that key. A privileged operator with root access can produce a valid-looking Level 0 record for a run that never happened, or that violated policy. Level 0 is suitable for development and audit-trail tooling only, not for third-party verification.
 
 **Replay of a valid past record**
-A TRACE claim proves a specific run happened; it does not prevent a verifier from being shown a valid record from an earlier run. Verifiers that rely on recency must bound `iat` in both directions (maximum age and allowed future clock skew), check `exp` when present, require nonce binding to a challenge, or anchor records to a public transparency log and check for freshness.
+A genuine old record stays genuine, so someone can show you last week's record and pass it off as today's. A TRACE claim proves a specific run happened; it does not prevent a verifier from being shown a valid record from an earlier run. Verifiers that rely on recency must bound `iat` in both directions (maximum age and allowed future clock skew), check `exp` when present, require nonce binding to a challenge, or anchor records to a public transparency log and check for freshness.
 
 **Policy correctness**
-The `policy.bundle_hash` field attests that a specific policy was in force at runtime. It does not attest that the policy achieves the intended security outcome. Policy review is a separate control.
+A record can show which rules the agent ran under, but not whether those rules were any good. The `policy.bundle_hash` field attests that a specific policy was in force at runtime. It does not attest that the policy achieves the intended security outcome. Policy review is a separate control.
 
 **What happened inside the model**
-The call transcript records tool invocations, arguments, and responses that are observable at the gateway boundary. It does not record the model's internal chain-of-thought, intermediate reasoning, or context window contents. Reasoning that influences behavior without producing a tool call is not captured.
+TRACE sees what the agent did, not what the model thought. The call transcript records tool invocations, arguments, and responses that are observable at the gateway boundary. It does not record the model's internal chain-of-thought, intermediate reasoning, or context window contents. Reasoning that influences behavior without producing a tool call is not captured.
 
 **Cross-boundary data propagation**
-The call graph summary uses temporal adjacency to approximate data flow between tool calls. It cannot definitively prove which specific data from one tool response influenced which subsequent call. The `provenance_disclaimer` field in every call graph summary is required for this reason.
+TRACE can show that one tool call came after another, but not prove that data from the first actually fed the second. The call graph summary uses temporal adjacency to approximate data flow between tool calls. It cannot definitively prove which specific data from one tool response influenced which subsequent call. The `provenance_disclaimer` field in every call graph summary is required for this reason.
 
 **TEE side-channel attacks**
-Hardware attestation proves the TRACE signing key and policy engine were measured in silicon before execution. It does not protect against side-channel attacks (cache timing, power analysis) targeting the TEE itself. TEE-level side-channel defense is the responsibility of the TEE platform vendor.
+A TEE (trusted execution environment) is a sealed area of a processor that even the machine's operator cannot look into. Hardware attestation, the processor's signed report of what is running inside it, proves the TRACE signing key and policy engine were measured in silicon before execution. It does not protect against side-channel attacks (cache timing, power analysis) targeting the TEE itself. TEE-level side-channel defense is the responsibility of the TEE platform vendor.
 
 **Revocation of the signing key after issuance**
-If the TRACE signing key is compromised after records are issued, existing records remain cryptographically valid. Key monitoring, rapid revocation, and transparency log integration are the required controls: TRACE provides the anchoring mechanism but cannot detect compromise itself.
+If a signing key is stolen later, everything it already signed still checks out. If the TRACE signing key is compromised after records are issued, existing records remain cryptographically valid. Key monitoring, rapid revocation, and transparency log integration are the required controls: TRACE provides the anchoring mechanism but cannot detect compromise itself.
 
 **Pure offline verification cannot prove non-revocation**
-Signature validity is permanent; trust is not. Nothing inside a record can retract the key that signed it, so a record signed by a since-revoked key verifies offline forever. Spec §3.2.1 accordingly requires verifiers to consult current revocation status at verification time, which is by definition an online step. `verify_record()` takes a `revocation` store, either a container of revoked identifiers or a callable performing a live CRL, status-endpoint, or SCITT lookup. It rejects a listed key, and fails closed when the store cannot answer. Without that store, verification is offline and its result means "this record was validly signed by this key", not "this key is still trusted".
+Checking a record with no network connection tells you it was signed by a given key, but not whether that key has since been withdrawn. Signature validity is permanent; trust is not. Nothing inside a record can retract the key that signed it, so a record signed by a since-revoked key verifies offline forever. Spec §3.2.1 accordingly requires verifiers to consult current revocation status at verification time, which is by definition an online step. `verify_record()` takes a `revocation` store, either a container of revoked identifiers or a callable performing a live CRL, status-endpoint, or SCITT lookup. It rejects a listed key, and fails closed when the store cannot answer. Without that store, verification is offline and its result means "this record was validly signed by this key", not "this key is still trusted".
 
 ## Platform state is not appraised
 
+An AMD processor's signed report says which software is running and, separately, how the machine itself is configured. The checks described here cover the first part only, so a report from a machine with weaker security settings passes just as cleanly.
+
 <!-- This is the source copy of the marked block. cmcp and ca2a carry it
      verbatim and their limitations-parity workflows check it against this
      file, so a change here has to land before theirs. The paragraph after
@@ -64,12 +66,14 @@ appraise it even where the producer checked it. The spec does not assert it for
 
 ## What Level 0 does not provide
 
-Level 0 provides software signatures without hardware-rooted assurance. A privileged operator may extract the signing key; a valid signature does not establish that execution was protected by a TEE.
+Level 0 is useful for development and for keeping an audit trail, but it is not evidence an outside party should accept on its own. Level 0 provides software signatures without hardware-rooted assurance. A privileged operator may extract the signing key; a valid signature does not establish that execution was protected by a TEE.
 
-TRACE verification levels describe technical evidence, not legal compliance. Article 12 of the EU AI Act requires a logging capability; it does not prescribe a TRACE level or tamper-evident format. See the [regulatory context in the specification](spec/trace-v0.2.md#1-problem). Neither a TRACE level nor transparency-log anchoring alone establishes compliance with the EU AI Act or DORA. Deployment-specific obligations require a separate assessment.
+TRACE levels describe the strength of technical evidence; they say nothing about legal compliance. Article 12 of the EU AI Act requires a logging capability; it does not prescribe a TRACE level or tamper-evident format. See the [regulatory context in the specification](spec/trace-v0.2.md#1-problem). Neither a TRACE level nor transparency-log anchoring alone establishes compliance with the EU AI Act or DORA. Deployment-specific obligations require a separate assessment.
 
 ## What the SDK does not do
 
+The SDK is the `agentrust-trace` Python library that signs and checks records. These jobs sit outside it:
+
 - **Evaluate Cedar policy**: the SDK includes the Cedar policy field in the claim; evaluation requires the Cedar engine (included in AGT or cMCP)
 - **Store or index records**: the SDK produces and verifies TRACE claim documents; storage, rotation, and retrieval are the caller's responsibility
 - **Anchor to a transparency log**: the SDK generates records suitable for SCITT anchoring; submission to a transparency log requires a separate SCITT client
@@ -78,7 +82,7 @@ TRACE verification levels describe technical evidence, not legal compliance. Art
 
 ## Performance
 
-Hardware attestation adds latency at the point of claim generation (not per-tool-call):
+Hardware evidence makes signing a record slower, once per record rather than on every tool call:
 
 | Provider | Typical claim signing latency |
 |---|---|
diff --git a/MAINTAINERS.md b/MAINTAINERS.md
index ea1a25af..e814316f 100644
--- a/MAINTAINERS.md
+++ b/MAINTAINERS.md
@@ -1,5 +1,7 @@
 # Maintainers
 
+This page lists who reviews and decides changes to TRACE, and how a regular contributor can take on one of those roles.
+
 ## Project Lead
 
 | Name | Affiliation | GitHub | Contact |
diff --git a/README.md b/README.md
index 293db916..74a30f25 100644
--- a/README.md
+++ b/README.md
@@ -33,9 +33,9 @@ Community updates and contributor highlights: [AgenTrust on LinkedIn](https://ww
 
 > **Developer Preview.** Launched at Confidential Computing Summit, 23 June 2026. Spec v0.2 is current. See [LIMITATIONS.md](LIMITATIONS.md) before relying on it in production.
 
-An open specification for portable, signed runtime evidence about AI agent runs. TRACE defines the format, anchoring protocol, and verification rules for a record of what an agent ran, where, under which policy, touching which data, and calling which tools, signed so any third party can check it offline. A v0.2 signature proves who produced a record and that it has not changed; hardware provenance needs attestation verified against a trusted root, which the proposed [v0.3 runtime evidence profile](docs/rfcs/runtime-evidence-profile.md) adds.
+TRACE is an open format for a signed receipt of an AI agent run: what ran, where, under which rules, on what kind of data, and which tools it called. Anyone holding the receipt (a Trust Record) can check it on their own computer, without asking the operator. This repository holds the specification, the JSON schema, test vectors and the `agentrust-trace` Python library.
 
-A TRACE Trust Record answers: _what ran, where, under which policy, touching which data, calling which tools_, in a form any third party can check offline without asking the operator.
+A v0.2 signature proves who made a record and that it has not changed. It does not prove the hardware claims inside it: that needs a signed report from the processor itself (attestation), checked against the chip maker's root certificate, which the proposed [v0.3 runtime evidence profile](docs/rfcs/runtime-evidence-profile.md) adds.
 
 ## What a Trust Record claims
 
@@ -100,7 +100,7 @@ Hosted at the Linux Foundation as its own series, "TRACE Specification, a Series
 
 ### What is TRACE?
 
-TRACE (Trust, Runtime Attestation, and Compliance Evidence) is an open specification for hardware-attested AI agent governance records. It defines the record format, the anchoring protocol, and the verification rules for cryptographic evidence that an AI agent ran under a specific policy, in a verified hardware environment, on a given data class, invoking identified tools.
+TRACE (Trust, Runtime Attestation, and Compliance Evidence) is an open specification for signed records of AI agent runs. It defines the record format, how records are published to a public log, and the rules for checking them. A record states that an agent ran under a specific policy, on a stated platform, on a given class of data, calling identified tools; the signature makes those statements tamper-evident, and hardware attestation, where present, is what backs the platform claim.
 
 ### What does a TRACE Trust Record prove?
 
@@ -116,11 +116,11 @@ Install the library with `pip install agentrust-trace`, sign a record with `sign
 
 ### How does TRACE relate to AGT and cMCP?
 
-TRACE is the evidence format. AGT and cMCP produce and consume Trust Records, so you can connect them into an end-to-end agent governance pipeline. See the integration guides for details.
+TRACE is the evidence format. AGT and cMCP write and read Trust Records, so you can connect them so that every agent action ends in a record someone else can check. See the integration guides for details.
 
 ### What is the current status of TRACE?
 
-The current specification is TRACE v0.2, published with a conformance test suite. See the Limitations page for scope boundaries before relying on it in production.
+The current specification is TRACE v0.2, published with a conformance test suite, as a Developer Preview. TRACE is a Series of LF Projects, and a proposal to bring it into the Agentic AI Foundation as a Sandbox project is in progress ([aaif/project-proposals #42](https://github.com/aaif/project-proposals/issues/42)). See the Limitations page for what it does not cover before relying on it in production.
 
 ## Contributing
 
diff --git a/ROADMAP.md b/ROADMAP.md
index f33ba74b..ca2cca5c 100644
--- a/ROADMAP.md
+++ b/ROADMAP.md
@@ -1,9 +1,13 @@
 # Roadmap
 
-Status as of September 2026. Spec **v0.2** is current ([`spec/trace-v0.2.md`](spec/trace-v0.2.md)); the `agentrust-trace` reference SDK is at **0.11.0** and the conformance suite (`trace-spec/conformance`) at **0.5.1**.
+This page shows what TRACE already does, what comes next, and what it will never try to do. It is for anyone deciding whether TRACE fits their plans, or looking for a place to help.
+
+Status as of October 2026. Spec **v0.2** is current ([`spec/trace-v0.2.md`](spec/trace-v0.2.md)); the `agentrust-trace` reference SDK (the Python library) is at **0.11.0** and the conformance suite (`trace-spec/conformance`, the tests that score an implementation) at **0.6.2**.
 
 ## Shipped: v0.2 (July to August 2026)
 
+In short: v0.2 fixed the record's identifier, added links between records when one agent hands work to another, published the format for anchoring records in a public log, and added connectors for AGT, cMCP and sandboxed agent runtimes. The detail follows.
+
 - **EAT profile URI cutover** to `tag:agentrust-io.com,2026:trace-v0.2`. The v0.1 identifier named a domain this project never controlled, which RFC 4151 does not permit, so it was invalid rather than misspelled. A v0.2 verifier requires the new URI and rejects the old one; `verify_record()` enforces the cutover before any cryptographic work. Records issued under v0.1 stay verifiable against `spec/trace-v0.1.md` and the published 0.4.x releases.
 - **`delegation` link block** (`parent_record_hash` + `credential_id`), optional and additive. A chain of records linked this way forms an offline-verifiable delegation DAG. This is the foundation the A2A profile binds to, not the profile itself.
 - **`transparency` is optional below Level 2.** A Level 0 or Level 1 record is unanchored and has no receipt to name; that state was previously unrepresentable.
@@ -19,6 +23,8 @@ Status as of September 2026. Spec **v0.2** is current ([`spec/trace-v0.2.md`](sp
 
 ## Next: v0.3
 
+In short: the next version defines exactly how TRACE records describe tool calls (MCP) and agent-to-agent hand-offs (A2A), and starts on evidence for an agent's memory, encrypted records and vendor-specific hardware notes.
+
 - **MCP profile (normative)**: the [requirements proposal](spec/mcp-profile-v0.3-draft.md) separates TRACE attempt identity, correlation metadata and signed declaration snapshots. Wire format, implementation and adoption remain pending before upstream contribution to MCP spec governance.
 - **A2A profile (normative)**: binding rules over the `delegation` block now that A2A is stable at v1.x, including the mutual case. cA2A is the reference implementation.
 - **Attested memory and persistent state**: a claim for agent memory integrity at runtime, digesting the whole store rather than a manifest of it. Nothing in the ecosystem measures agent memory today; every runtime treats the agent as stateless between actions.
@@ -28,6 +34,8 @@ Status as of September 2026. Spec **v0.2** is current ([`spec/trace-v0.2.md`](sp
 
 ## Later: v1.0 standard (2027)
 
+In short: a stable 1.0 run by its own technical steering committee, with a certification program and verification libraries in more languages.
+
 - TSC governance under "TRACE Specification, a Series of LF Projects, LLC" (formation with LF Projects, LLC complete; the TSC transition under [CHARTER.md](CHARTER.md) is the remaining step)
 - All §7 open questions resolved
 - Complete conformance certification program
@@ -38,6 +46,8 @@ Status as of September 2026. Spec **v0.2** is current ([`spec/trace-v0.2.md`](sp
 
 ## What TRACE will not do
 
+TRACE builds on existing standards and leaves several jobs to other tools on purpose:
+
 - Replace RATS, EAT, SLSA, SPIFFE, SCITT, or MCP: TRACE is a profile of these
 - Specify a centralized Trust Record registry: verification is designed to work without one
 - Build a TEE platform: hardware support targets open silicon (TDX, SEV-SNP, NVIDIA CC) and any platform that produces RATS-conformant evidence
@@ -45,4 +55,4 @@ Status as of September 2026. Spec **v0.2** is current ([`spec/trace-v0.2.md`](sp
 
 ## Influencing the roadmap
 
-Open a GitHub issue with the `spec` or `roadmap` label. Items land here when they are implemented and tested, not when they are planned; anything above the "Next" line is exercisable today.
+To suggest a change, open a GitHub issue with the `spec` or `roadmap` label. Items land here when they are implemented and tested, not when they are planned; anything above the "Next" line is exercisable today.
diff --git a/SPONSORS.md b/SPONSORS.md
index 6bc0560a..92342941 100644
--- a/SPONSORS.md
+++ b/SPONSORS.md
@@ -1,6 +1,6 @@
 # Sponsors
 
-The TRACE project recognizes organizations that provide financial, engineering, infrastructure, or other material support.
+This page lists the organizations that pay for or otherwise support the work on TRACE, and how another organization can join them. The TRACE project recognizes organizations that provide financial, engineering, infrastructure, or other material support.
 
 TRACE is sponsored by OPAQUE Systems, which funds the engineering, infrastructure and confidential-computing work behind it. Project decisions follow [GOVERNANCE.md](GOVERNANCE.md).
 
@@ -12,4 +12,4 @@ TRACE is sponsored by OPAQUE Systems, which funds the engineering, infrastructur
 
 ## Adding or updating a sponsor
 
-Sponsor recognition must describe the support factually and must not imply certification or endorsement. Open a pull request updating this file with the organization name and a concise description of its support.
+More sponsors are welcome. Sponsor recognition must describe the support factually and must not imply certification or endorsement. Open a pull request updating this file with the organization name and a concise description of its support.
diff --git a/conformance/LIMITATIONS.md b/conformance/LIMITATIONS.md
index 6ddb5a57..7f8bff4f 100644
--- a/conformance/LIMITATIONS.md
+++ b/conformance/LIMITATIONS.md
@@ -1,7 +1,9 @@
 # Known Limitations
 
 What this suite does **not** establish. A conformance report is only useful if the reader knows
-what it was never checking, so this is the companion to the report rather than a footnote to it.
+what it was never checking, so read this page alongside any report. In short: a pass means the
+record is well formed and complete for its level; it does not mean the agent behaved well, that
+the hardware claims are true, or that anyone independent checked the result.
 
 ## What a pass means
 
@@ -19,6 +21,8 @@ the disagreement is a bug worth reporting here.
 ## Where the checks stop
 
 **`TR-RTE` checks the shape of the attestation fields, not the attestation.**
+Attestation is the processor's signed statement of what code it is running. The suite checks that
+the record's fields describing it are well formed; it does not check the statement itself.
 It validates that `runtime.platform` is a recognised value, that `runtime.measurement` is a well
 formed digest, and that the RIM URI parses. It does not obtain a quote, and it does not verify one
 against AMD, Intel or a TPM manufacturer root. A record can satisfy `TR-RTE` at Level 1 carrying a
@@ -26,6 +30,8 @@ syntactically perfect measurement that no hardware ever produced. Verifying the
 silicon vendor is the relying party's job, and `cmcp_verify` is where that happens.
 
 **`TR-ANC-002` proves inclusion relative to the receipt you hand it.**
+In plain terms: it proves the record is in the log the receipt describes, not that the log is a
+real public one.
 It replays the audit path against the Merkle root carried in that receipt. It does not fetch the
 `transparency` URI, and it does not establish that the root is one a public log actually
 published. A self-consistent receipt over a tree the submitter built themselves will pass. What
@@ -73,31 +79,34 @@ The accounting extension covers only `TR-APR-001`, `TR-POL-003`, and `TR-SCA-002
 Complete means that every attempted level has exactly one reconciled row for each of those three
 obligations. It does not mean every TRACE obligation was accounted for, every obligation was
 evaluated, or that the report independently proves which code ran or which fields it accessed.
-An obligation absent from both the bounded registry and its rows is outside this completeness
-claim and cannot be discovered by registry-to-row reconciliation alone.
-
-The pilot records `TR-SCA-002` at Level 0 as applicable but not attempted: the pinned schema
-requires `build_provenance.digest`, while the scheduler first runs `TR-SCA` at Level 1. The row
-carries that scheduler reason rather than silently presenting the state without an explanation.
-
-Each source locator includes a digest of the exact value resolved at its pinned trace-spec
-revision. JSON sources use RFC 6901 pointers and RFC 8785-canonical value bytes. The operational
-TR-POL-003 rule uses the unique exact text of verification item 5 in the pinned specification;
-its schema fragments are listed separately as structural support. A reader who holds those
-pinned bytes can resolve and compare the values. The suite does not fetch or authenticate
-trace-spec at report time, and a matching value does not prove that a locator is sufficient or
-that its checker is correct.
-
-Findings and accounting share one validated execution snapshot during supported report
-construction. The emitted report remains editable and unsigned. Its registry hash identifies
-registry content; it does not authenticate the rows, the report, or its producer.
-
-The optional policy resolver is trusted in-process Python code supplied by the caller. The
-accounted path isolates nested public runs and freezes ordinary decision inputs, but it is not a
-sandbox against a callback that rewrites interpreter globals, functions, classes, or source files.
-
-`producer_branch` is a checker-owned same-execution diagnostic. Some branches with the same
-accounting meaning return indistinguishable findings, so the emitted report alone cannot
-independently reconstruct every branch label. Applicability, evaluation state, prerequisite,
-contribution, findings, and report tallies are revalidated at emission; the label is not
-presented as independent proof of checker control flow.
+Like the rest of the report, this section is unsigned and anyone can edit it.
+
+??? info "Technical detail: locators, snapshots, the resolver and branch labels"
+    An obligation absent from both the bounded registry and its rows is outside this completeness
+    claim and cannot be discovered by registry-to-row reconciliation alone.
+
+    The pilot records `TR-SCA-002` at Level 0 as applicable but not attempted: the pinned schema
+    requires `build_provenance.digest`, while the scheduler first runs `TR-SCA` at Level 1. The row
+    carries that scheduler reason rather than silently presenting the state without an explanation.
+
+    Each source locator includes a digest of the exact value resolved at its pinned trace-spec
+    revision. JSON sources use RFC 6901 pointers and RFC 8785-canonical value bytes. The operational
+    TR-POL-003 rule uses the unique exact text of verification item 5 in the pinned specification;
+    its schema fragments are listed separately as structural support. A reader who holds those
+    pinned bytes can resolve and compare the values. The suite does not fetch or authenticate
+    trace-spec at report time, and a matching value does not prove that a locator is sufficient or
+    that its checker is correct.
+
+    Findings and accounting share one validated execution snapshot during supported report
+    construction. The emitted report remains editable and unsigned. Its registry hash identifies
+    registry content; it does not authenticate the rows, the report, or its producer.
+
+    The optional policy resolver is trusted in-process Python code supplied by the caller. The
+    accounted path isolates nested public runs and freezes ordinary decision inputs, but it is not a
+    sandbox against a callback that rewrites interpreter globals, functions, classes, or source files.
+
+    `producer_branch` is a checker-owned same-execution diagnostic. Some branches with the same
+    accounting meaning return indistinguishable findings, so the emitted report alone cannot
+    independently reconstruct every branch label. Applicability, evaluation state, prerequisite,
+    contribution, findings, and report tallies are revalidated at emission; the label is not
+    presented as independent proof of checker control flow.
diff --git a/conformance/README.md b/conformance/README.md
index 579e82c4..f2e2a303 100644
--- a/conformance/README.md
+++ b/conformance/README.md
@@ -29,9 +29,9 @@ Community updates and contributor highlights: [AgenTrust on LinkedIn](https://ww
 
 > Tracks [TRACE Spec v0.2](https://github.com/agentrust-io/trace-spec).
 
-Check a TRACE record, inspect the findings, and produce a reproducible conformance report. The suite checks the record and supplied evidence; a passing report does not establish that an entire implementation meets every specification requirement.
+TRACE is an open format for signed receipts that say what an AI agent ran and what it did ([the terms, in plain English](https://agentrust-io.com/#plain-terms)). This suite checks one of those receipts, a TRACE record, against the specification, tells you the highest conformance level it reaches, and writes a report anyone can reproduce. A pass covers that one record and the evidence supplied with it; it does not show that a whole product meets every requirement of the specification.
 
-Eight modules cover envelope, signature, runtime, policy, appraisal, transcript, transparency, and provenance checks. Read the [limitations](LIMITATIONS.md) to interpret their results.
+Eight modules, each a group of related checks, look at the envelope (the outer wrapper and its basic fields), signature, runtime (the hardware it says it ran on), policy (the rules the agent ran under), appraisal (a verifier's verdict on the hardware evidence), transcript (the log of tool calls), transparency (proof of entry in a public log) and provenance (how the software was built). Read the [limitations](LIMITATIONS.md) to see what each result does and does not tell you.
 
 ## Quick start
 
@@ -43,8 +43,8 @@ trace-tests verify --record path/to/trust-record.jwt --level 1 \
 
 ## A report you can hand to someone else
 
-`verify` answers a question for the person running it. `report` produces an artifact for
-somebody who was not there: an auditor, a counterparty, an acquirer.
+`verify` prints results for the person running it. `report` writes files for somebody who
+was not there: an auditor, a counterparty, an acquirer.
 
 ```bash
 trace-tests report --record trust-record.json   --html report.html --json report.json --badge trace.svg
@@ -66,7 +66,13 @@ conformance report that looks authoritative and cannot be checked is the same sh
 thing as a control plane writing its own log.
 
 `report.json` is stable under `schema: agentrust-io/trace-tests/report/1` for dashboards
-and CI. Reports produced by the CLI include an additive, version-tagged
+and CI. CLI reports also carry a small pilot section that accounts for three specific checks
+one by one; it covers those three only, not all of TRACE.
+
+<details>
+<summary>Technical detail: the obligation_accounting pilot</summary>
+
+Reports produced by the CLI include an additive, version-tagged
 `obligation_accounting` object for the bounded `TR-APR-001`, `TR-POL-003`, and
 `TR-SCA-002` pilot. During supported report construction, its rows are reconciled
 against the executable registry identified by `registry_id` and `registry_sha256`.
@@ -86,6 +92,8 @@ and `obligation_accounting` is the sole new top-level member. Compatibility with
 consumers that require the exact historical key set is not established. The report
 remains an unsigned self-report; see [Known Limitations](LIMITATIONS.md).
 
+</details>
+
 ## Test modules
 
 | Module | ID | Tests |
@@ -94,6 +102,7 @@ remains an unsigned self-report; see [Known Limitations](LIMITATIONS.md).
 | Signature | `TR-SIG` | ES256/ES384/EdDSA, key binding, chain |
 | Runtime | `TR-RTE` | TEE platform, measurement format, RIM URI |
 | Policy | `TR-POL` | Bundle hash, enforcement mode, TEE binding |
+| Appraisal | `TR-APR` | Appraisal status, verifier URI, policy reference, timestamp |
 | Transcript | `TR-TXN` | Tool-call transcript hash binding (Phase 2+) |
 | Transparency | `TR-ANC` | SCITT receipt URI, inclusion proof |
 | Provenance | `TR-SCA` | SLSA level, builder URI, digest format |
diff --git a/conformance/docs/error-codes.md b/conformance/docs/error-codes.md
index 99ff45b4..e8f87686 100644
--- a/conformance/docs/error-codes.md
+++ b/conformance/docs/error-codes.md
@@ -1,8 +1,8 @@
 # Error Codes
 
-All TRACE test failures emit a structured error code of the form `TR-<MODULE>-<NNN>`.
+Look up a code from a failed or unverified check here: what it means and how to fix the record. Every finding the suite reports carries a code of the form `TR-<MODULE>-<NNN>`, where the middle part names the [module](modules.md) (the group of checks) and the number names the check.
 
-## TR-ENV — Envelope
+## TR-ENV: Envelope
 
 | Code | Description | How to fix |
 |------|-------------|------------|
@@ -12,7 +12,7 @@ All TRACE test failures emit a structured error code of the form `TR-<MODULE>-<N
 | TR-ENV-004 | `cnf` is absent or not an object, `cnf.jwk` is absent or not an object, or `cnf.jwk.kty` is absent | Populate `cnf.jwk` with at least `kty`. This checks that one field, not the schema's full required set, which structural validation covers |
 | TR-ENV-005 | `cnf.jwk` carries private key material (`d`, `p`, `q`, `dp`, `dq`, `qi`, `k`) | Publish the public half only. RFC 8747 makes `cnf` a confirmation key, and a record is signed and usually anchored, so a key exposed this way must be treated as compromised and the identity revoked |
 
-## TR-SIG — Signature
+## TR-SIG: Signature
 
 | Code | Description | How to fix |
 |------|-------------|------------|
@@ -21,7 +21,7 @@ All TRACE test failures emit a structured error code of the form `TR-<MODULE>-<N
 | TR-SIG-004 | `cnf.jwk` carries private key material (a `d` member), or `cnf.jwk.kty` is missing or names an unsupported key type (`OKP` and `EC` are accepted) | Remove `d` and embed only the public form of the JWK; `key_to_jwk()` returns it. For key type, use `OKP` or `EC`; Ed25519 signature verification additionally requires `kty: "OKP"` with `crv: "Ed25519"`, and a supported key that is not that pair passes this check and fails TR-SIG-005 |
 | TR-SIG-005 | The signature check outcome: the Ed25519 verification result, a signature that cannot be verified, a signature left unchecked because `cnf.jwk` carried private key material, or no signature at all. With no signature it is FAIL at Level 1 and above and `UNVERIFIED` at Level 0, which is not a pass | Sign the record with `sign_record(record, key)` and do not change the signed fields afterwards. An unsigned record is reported as unverified rather than skipped, so it cannot be read as a benign omission |
 
-## TR-RTE — Runtime
+## TR-RTE: Runtime
 
 | Code | Description | How to fix |
 |------|-------------|------------|
@@ -30,7 +30,7 @@ All TRACE test failures emit a structured error code of the form `TR-<MODULE>-<N
 | TR-RTE-003 | `runtime.rim_uri` is present and is not an `https://` URI | Remove `runtime.rim_uri` if not using a RIM, or set it to an `https://` URI. The URI is not resolved and the manifest behind it is not checked; this is a format check |
 | TR-RTE-004 | Level 1+ verification is missing the verifier challenge nonce or the nonce does not match | Supply the verifier's expected nonce and require the attested runtime nonce to match it |
 
-## TR-POL — Policy
+## TR-POL: Policy
 
 | Code | Description | How to fix |
 |------|-------------|------------|
@@ -38,7 +38,7 @@ All TRACE test failures emit a structured error code of the form `TR-<MODULE>-<N
 | TR-POL-002 | `policy.enforcement_mode` is not `enforce`, `advisory`, `silent`, or `declared` | Replace `"strict"` or `"monitor"` with one of the four accepted values; `"declared"` is the honest value for a producer that binds a policy without evaluating it |
 | TR-POL-003 | `policy.policy_uri` is not an absolute URI, or the bundle it resolves to does not have the digest `policy.bundle_hash` declares. Unverified when a resolver was supplied and the bundle could not be read; skipped when no `policy_uri` is present or no resolver was supplied | Point `policy_uri` at the bundle whose bytes hash to `bundle_hash`. A record that cites a bundle it cannot be checked against is reported as unverified rather than passed |
 
-## TR-APR — Appraisal
+## TR-APR: Appraisal
 
 | Code | Description | How to fix |
 |------|-------------|------------|
@@ -48,23 +48,23 @@ All TRACE test failures emit a structured error code of the form `TR-<MODULE>-<N
 | TR-APR-004 | `appraisal.timestamp` is present and is not an integer of epoch seconds, or is in the future. Skipped when the field is absent, which is permitted | Set `appraisal.timestamp` to the epoch second the appraisal was produced. An appraisal dated in the future asserts something that has not happened, on the same ground TR-ENV-002 applies to `iat` |
 | TR-APR-005 | `appraisal.status` is not `affirming` at Level 1 or above. Skipped at Level 0, where `docs/levels.md`'s own minimum conformant record carries `none` | Re-run the appraisal until it affirms, or check the record at Level 0 |
 
-## TR-TXN — Transcript
+## TR-TXN: Transcript
 
 | Code | Description | How to fix |
 |------|-------------|------------|
 | TR-TXN-001 | `tool_transcript.hash` is not a valid `sha256:` digest | Set `tool_transcript.hash` to `sha256:` + 64 hex chars of the Merkle root of the tool call log |
 | TR-TXN-002 | `tool_transcript.call_count` is negative or not an integer | Set `tool_transcript.call_count` to a non-negative integer (0 is valid for sessions with no tool calls) |
 
-## TR-ANC — Transparency
+## TR-ANC: Transparency
 
 | Code | Description | How to fix |
 |------|-------------|------------|
 | TR-ANC-001 | `transparency` is absent or empty, is not a string, or is not an `https://` URI with a host | Submit the record to a SCITT transparency log and set `transparency` to the returned receipt URI. The URI is not resolved and the receipt behind it is not fetched; this is a format check on the pointer, and TR-ANC-002 is what checks the anchor |
 | TR-ANC-002 | No anchor receipt was supplied, the receipt is malformed, or replaying its inclusion proof does not reproduce the committed `merkle_root` | Pass the receipt with `--receipt`. Without one, nothing proves the record is in the log the URI names, so Level 2 cannot pass. If a receipt is supplied and the proof does not verify, the record is not in that tree or it has been modified since it was anchored |
 
-## TR-SCA — Provenance
+## TR-SCA: Provenance
 
 | Code | Description | How to fix |
 |------|-------------|------------|
-| TR-SCA-001 | `build_provenance.slsa_level` is not 0–3 | Set `build_provenance.slsa_level` to an integer 0–3 matching your SLSA build level |
+| TR-SCA-001 | `build_provenance.slsa_level` is not 0 to 3 | Set `build_provenance.slsa_level` to an integer 0 to 3 matching your SLSA build level |
 | TR-SCA-002 | `build_provenance.digest` is not a valid `sha256:` digest | Set `build_provenance.digest` to `sha256:` + 64 hex chars of the container image or artifact digest |
diff --git a/conformance/docs/levels.md b/conformance/docs/levels.md
index 7f93efd1..c0efff76 100644
--- a/conformance/docs/levels.md
+++ b/conformance/docs/levels.md
@@ -1,16 +1,18 @@
 # Conformance Levels
 
-TRACE defines three conformance levels. Higher levels require all lower-level modules plus additional ones.
+This page explains what a record needs to reach each conformance level, and which failures stop it. Read it when a record lands at a lower level than you expected, or before you decide which level to aim for.
+
+TRACE defines three conformance levels. Level 0 is for development, Level 1 adds a claim about the secure hardware the agent ran on, and Level 2 adds a log of tool calls and proof that the record was entered in a public log. Each level runs everything the level below runs, plus more checks.
 
 | Level | Required Modules | Use Case |
 |-------|-----------------|----------|
-| **0** | TR-ENV, TR-SIG, TR-POL, TR-APR | Software-only development and staging |
+| **0** | TR-ENV, TR-SIG, TR-POL, TR-APR | Development and staging, no secure hardware |
 | **1** | Level 0 + TR-RTE, TR-SCA | Records that declare a TEE platform and measurement |
 | **2** | Level 1 + TR-TXN, TR-ANC | Full records with transparency anchoring |
 
-## Level 0 — Software-only
+## Level 0: Software-only
 
-Level 0 records are signed with a software key. The `runtime.platform` must be `"software-only"`. All-zero measurement is conventional for development use. The `appraisal` block must be present and well-formed — a recognised `status`, a `verifier` that is an absolute URI — but Level 0 does not require the appraisal to affirm.
+Level 0 records are signed with a key kept in ordinary software rather than in secure hardware. The `runtime.platform` must be `"software-only"`. All-zero measurement is conventional for development use. The `appraisal` block (a verifier's verdict on the evidence) must be present and well formed, with a recognised `status` and a `verifier` that is an absolute URI, but Level 0 does not require the verdict to be positive.
 
 **Minimum conformant Level 0 record:**
 
@@ -53,26 +55,28 @@ Level 0 records are signed with a software key. The `runtime.platform` must be `
 }
 ```
 
-**Modules tested:** TR-ENV, TR-SIG, TR-POL
+**Modules tested:** TR-ENV, TR-SIG, TR-POL, TR-APR
 
 **What causes a Level 0 failure:**
 
-- `eat_profile` missing or wrong value — TR-ENV-001
-- `runtime.platform` is a TEE value (e.g. `amd-sev-snp`) but Level 0 is requested — TR-RTE-001 does not apply, but TR-ENV still checks the envelope
-- `policy.enforcement_mode` is `"strict"` or `"monitor"` — TR-POL-002
-- `cnf.jwk` missing, of an unsupported key type, or carrying private key material (`d`) — TR-SIG-004
-- Signature does not verify against `cnf.jwk` — TR-SIG-005
-- `policy.policy_uri` is not an absolute URI, or the bundle it resolves to does not have the digest `policy.bundle_hash` declares — TR-POL-003. The malformed case is reported with or without a resolver: a reference the record got wrong needs no network to detect
+- `eat_profile` missing or wrong value: TR-ENV-001
+- `runtime.platform` is a TEE value (e.g. `amd-sev-snp`) but Level 0 is requested: TR-RTE-001 does not apply, but TR-ENV still checks the envelope
+- `policy.enforcement_mode` is `"strict"` or `"monitor"`: TR-POL-002
+- `cnf.jwk` missing, of an unsupported key type, or carrying private key material (`d`): TR-SIG-004
+- Signature does not verify against `cnf.jwk`: TR-SIG-005
+- `policy.policy_uri` is not an absolute URI, or the bundle it resolves to does not have the digest `policy.bundle_hash` declares: TR-POL-003. The malformed case is reported with or without a resolver: a reference the record got wrong needs no network to detect
 
-- `appraisal` is absent or not an object, or `appraisal.status` is not one of the four values the schema enumerates — TR-APR-001
-- `appraisal.verifier` is absent or is not an absolute URI — TR-APR-002
-- `appraisal.policy_ref` or `appraisal.timestamp` is present and malformed — TR-APR-003, TR-APR-004. Absent, either one is skipped rather than passed
+- `appraisal` is absent or not an object, or `appraisal.status` is not one of the four values the schema enumerates: TR-APR-001
+- `appraisal.verifier` is absent or is not an absolute URI: TR-APR-002
+- `appraisal.policy_ref` or `appraisal.timestamp` is present and malformed: TR-APR-003, TR-APR-004. Absent, either one is skipped rather than passed
 
 ---
 
-## Level 1 — TEE Attestation
+## Level 1: TEE Attestation
+
+Level 1 adds hardware attestation: the record names the TEE (trusted execution environment, a processor mode that keeps a program's memory sealed off) it ran in and the measurement (a fingerprint of the code loaded into it). The suite checks that these fields are well formed; it does not verify the hardware's signed report, which is a separate step (see [Known limitations](../LIMITATIONS.md)).
 
-Level 1 adds hardware attestation. `runtime.platform` must be a value from the `runtime.platform` enum in `schemas/trace-claim.json` other than `software-only`, which carries no hardware attestation evidence. The measurement must be non-zero. `appraisal.status` must be `"affirming"` — TR-APR-005.
+`runtime.platform` must be a value from the `runtime.platform` enum in `schemas/trace-claim.json` other than `software-only`, which carries no hardware attestation evidence. The measurement must be non-zero. `appraisal.status` must be `"affirming"` (TR-APR-005).
 
 **Minimum conformant Level 1 record** (changes from Level 0 in bold context):
 
@@ -115,20 +119,22 @@ Level 1 adds hardware attestation. `runtime.platform` must be a value from the `
 }
 ```
 
-**Modules tested:** TR-ENV, TR-SIG, TR-POL, TR-RTE, TR-SCA
+**Modules tested:** TR-ENV, TR-SIG, TR-POL, TR-APR, TR-RTE, TR-SCA
 
 **What causes a Level 1 failure over Level 0:**
 
-- `runtime.platform` is `"software-only"` — TR-RTE-001
-- `runtime.measurement` is all zeros — TR-RTE-002 (all-zero is invalid at Level 1)
-- `build_provenance` missing entirely — TR-SCA-001, TR-SCA-002
-- `appraisal.status` is `"none"` — while not a hard schema violation, a conformant Level 1 record should carry `"affirming"`; TR-APR-005 reports this from Level 1 and skips it at Level 0
+- `runtime.platform` is `"software-only"`: TR-RTE-001
+- `runtime.measurement` is all zeros: TR-RTE-002 (all-zero is invalid at Level 1)
+- `build_provenance` missing entirely: TR-SCA-001, TR-SCA-002
+- `appraisal.status` is `"none"`: while not a hard schema violation, a conformant Level 1 record should carry `"affirming"`; TR-APR-005 reports this from Level 1 and skips it at Level 0
 
 ---
 
-## Level 2 — Transparency Anchoring
+## Level 2: Transparency Anchoring
+
+Level 2 adds two things: a fingerprint of the log of tool calls the agent made, and proof that the record was entered in a public, append-only transparency log, so it cannot be quietly swapped later. SCITT is the standard format for such logs.
 
-Level 2 adds tool transcript and transparency anchor requirements. The `transparency` field must be an HTTPS URI with a host, pointing to a SCITT receipt. The suite checks that it parses and that the scheme and host are present; it does not resolve the URI, and it does not recognise a placeholder value.
+The `transparency` field must be an HTTPS URI with a host, pointing to a SCITT receipt. The suite checks that it parses and that the scheme and host are present; it does not resolve the URI, and it does not recognise a placeholder value.
 
 **Minimum conformant Level 2 record** (additional fields over Level 1):
 
@@ -142,20 +148,22 @@ Level 2 adds tool transcript and transparency anchor requirements. The `transpar
 }
 ```
 
-**Modules tested:** TR-ENV, TR-SIG, TR-POL, TR-RTE, TR-SCA, TR-TXN, TR-ANC
+**Modules tested:** TR-ENV, TR-SIG, TR-POL, TR-APR, TR-RTE, TR-SCA, TR-TXN, TR-ANC
 
 **What causes a Level 2 failure over Level 1:**
 
-- `tool_transcript.hash` missing or not a valid `sha256:` digest — TR-TXN-001
-- `tool_transcript.call_count` negative or not an integer — TR-TXN-002
-- `transparency` is absent or empty, is not a string, or is not an `https://` URI with a host — TR-ANC-001
-- no anchor receipt was supplied, the receipt is malformed, or its inclusion proof does not reproduce the committed `merkle_root` — TR-ANC-002. A record cannot reach Level 2 on a URI alone: pass the receipt with `--receipt`
-- `policy.policy_uri` is present, a resolver was supplied with `--policy-dir`, and the bundle could not be read — TR-POL-003. Unverified rather than failed, and unverified fails the run from Level 2
+- `tool_transcript.hash` missing or not a valid `sha256:` digest: TR-TXN-001
+- `tool_transcript.call_count` negative or not an integer: TR-TXN-002
+- `transparency` is absent or empty, is not a string, or is not an `https://` URI with a host: TR-ANC-001
+- no anchor receipt was supplied, the receipt is malformed, or its inclusion proof does not reproduce the committed `merkle_root`: TR-ANC-002. A record cannot reach Level 2 on a URI alone: pass the receipt with `--receipt`
+- `policy.policy_uri` is present, a resolver was supplied with `--policy-dir`, and the bundle could not be read: TR-POL-003. Unverified rather than failed, and unverified fails the run from Level 2
 
 ---
 
 ## Unverified findings
 
+Besides pass, fail and skip, a check can come back unverified: the suite could not reach the evidence it needed to decide. The table says from which level that counts as a failure.
+
 An unverified finding means **the check could not be executed against the
 evidence the record cites**. It is held apart from a skip so that a consumer can
 never read it as a benign omission, and it is not a pass.
@@ -169,11 +177,14 @@ which that stops being tolerable is a property of the check.
 | TR-SIG-005 | 1 |
 | TR-POL-003 | 2 |
 
-A code absent from this table fails from Level 1. That default is deliberate: a
-new code nobody registered still fails closed, and the registration guard turns
-red rather than the run turning quietly permissive. The table is
-`UNVERIFIED_FAILS_FROM_LEVEL` in `src/trace_tests/modules/unverified.py`, and
-`tests/test_docs_match_the_modules.py` fails if the two disagree.
+A code absent from this table fails from Level 1.
+
+??? info "Technical detail: where the table lives"
+    That default is deliberate: a new code nobody registered still fails closed, and
+    the registration guard turns red rather than the run turning quietly permissive.
+    The table is `UNVERIFIED_FAILS_FROM_LEVEL` in
+    `src/trace_tests/modules/unverified.py`, and
+    `tests/test_docs_match_the_modules.py` fails if the two disagree.
 
 ---
 
@@ -187,6 +198,6 @@ The certification program (launching 2027) will require Level 1 at minimum.
 
 ## Related
 
-- [Error Codes](error-codes.md) — every TR-* error with description and fix
-- [Test Modules](modules.md) — per-module test lists with positive and negative cases
-- [TRACE Trust Levels](https://trace.agentrust-io.com/docs/trust-levels/) — full specification of what each level proves
+- [Error Codes](error-codes.md): every TR-* error with description and fix
+- [Test Modules](modules.md): per-module test lists with positive and negative cases
+- [TRACE Trust Levels](https://trace.agentrust-io.com/docs/trust-levels/): full specification of what each level proves
diff --git a/conformance/docs/modules.md b/conformance/docs/modules.md
index d00c9e3b..4570f677 100644
--- a/conformance/docs/modules.md
+++ b/conformance/docs/modules.md
@@ -1,6 +1,8 @@
 # Test Modules
 
-The TRACE conformance suite is divided into eight modules. Each module maps to a section of the TRACE specification.
+The TRACE conformance suite is divided into eight modules. A module is a group of related checks on one part of a record, such as its signature or the hardware it says it ran on. Each module maps to a section of the TRACE specification, and each one's page lists every check with an example that passes and one that fails.
+
+The table below uses the record's own field names (in code font). The [conformance levels](levels.md) page says which modules run at which level.
 
 | Module | ID Prefix | Spec Section | What It Tests |
 |--------|-----------|--------------|---------------|
diff --git a/conformance/docs/modules/tr-anc.md b/conformance/docs/modules/tr-anc.md
index 74b4758b..d0de06ad 100644
--- a/conformance/docs/modules/tr-anc.md
+++ b/conformance/docs/modules/tr-anc.md
@@ -1,6 +1,13 @@
-# TR-ANC — Transparency
+# TR-ANC: Transparency
 
-Tests transparency anchoring via SCITT.
+Checks that the record was entered in a public, append-only log, so it cannot be quietly replaced later. TR-ANC-001 checks the link to the log entry. TR-ANC-002 uses a receipt you supply to prove, offline, that this exact record is in the log the receipt describes. Both apply from Level 2.
+
+??? info "Technical detail: what the receipt proof covers"
+    The log follows SCITT, the IETF format for transparency services. The receipt carries an
+    inclusion proof (a short list of hashes linking the record to a Merkle root, the single
+    hash that commits to the whole log). The proof is checked against the root in that
+    receipt; whether a public log really published that root is outside this module, as
+    [Known limitations](../../LIMITATIONS.md) explains.
 
 ## Required at Level 2+
 
diff --git a/conformance/docs/modules/tr-apr.md b/conformance/docs/modules/tr-apr.md
index 66bf17d2..77dbd7ec 100644
--- a/conformance/docs/modules/tr-apr.md
+++ b/conformance/docs/modules/tr-apr.md
@@ -1,4 +1,6 @@
-# TR-APR — Appraisal
+# TR-APR: Appraisal
+
+An appraisal is a verifier's verdict on the hardware evidence behind a record. This module checks that the verdict the record carries is well formed and, from Level 1, positive. It reads the verdict as written and fetches nothing.
 
 Tests the evidence appraisal the record carries: the verifier's verdict, who
 issued it, which policy it was issued under, and when.
diff --git a/conformance/docs/modules/tr-env.md b/conformance/docs/modules/tr-env.md
index f13db6fa..134b7c0c 100644
--- a/conformance/docs/modules/tr-env.md
+++ b/conformance/docs/modules/tr-env.md
@@ -1,6 +1,8 @@
-# TR-ENV — Envelope
+# TR-ENV: Envelope
 
-Tests the top-level EAT envelope structure of a TRACE Trust Record.
+Checks the outer wrapper of a record and its basic fields: which version of the format it uses, when it was issued, which agent it is about, and the public key used to check its signature. A common cause of failure here is a record made for an older version of TRACE (see [Known limitations](../../LIMITATIONS.md)).
+
+Technically, the envelope is an EAT (Entity Attestation Token, an IETF format for signed statements about a system), and these checks cover its top-level structure.
 
 ## Required at Level 0+
 
diff --git a/conformance/docs/modules/tr-pol.md b/conformance/docs/modules/tr-pol.md
index 8ef613bd..ebe542e1 100644
--- a/conformance/docs/modules/tr-pol.md
+++ b/conformance/docs/modules/tr-pol.md
@@ -1,6 +1,6 @@
-# TR-POL — Policy
+# TR-POL: Policy
 
-Tests Cedar policy bundle binding.
+Checks the record's link to the policy bundle, the file of rules the agent ran under (written in Cedar, a policy language). The record carries the bundle's digest (a fingerprint of its bytes) and how strictly the rules were applied; when you supply the bundle, the suite confirms the fingerprint matches.
 
 ## Required at Level 0+
 
@@ -13,7 +13,7 @@ Tests Cedar policy bundle binding.
 ## Resolving the bundle
 
 TR-POL-003 needs somewhere to fetch the bundle from. The resolver is supplied
-by the caller and never derived from the record — a record that named its own
+by the caller and never derived from the record, because a record that named its own
 resolver could name one that agrees with it. From the CLI that is `--policy-dir
 DIR`, where `DIR/resolutions.json` maps each `policy_uri` to a relative path
 inside `DIR`:
diff --git a/conformance/docs/modules/tr-rte.md b/conformance/docs/modules/tr-rte.md
index a3dee5b3..b30d15c1 100644
--- a/conformance/docs/modules/tr-rte.md
+++ b/conformance/docs/modules/tr-rte.md
@@ -1,5 +1,7 @@
 # TR-RTE: Runtime
 
+This module looks at what the record says about the hardware the agent ran on: which kind of TEE (trusted execution environment, a processor mode that keeps a program's memory sealed off) and the measurement (a fingerprint of the code loaded into it). It checks that those claims are well formed. It does not prove them; that takes checking the hardware's own signed report, which happens outside this suite.
+
 Checks runtime claim fields and, at Level 1 or above, the verifier's nonce. This module does not fetch reference manifests, verify hardware quotes, authenticate platform certificates, or compare measurements against an approved image.
 
 ## Checks
diff --git a/conformance/docs/modules/tr-sca.md b/conformance/docs/modules/tr-sca.md
index 864807df..e238a37a 100644
--- a/conformance/docs/modules/tr-sca.md
+++ b/conformance/docs/modules/tr-sca.md
@@ -1,10 +1,10 @@
-# TR-SCA — Provenance
+# TR-SCA: Provenance
 
-Tests SLSA build provenance.
+Checks the record's statement about how the agent's software was built: the SLSA level (a public scale, 0 to 3, for how trustworthy a build process is) and the digest of what was built. These checks apply from Level 1 and cover the format of the claim only.
 
 ## Required at Level 1+
 
 | Test ID | Description | Positive Case | Negative Case |
 |---------|-------------|---------------|---------------|
-| TR-SCA-001 | `build_provenance.slsa_level` is 0–3 | `0`, `1`, `2`, `3` | `4`, `5`, `-1`, `"high"`, absent |
+| TR-SCA-001 | `build_provenance.slsa_level` is 0 to 3 | `0`, `1`, `2`, `3` | `4`, `5`, `-1`, `"high"`, absent |
 | TR-SCA-002 | `build_provenance.digest` is a valid `sha256:` digest | `sha256:` followed by 64 hex chars | missing, wrong prefix, wrong length |
diff --git a/conformance/docs/modules/tr-sig.md b/conformance/docs/modules/tr-sig.md
index 4d9938ef..71442c7c 100644
--- a/conformance/docs/modules/tr-sig.md
+++ b/conformance/docs/modules/tr-sig.md
@@ -1,6 +1,6 @@
-# TR-SIG — Signature
+# TR-SIG: Signature
 
-Tests Ed25519 signature binding on the TRACE Trust Record.
+Checks that the record is signed and that the signature matches the public key carried in the record, so any change after signing shows up. It also checks that the record does not accidentally publish its private key. Signatures use Ed25519, a widely used signing algorithm.
 
 ## Required at Level 0+
 
diff --git a/conformance/docs/modules/tr-txn.md b/conformance/docs/modules/tr-txn.md
index d39e7b03..8e7a89be 100644
--- a/conformance/docs/modules/tr-txn.md
+++ b/conformance/docs/modules/tr-txn.md
@@ -1,6 +1,6 @@
-# TR-TXN — Transcript
+# TR-TXN: Transcript
 
-Tests tool-call transcript binding.
+Checks the record's summary of the tool calls the agent made: a fingerprint of the full call log and the number of calls. These checks apply from Level 2. They check that the fields are well formed; the suite does not have the log itself to compare against.
 
 ## Required at Level 2+
 
diff --git a/conformance/docs/quickstart.md b/conformance/docs/quickstart.md
index 6b964094..ee632e41 100644
--- a/conformance/docs/quickstart.md
+++ b/conformance/docs/quickstart.md
@@ -1,5 +1,7 @@
 # Quick Start
 
+This page installs the suite, makes a sample TRACE record, and checks it. It is for anyone who wants to see the suite work before reading the details. You need Python 3.11 or later and `pip`.
+
 ## Install
 
 ```bash
@@ -11,7 +13,7 @@ installs. `pip install trace-tests` returns 404.
 
 ## Create a sample fixture
 
-The test suite runs against a signed TRACE Trust Record. Generate a Level 0 development record with the `agentrust-trace` library:
+The suite checks a signed TRACE record (also called a Trust Record): a small JSON file describing one agent run, signed so that any later change is detectable. Make a Level 0 record, the level meant for development, with the `agentrust-trace` library:
 
 ```bash
 pip install agentrust-trace
@@ -67,7 +69,7 @@ print("Wrote sample-record.json")
 python generate_sample.py
 ```
 
-`software-only` platform and all-zero measurement are the correct values for Level 0 development records. `generate_key()` produces a fresh Ed25519 key on each run; for CI use, load a persisted key via the `TRACE_PRIVATE_KEY_PEM` environment variable instead.
+`software-only` means the record makes no claim about secure hardware, and the all-zero measurement is the matching placeholder. Both are the correct values for Level 0 development records. `generate_key()` produces a fresh Ed25519 key on each run; for CI use, load a persisted key via the `TRACE_PRIVATE_KEY_PEM` environment variable instead.
 
 ## Run against a Trust Record
 
@@ -75,7 +77,7 @@ python generate_sample.py
 trace-tests verify --record sample-record.json --level 0
 ```
 
-Level 0 is software-only (development). Level 1 requires TEE attestation. Level 2 adds transparency anchoring.
+Level 0 is for development records with no secure hardware. Level 1 requires the record to name a TEE (a trusted execution environment: a processor mode that keeps a program's memory sealed off and can report what code is running) and its measurement. Level 2 adds proof that the record was entered in a public transparency log.
 
 ## Run all levels
 
@@ -85,10 +87,12 @@ trace-tests verify --record sample-record.json --level 1 --expected-nonce "$VERI
 trace-tests verify --record sample-record.json --level 2 --expected-nonce "$VERIFIER_CHALLENGE"
 ```
 
-The sample fixture passes Level 0. Levels 1 and 2 will fail on runtime attestation and transparency fields — that is expected. See [Trust Levels](levels.md) for what each level requires.
+The sample fixture passes Level 0. Levels 1 and 2 will fail on the runtime attestation and transparency fields, which is expected. See [Trust Levels](levels.md) for what each level requires.
 
 ## Resolving the policy bundle
 
+A policy bundle is the file of rules the agent ran under. The record carries the bundle's digest (a fingerprint of its bytes), and the suite can fetch the bundle from a local folder to confirm the fingerprint matches.
+
 If your record carries `policy.policy_uri`, TR-POL-003 can fetch the bundle and
 check that it has the digest `policy.bundle_hash` declares. Point `--policy-dir`
 at a directory holding a `resolutions.json` that maps each URI to a relative
diff --git a/conformance/docs/tutorials/ci-integration.md b/conformance/docs/tutorials/ci-integration.md
index abf809ba..9a238c86 100644
--- a/conformance/docs/tutorials/ci-integration.md
+++ b/conformance/docs/tutorials/ci-integration.md
@@ -1,11 +1,13 @@
 # Running trace-tests in a CI Pipeline
 
-Configure a GitHub Actions workflow that installs `agentrust-trace-tests`, runs the full conformance suite, and uploads the test report as an artifact.
+This guide is for teams that want every code change checked automatically. It sets up a GitHub Actions workflow (GitHub's built-in system for running jobs on each push) that installs `agentrust-trace-tests`, runs your conformance tests, and saves the results as a downloadable file.
+
+If all you need is to stop a pipeline when a record falls below a level, one command does it: `trace-tests report --record trust-record.json --json report.json --fail-under 1` exits non-zero when the record does not reach Level 1. The rest of this page covers running your own pytest tests against the suite's library.
 
 ## What you'll learn
 
 - A working GitHub Actions workflow file with matrix Python version testing
-- How to use `CMCP_DEV_MODE=1` to run the software-only TEE path in standard CI
+- What `CMCP_DEV_MODE=1` does, and does not do, for software-only records in standard CI
 - How to read a failure back to the specific error code and field it names
 - When to skip hardware attestation tests that require real TEE hardware
 
@@ -71,7 +73,7 @@ The `fail-fast: false` setting lets all Python versions finish even if one matri
 
 ## Set CMCP_DEV_MODE for software-only CI
 
-Standard CI runners have no TEE hardware. Set `CMCP_DEV_MODE=1` to allow records with `runtime.platform: "software-only"` to pass TR-RTE without a real attestation measurement.
+Standard CI runners have no TEE hardware (no trusted execution environment, the processor mode that keeps a program's memory sealed off). The suite itself does not read `CMCP_DEV_MODE`: checked against the 0.6.1 source, no file under `src/` mentions it. A software-only record passes at Level 0 because Level 0 does not run TR-RTE, and it fails TR-RTE-001 at Level 1 and above whatever the environment says. Keep the variable in the workflow only if your own fixtures or tools read it.
 
 ```yaml
 - name: Run conformance suite
@@ -80,13 +82,13 @@ Standard CI runners have no TEE hardware. Set `CMCP_DEV_MODE=1` to allow records
   run: pytest --tb=short
 ```
 
-When this environment variable is absent, TR-RTE checks that `runtime.platform` is a registered hardware TEE enum (`intel-tdx`, `amd-sev-snp`, `nvidia-h100`, etc.). With `CMCP_DEV_MODE=1`, the `software-only` platform value passes. Never set this flag in production verification.
+At Level 1 and above, TR-RTE checks that `runtime.platform` is a registered hardware TEE value (`intel-tdx`, `amd-sev-snp`, `nvidia-h100`, etc.). To check a software-only record in CI, run it at Level 0. Never treat a Level 0 pass as evidence about hardware.
 
 ---
 
 ## Skip hardware attestation tests
 
-Some tests require a live TEE to produce a real attestation report. Mark them so they skip automatically on standard runners:
+Some tests need real TEE hardware to produce an attestation report (the processor's signed statement of what code it is running). Mark them so they skip automatically on standard runners:
 
 ```python
 import os
@@ -198,12 +200,12 @@ matrix:
   python-version: ["3.10", "3.11", "3.12", "3.13"]
 ```
 
-If a module uses a stdlib API that changed between versions, the matrix will catch it. The `trace_tests` library targets the same version range, so failures here indicate a compatibility problem in your custom tests or fixtures, not in the library itself.
+If a module uses a stdlib API that changed between versions, the matrix will catch it. The package requires Python 3.11 or later (`requires-python = ">=3.11"` in `pyproject.toml`), so the 3.10 leg in the example above cannot install it; drop 3.10 from your matrix. On 3.11 and later, a failure that appears on one version only points at your custom tests or fixtures.
 
 ---
 
 ## Summary
 
-You have a GitHub Actions workflow that installs `agentrust-trace-tests`, runs the suite across three Python versions with `CMCP_DEV_MODE=1`, and saves per-version JSON reports as artifacts. Hardware attestation tests are marked and skipped on standard runners. When a test fails, the error code in the assertion message maps directly to the spec field that failed.
+You have a GitHub Actions workflow that installs `agentrust-trace-tests`, runs your tests on each Python version in the matrix, and saves per-version JSON reports as artifacts. Hardware attestation tests are marked and skipped on standard runners. When a test fails, the error code in the assertion message maps directly to the spec field that failed.
 
 For more on what each error code means, see [Error Codes](../error-codes.md). To write custom tests against specific modules, see [Writing Conformance Tests](./writing-conformance-tests.md).
diff --git a/conformance/docs/tutorials/writing-conformance-tests.md b/conformance/docs/tutorials/writing-conformance-tests.md
index 652b0ad8..139aba90 100644
--- a/conformance/docs/tutorials/writing-conformance-tests.md
+++ b/conformance/docs/tutorials/writing-conformance-tests.md
@@ -1,6 +1,6 @@
 # Writing Custom TRACE Conformance Tests
 
-Write a custom pytest test that verifies a specific field in a TRACE Trust Record using the `trace_tests` library.
+This guide is for developers who produce TRACE records and want their own automated tests for them. It shows how to call the suite's checks from pytest (a common Python test runner) and test one field of a record at a time, using the `trace_tests` library.
 
 ## What you'll learn
 
@@ -22,11 +22,11 @@ TRACE defines three levels. Each level activates a cumulative set of modules:
 
 | Level | Required modules | Typical use |
 |-------|-----------------|-------------|
-| 0 | TR-ENV, TR-SIG, TR-POL | Software-only development and staging |
+| 0 | TR-ENV, TR-SIG, TR-POL, TR-APR | Development and staging, no secure hardware |
 | 1 | Level 0 + TR-RTE, TR-SCA | Records that declare a TEE platform and measurement |
 | 2 | Level 1 + TR-TXN, TR-ANC | Full records with SCITT transparency anchoring |
 
-At Level 0 you can set `runtime.platform` to `"software-only"` and skip hardware attestation entirely. At Level 1 you must supply a real TEE measurement from AMD SEV-SNP, Intel TDX, NVIDIA H100, or similar. Level 2 adds a SCITT receipt URI and a bound tool-call transcript hash.
+At Level 0 you can set `runtime.platform` to `"software-only"` and skip hardware attestation entirely. At Level 1 you must supply a TEE measurement (a fingerprint of the code loaded into a trusted execution environment) from AMD SEV-SNP, Intel TDX, NVIDIA H100, or similar. Level 2 adds a SCITT receipt URI and a bound tool-call transcript hash.
 
 The `runner.run()` function respects this table. Modules not required at the requested level are never invoked.
 
@@ -97,7 +97,7 @@ finding.skipped()     # True when status == SKIP
 finding.unverified()  # True when status == UNVERIFIED
 ```
 
-`UNVERIFIED` is distinct from `SKIP`. It means the record carries no signature that can be verified. At Level 0 this is allowed; at Level 1 and above it counts as a failure so a caller cannot mistake an unverified record for a passing one.
+`UNVERIFIED` is distinct from `SKIP`. It means the check could not reach the evidence it needed: for TR-SIG-005, a signature that can be verified; for TR-POL-003, a policy bundle that could be read. Each code has a level from which it counts as a failure (TR-SIG-005 from Level 1, TR-POL-003 from Level 2; see [Unverified findings](../levels.md#unverified-findings)), so a caller cannot mistake an unverified record for a passing one.
 
 ---
 
@@ -236,7 +236,7 @@ Common codes you will encounter:
 | TR-POL-002 | `policy.enforcement_mode` | Must be `enforce`, `advisory`, `silent`, or `declared` |
 | TR-RTE-001 | `runtime.platform` | Must be a registered TEE platform enum |
 
-When a finding carries `status == Status.UNVERIFIED`, the record has no signature. This is not a benign skip at Level 1 or above.
+When a finding carries `status == Status.UNVERIFIED`, the check could not reach its evidence, for example because the record has no signature. It is never a benign skip, and from the level its code names it fails the run.
 
 ---
 
diff --git a/conformance/index.md b/conformance/index.md
index 29957292..8a103fee 100644
--- a/conformance/index.md
+++ b/conformance/index.md
@@ -10,13 +10,13 @@ description: Run this suite against a TRACE record to see which conformance leve
 
 # Score a TRACE record against the specification
 
-The suite checks one record and the evidence supplied with it, reports the highest conformance level reached, and writes a report anyone can reproduce from the record digest and suite version. A passing report does not establish that an entire implementation meets every requirement of the [TRACE specification](https://trace.agentrust-io.com).
+TRACE is an open format for signed receipts that say what an AI agent ran and what it did ([the terms, in plain English](https://agentrust-io.com/#plain-terms)). This suite takes one of those receipts, called a TRACE record, checks it against the [TRACE specification](https://trace.agentrust-io.com), and tells you the highest conformance level it reaches. It writes a report anyone can reproduce from the record's digest (a fingerprint of its exact bytes) and the suite version. A pass covers that one record; it does not show that a whole product meets every requirement of the specification.
 
 [Score your first record](docs/quickstart.md){ .md-button .md-button--primary }
 [What this proves, and what it does not](LIMITATIONS.md){ .md-button }
 
 !!! tip "TL;DR"
-    [agentrust-trace-tests](https://pypi.org/project/agentrust-trace-tests/) 0.6.2 (Apache-2.0) runs eight modules against a record on your machine and writes a report carrying the record digest, the suite version and the command to reproduce it. A pass describes the record and says nothing about the agent, and TR-RTE checks the shape of attestation fields without verifying a quote against AMD or Intel roots.
+    [agentrust-trace-tests](https://pypi.org/project/agentrust-trace-tests/) 0.6.2 (Apache-2.0) runs eight modules, each a group of related checks, against a record on your own machine, and writes a report with the record digest, the suite version and the command to reproduce it. A pass describes the record and says nothing about how the agent behaved, and the runtime module (TR-RTE) only checks that the hardware fields are well formed: it does not verify a hardware attestation report (the processor's signed statement of what code it ran) against AMD or Intel.
 
 <div class="grid cards" markdown>
 
@@ -24,7 +24,7 @@ The suite checks one record and the evidence supplied with it, reports the highe
 
     ---
 
-    Score a record, read the failures, and produce a report from the same run.
+    Install the suite, check a sample record, see what failed and why, and produce a report from the same run.
 
     [Getting Started](docs/quickstart.md)
 
@@ -32,7 +32,7 @@ The suite checks one record and the evidence supplied with it, reports the highe
 
     ---
 
-    The report is not evidence, and it says so on its face. Each result's scope is set out module by module.
+    The report is not proof on its own, and it says so on its face. The limitations page sets out, check by check, what a result does and does not tell you.
 
     [Limitations](LIMITATIONS.md)
 
@@ -40,7 +40,7 @@ The suite checks one record and the evidence supplied with it, reports the highe
 
     ---
 
-    Quote verification happens outside the suite. Check a real Intel TDX quote at [agentrust-io.com/verify](https://agentrust-io.com/verify/).
+    The suite does not check the processor's signed report itself; other tools do that. You can check a real Intel TDX report in your browser at [agentrust-io.com/verify](https://agentrust-io.com/verify/).
 
     [Runtime module](docs/modules/tr-rte.md)
 
@@ -48,13 +48,13 @@ The suite checks one record and the evidence supplied with it, reports the highe
 
     ---
 
-    The suite scores TRACE records, the evidence step. The specification is at [trace.agentrust-io.com](https://trace.agentrust-io.com), and records can be anchored in the [TRACE Registry](https://agentrust-io.com/registry/).
+    AgenTrust covers four steps: the model, the agent, its actions, and the evidence. This suite scores TRACE records, the evidence step. The specification is at [trace.agentrust-io.com](https://trace.agentrust-io.com), and records can be entered in a public, append-only log, the [TRACE Registry](https://agentrust-io.com/registry/).
 
     [See the chain](https://agentrust-io.com/#chain)
 
 </div>
 
-The [eight modules](docs/modules.md) cover envelope, signature, runtime, policy, appraisal, transcript, transparency, and provenance checks. Read the [limitations](LIMITATIONS.md) to interpret what each result establishes.
+The [eight modules](docs/modules.md) each look at one part of a record: the envelope (the outer wrapper and its basic fields), the signature, the runtime (the hardware it says it ran on), the policy (the rules the agent ran under), the appraisal (a verifier's verdict on the hardware evidence), the transcript (the log of tool calls), transparency (proof the record was entered in a public log) and provenance (how the software was built). Read the [limitations](LIMITATIONS.md) to see what each result does and does not tell you.
 
 ```bash
 pip install agentrust-trace-tests
@@ -63,25 +63,29 @@ trace-tests verify --record path/to/trust-record.jwt --level 1
 
 ## A report you can hand to someone else
 
+`verify` prints results for you. `report` writes files you can give to someone who was not there, such as an auditor or a customer.
+
 ```bash
 trace-tests report --record trust-record.json --html report.html --json report.json --badge trace.svg
 ```
 
-- `verify` answers a question for the person running it. `report` produces an artifact for somebody who was not there.
-- `report` runs every level up to `--max-level`, because the useful answer is the highest level a record reaches, not whether it cleared the level someone happened to pick.
-- The HTML report is self-contained: no scripts, no fonts, no external CSS, no badge service, nothing fetched when it is opened.
+- `report` tries every level up to `--max-level`, so the answer is the highest level the record reaches, whichever level you happened to ask about.
+- The HTML report is a single file that loads nothing else: no scripts, no fonts, no outside stylesheets, no badge service, nothing fetched when it is opened.
+
+To make a CI pipeline (the automated checks that run on every code change) fail below a level, add `--fail-under 1`. Without it the command always exits `0`, which is what you want when you only need the report. `report.json` keeps a stable layout, `schema: agentrust-io/trace-tests/report/1`, for dashboards and CI.
 
-Use `--fail-under 1` to gate CI on a level. Without it the command always exits `0`, which is what you want when you are producing an artifact rather than enforcing a threshold. `report.json` is stable under `schema: agentrust-io/trace-tests/report/1` for dashboards and CI.
+CLI reports also carry a small pilot section that accounts for three specific checks one by one. It covers those three only, not all of TRACE.
 
-CLI reports add an independently versioned `obligation_accounting` member for a
-bounded three-obligation pilot: `TR-APR-001`, `TR-POL-003`, and `TR-SCA-002`.
-The rows and findings come from one execution snapshot, and the report refuses
-an incomplete pilot matrix. This does not claim complete TRACE accounting.
-The extension treats `report/1` as additively extensible; compatibility with
-consumers requiring the exact historical top-level key set is not established.
-See [Known limitations](LIMITATIONS.md) for the trust and replay boundary.
+??? info "Technical detail: the obligation_accounting pilot"
+    CLI reports add an independently versioned `obligation_accounting` member for a
+    bounded three-obligation pilot: `TR-APR-001`, `TR-POL-003`, and `TR-SCA-002`.
+    The rows and findings come from one execution snapshot, and the report refuses
+    an incomplete pilot matrix. This does not claim complete TRACE accounting.
+    The extension treats `report/1` as additively extensible; compatibility with
+    consumers requiring the exact historical top-level key set is not established.
+    See [Known limitations](LIMITATIONS.md) for the trust and replay boundary.
 
-A conformance report that looks authoritative and cannot be checked is the same shape of thing as a control plane writing its own log. So the report tells a reader who does not trust the sender to go and check the record instead, and gives them what they need to do it.
+Anyone can edit a report, so a report that looks official but cannot be checked is no better than a system vouching for itself. The report therefore tells a reader who does not trust the sender to check the record directly, and gives them what they need to do it.
 
 ## Where to go next
 
@@ -91,6 +95,8 @@ A conformance report that looks authoritative and cannot be checked is the same
 
 ## Test modules
 
+The table uses the specification's own terms. Each module's page explains them.
+
 | Module | ID | Tests |
 |---|---|---|
 | Envelope | `TR-ENV` | EAT structure, required fields, `iat` validity |
diff --git a/conformance/measurement/REPORT.md b/conformance/measurement/REPORT.md
index a322895e..88af9696 100644
--- a/conformance/measurement/REPORT.md
+++ b/conformance/measurement/REPORT.md
@@ -1,5 +1,7 @@
 # Does `trace-tests` notice when its own conformance checks break?
 
+In plain terms: this page asks whether the suite's own tests would notice if one of its checks quietly stopped working. The method is to break each check on purpose, one at a time, and count how many tests fail. The result below: every failure path is now caught by at least one test, and eight checks rely on exactly one.
+
 **Measured** 2026-08-07 against `agentrust-io/trace-tests` @ `7fc189c` (release 0.4.1),
 with the normative schema from `agentrust-io/trace-spec` @ `dc7491c`.
 
@@ -52,7 +54,7 @@ covered, and still count as verified. The sites are where the checks actually li
 
 `TR-TXN-001` carries the most weight. It is the Level 2 requirement that a tool
 transcript exist at all. If it regressed, implementations would continue to be stamped
-Level 2 conformant without that property being checked — and the transcript is the claim
+Level 2 conformant without that property being checked, and the transcript is the claim
 Level 2 is largely about.
 
 `TR-SIG-002` is the gate that rejects a key that is not Ed25519. With it inert, a record
@@ -79,7 +81,7 @@ output is the conformance stamp rather than in the informative fixture set.
 `runtime.platform` enum. It holds nine values; the schema holds ten. `software-only` is
 missing.
 
-The conformance module is correct — `tr_rte.py:_VALID_PLATFORMS` has all ten — so this is
+The conformance module is correct (`tr_rte.py:_VALID_PLATFORMS` has all ten), so this is
 a defect in the self-test, not in what implementers run. Three-way comparison on a Level 0
 record carrying `software-only`:
 
@@ -90,7 +92,7 @@ tests/test_level0.py            FAIL      (contradicts both)
 ```
 
 It is latent: no vector in `tests/vectors/` uses `software-only`, so nothing triggers it
-today. It becomes active the moment one does — and it would then reject behaviour the
+today. It becomes active the moment one does, and it would then reject behaviour the
 project deliberately added, in PR #16/#17, which updated the conformance module and added
 `tests/test_software_only_platform.py` while leaving this copy behind.
 
@@ -140,7 +142,7 @@ is the property. The two are not related closely enough to substitute one for th
 - **An empty path is rejected before it can look valid.** `Path("")` is `.`, which is a
   directory, so the obvious existence check passes and the script measures whichever tree
   it happens to be standing in. The enum comparison had exactly this hole and reported
-  success having compared nothing — the failure it exists to find, in itself. It now
+  success having compared nothing: the failure it exists to find, in itself. It now
   refuses an empty argument, and refuses to report agreement when zero comparisons were
   made.
 
diff --git a/docs/build-provenance-depth.md b/docs/build-provenance-depth.md
index 62d99f24..0fec462b 100644
--- a/docs/build-provenance-depth.md
+++ b/docs/build-provenance-depth.md
@@ -4,14 +4,18 @@ description: What each build_provenance verification depth does not assure, and
 
 # Build provenance verification depth
 
+A Trust Record can say which build system produced the software that ran (its build provenance). A verifier can check that claim at three depths, from a quick name check to following every ingredient of the build. This page is for whoever chooses the depth for a deployment: it says what each depth leaves unchecked, so the choice is made knowingly.
+
 > **Non-normative.** This page is informative. It changes no schema field, wire format, required claim or conformance requirement, and carries no uppercase RFC 2119 keyword. The depth question itself was decided on [trace-spec#50](https://github.com/agentrust-io/trace-spec/issues/50). The names *Surface*, *Builder-chain* and *Dependency-chain* used on this page are the descriptive ones; they map one to one onto the `build_provenance.provenance_depth` values `surface`, `builder` and `transitive`. [Section 3.3.1 of the specification](../spec/trace-v0.2.md#331-build-provenance-verification-depth) carries the normative rules.
 
-[Spec section 3.3](../spec/trace-v0.2.md) step 7 is one sentence: *"SLSA provenance resolves to a trusted builder."* It does not say how far the verifier walks, and three stopping points satisfy it. They are not equally strong, and the weakest is the cheapest to implement.
+[Spec section 3.3](../spec/trace-v0.2.md) step 7 is one sentence: *"SLSA provenance resolves to a trusted builder."* It does not say how far the verifier walks, and three stopping points satisfy it. They are not equally strong, and the weakest is the cheapest to build.
 
 So this page states what each depth does **not** assure. A deployment picking a depth is choosing which unknowns it accepts, and that choice is invisible if the depths are described only by what they check.
 
 ## The three stopping points
 
+In plain terms: Surface compares names and fingerprints already in the record. Builder-chain also fetches the build system's signed statement and checks it matches. Dependency-chain also checks a signed statement for each input the build used.
+
 | Depth | Additionally checks | Reads |
 |---|---|---|
 | Surface | `build_provenance.digest` matches the artifact the verifier holds; `builder` is in a trusted set | The record |
diff --git a/docs/conformance-method.md b/docs/conformance-method.md
index 35adc25f..f36ce6cd 100644
--- a/docs/conformance-method.md
+++ b/docs/conformance-method.md
@@ -1,5 +1,7 @@
 # How the conformance vectors are built, and how the set is checked for holes
 
+Conformance vectors are the shared test cases any TRACE implementation can run to show it follows the specification: each one is an input plus the result a correct verifier has to give. This page explains how those test cases are written, and how we check that every rule is actually tested. It is for people who maintain the suite or want to judge how much a passing score is worth.
+
 *Informative. This page describes method, not requirements, and carries no RFC 2119
 keywords.*
 
@@ -56,7 +58,7 @@ and the vector was left behind.
 **Is every rule exercised?** For each code the verifier can emit, is there a vector that
 expects it? A rule with no vector is a check an implementation can omit while passing.
 
-**Is every rule load-bearing: twice?** The strongest form: *delete the rule and count
+**Is every rule load-bearing: twice?** A rule is load-bearing when at least one test case would change result if the rule were removed. The strongest form: *delete the rule and count
 the vectors that notice.* A rule can be named by a vector and still not be load-bearing:
 if another rule fires on the same input, removing it changes no outcome and nothing
 distinguishes an implementation that performs the check from one that skips it. And one
diff --git a/docs/crosswalks/acta-decision-receipts.md b/docs/crosswalks/acta-decision-receipts.md
index 9d3affc5..f93cab07 100644
--- a/docs/crosswalks/acta-decision-receipts.md
+++ b/docs/crosswalks/acta-decision-receipts.md
@@ -1,5 +1,7 @@
 # Acta Decision Receipts Cross-walk
 
+Acta is an IETF draft format for signed receipts that record whether an AI agent's tool call was allowed before it ran. This page shows how such a receipt can travel next to a TRACE record as supporting evidence, and which Acta fields a TRACE verifier checks. It is for teams that already produce Acta receipts; neither format changes.
+
 > **Non-normative.** This document is informative only. Nothing here changes TRACE v0.1 schema fields, wire formats, required claims, or conformance requirements. References to "TRACE" mean the TRACE v0.1 Trust Record as defined in [`spec/trace-v0.1.md`](../../spec/trace-v0.1.md). References to "Acta" mean the receipt format specified in [draft-farley-acta-signed-receipts](https://datatracker.ietf.org/doc/draft-farley-acta-signed-receipts/) (revision 02); section references of the form "Acta s2.1" are to that draft.
 
 ---
diff --git a/docs/crosswalks/chap-review-decisions.md b/docs/crosswalks/chap-review-decisions.md
index a89d8a0a..5a74d2ff 100644
--- a/docs/crosswalks/chap-review-decisions.md
+++ b/docs/crosswalks/chap-review-decisions.md
@@ -1,5 +1,7 @@
 # CHAP Review Decisions Cross-walk
 
+CHAP is a protocol for people reviewing an AI agent's work before it acts. This page shows how a CHAP approval links to the TRACE record of what the agent then did, so a reader can find the approval and check it. It is for teams that need to show a named person approved an action; neither specification changes.
+
 > **Non-normative.** This document is informative only. Nothing here changes TRACE v0.2 schema fields, wire formats, required claims, or conformance requirements. "TRACE" means the Trust Record defined in [`spec/trace-v0.2.md`](../../spec/trace-v0.2.md). "CHAP" means the [Collaborative Human-Agent Protocol](https://github.com/BrightbeamAI/chap) at version 0.2.13, with its `review/1.0` and `audit-scitt/1.0` profiles.
 
 ---
diff --git a/docs/crosswalks/mitre-atlas.md b/docs/crosswalks/mitre-atlas.md
index eada3123..8a6f2f90 100644
--- a/docs/crosswalks/mitre-atlas.md
+++ b/docs/crosswalks/mitre-atlas.md
@@ -1,5 +1,7 @@
 # MITRE ATLAS Evidence Cross-walk
 
+MITRE ATLAS is a public catalogue of the ways attackers target AI systems. This page goes through its 16 tactics and, for each, says which parts of a TRACE record help an investigator, what that evidence shows, and what it leaves out. It is for security and audit teams. TRACE records what happened; it does not block attacks.
+
 > **Non-normative.** This document is informative only. Nothing here changes TRACE v0.2 schema fields, wire formats, required claims, or conformance requirements. References to "TRACE" mean the TRACE v0.2 Trust Record as defined in [`spec/trace-v0.2.md`](../../spec/trace-v0.2.md).
 
 ---
diff --git a/docs/crosswalks/nkemba-institutional-reconstruction.md b/docs/crosswalks/nkemba-institutional-reconstruction.md
index 6e861555..7231d697 100644
--- a/docs/crosswalks/nkemba-institutional-reconstruction.md
+++ b/docs/crosswalks/nkemba-institutional-reconstruction.md
@@ -1,5 +1,7 @@
 # N'KEMBA Institutional Reconstruction Consumer Cross-walk
 
+N'KEMBA checks whether an organisation's decision is backed by evidence from several places: the agent run itself, who authorised it, who approved it, and what happened afterwards. This page explains which of those questions a TRACE record answers (the run) and which it cannot answer on its own. It is for teams building that kind of review on top of TRACE.
+
 > **Non-normative.** This document is informative only. Nothing here changes a TRACE schema field, wire format, required claim, or conformance requirement. References to TRACE mean the TRACE v0.2 Trust Record defined in [`spec/trace-v0.2.md`](../../spec/trace-v0.2.md). References to N'KEMBA mean a downstream consumer that reconstructs whether an institutional outcome is supported by independently verified evidence.
 
 ---
diff --git a/docs/crosswalks/owasp-agentic-top-10.md b/docs/crosswalks/owasp-agentic-top-10.md
index ae1e2fa9..db53fe30 100644
--- a/docs/crosswalks/owasp-agentic-top-10.md
+++ b/docs/crosswalks/owasp-agentic-top-10.md
@@ -1,5 +1,7 @@
 # OWASP Agentic AI Top 10 Evidence Cross-walk
 
+OWASP's Agentic AI Top 10 lists ten main security risks for AI agents. This page takes each risk and says which parts of a TRACE record give useful evidence, what that evidence shows, and where it falls short. It is for security and audit teams. TRACE records what happened; it does not prevent these risks.
+
 > **Non-normative.** This document is informative only. Nothing here changes TRACE v0.2 schema fields, wire formats, required claims, or conformance requirements. References to "TRACE" mean the TRACE v0.2 Trust Record as defined in [`spec/trace-v0.2.md`](../../spec/trace-v0.2.md).
 
 ---
diff --git a/docs/glossary.md b/docs/glossary.md
index bf5be4e6..303f423c 100644
--- a/docs/glossary.md
+++ b/docs/glossary.md
@@ -1,78 +1,78 @@
 # Glossary
 
-Terms used in the TRACE specification and documentation.
+This page defines the terms used across the TRACE specification and these docs. Each entry starts with a plain explanation, followed by the exact technical meaning. For the basic ideas behind all the AgenTrust projects (AI agent, tool call, attestation, signed receipt, verifying offline), see [the terms in plain English](https://agentrust-io.com/#plain-terms) on the AgenTrust site.
 
 ---
 
 **Appraisal**
-The process of evaluating a TEE evidence bundle against a reference integrity manifest (RIM) to produce an `appraisal.status` verdict. An `"affirming"` verdict means the measured environment matches the expected state. Defined in IETF RFC 9334 (RATS).
+Checking hardware evidence against the values you expected, and writing down the verdict. The process of evaluating a TEE (trusted execution environment: a protected area of a processor whose memory the host cannot read) evidence bundle against a reference integrity manifest (RIM) to produce an `appraisal.status` verdict. An `"affirming"` verdict means the measured environment matches the expected state. Defined in IETF RFC 9334 (RATS).
 
 ---
 
 **cnf / JWK**
-The TRACE `cnf` field (from RFC 7800) carries a JSON Web Key (`jwk` sub-field) that contains the Ed25519 public key used to sign the record. It is included in the signed payload so the verifier does not need to retrieve the key out-of-band.
+The public key that belongs to the record's signer, written inside the record. The TRACE `cnf` field (from RFC 7800) carries a JSON Web Key (`jwk` sub-field) that contains the Ed25519 public key used to sign the record. It is included in the signed payload so the verifier does not need to retrieve the key out-of-band. The verifier still has to compare it with a key it already trusts: a record cannot vouch for its own key (see [verification](verification.md)).
 
 ---
 
 **Conformance**
-A trust record is conformant if it passes all test cases required at its declared trust level. Conformance is verified by the `trace-tests` test suite. Partial conformance (record passes some but not all required tests) is not valid.
+Passing the official tests. A trust record is conformant if it passes all test cases required at its declared trust level. Conformance is verified by the `trace-tests` test suite. Partial conformance (record passes some but not all required tests) is not valid.
 
 ---
 
 **EAT: Entity Attestation Token**
-A JWT-based format for conveying evidence about a hardware or software entity. TRACE records use the EAT `eat_profile` claim to identify the specific TRACE profile version. Defined in IETF draft-ietf-rats-eat.
+An IETF standard format for a signed statement about a device or program, which TRACE records follow. A JWT-based format for conveying evidence about a hardware or software entity. TRACE records use the EAT `eat_profile` claim to identify the specific TRACE profile version. Defined in IETF draft-ietf-rats-eat, now published as RFC 9711.
 
 ---
 
 **GatewayClaim**
-A cMCP claim embedded in a TRACE trust record that binds the record to a specific cMCP session. Contains the session ID, gateway DID, and the Cedar policy bundle hash that governed the session.
+The part of a record that ties it to one session of the cMCP gateway, the component that sits between an agent and its tools. A cMCP claim embedded in a TRACE trust record that binds the record to a specific cMCP session. Contains the session ID, gateway DID, and the Cedar policy bundle hash that governed the session.
 
 ---
 
 **Input closure**
-The complete content-addressed set of everything a reproducibility claim's deterministic function reads: the initial configuration and every recorded external interaction, model calls included, each pinned as `{id, digest, resolver}`. A closure that omits anything which can change the transcript makes the claim malformed. Defined in §3.1.4 of the specification.
+Everything a rerun of the agent would need to read, each item pinned by its fingerprint. The complete content-addressed set of everything a reproducibility claim's deterministic function reads: the initial configuration and every recorded external interaction, model calls included, each pinned as `{id, digest, resolver}`. A closure that omits anything which can change the transcript makes the claim malformed. Defined in §3.1.4 of the specification.
 
 ---
 
 **JCS: JSON Canonicalization Scheme**
-RFC 8785. A deterministic serialization of JSON objects: Unicode code-point-ordered keys, no whitespace, IEEE 754 double-precision number encoding. TRACE uses JCS to canonicalize the record before computing the Ed25519 signature.
+A fixed way of writing JSON so the same data always produces the same bytes, which is what makes the signature repeatable. RFC 8785. A deterministic serialization of JSON objects: Unicode code-point-ordered keys, no whitespace, IEEE 754 double-precision number encoding. TRACE uses JCS to canonicalize the record before computing the Ed25519 signature.
 
 ---
 
 **Reproducibility claim**
-The optional `reproducibility` member of a Trust Record: a claim that re-executing a named deterministic function of the run over a pinned input closure yields a transcript whose RFC 8785 digest equals `transcript_digest`. The result of a verifier re-running it is carried under `appraisal.method: "re-execution"` as `reproduced`, `diverged` or `not-attempted`. Defined in §3.1.4 of the specification.
+An optional statement that running the same job again on the same inputs gives the same result. The optional `reproducibility` member of a Trust Record: a claim that re-executing a named deterministic function of the run over a pinned input closure yields a transcript whose RFC 8785 digest equals `transcript_digest`. The result of a verifier re-running it is carried under `appraisal.method: "re-execution"` as `reproduced`, `diverged` or `not-attempted`. Defined in §3.1.4 of the specification.
 
 ---
 
 **RIM: Reference Integrity Manifest**
-A signed document describing the expected firmware and software measurements for a TEE environment. During Level 1 appraisal, the verifier compares the TEE's runtime measurements against the RIM. The `runtime.rim_uri` field optionally points to a RIM.
+The list of values the hardware should report if it is running the expected software. A signed document describing the expected firmware and software measurements for a TEE environment. During Level 1 appraisal, the verifier compares the TEE's runtime measurements against the RIM. The `runtime.rim_uri` field optionally points to a RIM.
 
 ---
 
 **RATS: Remote Attestation Procedures**
-The IETF working group and architecture (RFC 9334) that defines the roles and flows for remote attestation: Attester (the hardware), Verifier (checks evidence against RIM), Relying Party (consumes the resulting attestation result). TRACE Level 1 and 2 follow the RATS architecture.
+The IETF's standard roles for proving to someone far away what a machine is running. The IETF working group and architecture (RFC 9334) that defines the roles and flows for remote attestation: Attester (the hardware), Verifier (checks evidence against RIM), Relying Party (consumes the resulting attestation result). TRACE Level 1 and 2 follow the RATS architecture.
 
 ---
 
 **SCITT: Supply Chain Integrity, Transparency, and Trust**
-An IETF draft standard for append-only transparency logs of software and attestation artifacts. TRACE Level 2 records include a SCITT receipt URI in the `transparency` field, anchoring the record to a public or shared log.
+A design for public logs that can only be added to, never quietly edited. An IETF draft standard for append-only transparency logs of software and attestation artifacts. TRACE Level 2 records include a SCITT receipt URI in the `transparency` field, anchoring the record to a public or shared log.
 
 ---
 
 **SPIFFE / SPIRE**
-SPIFFE (Secure Production Identity Framework For Everyone) defines URI-based workload identities of the form `spiffe://<trust-domain>/<workload-path>`. TRACE requires the `subject` field to be a SPIFFE URI or a DID. SPIRE is the reference implementation.
+A standard way to name a running program, like a web address for a workload. SPIFFE (Secure Production Identity Framework For Everyone) defines URI-based workload identities of the form `spiffe://<trust-domain>/<workload-path>`. TRACE requires the `subject` field to be a SPIFFE URI or a DID. SPIRE is the reference implementation.
 
 ---
 
 **Trust Level**
-A numeric value (0, 1, or 2) that summarizes the strength of the guarantees carried by a trust record. See [Trust Levels](trust-levels.md) for the full definition of each level.
+How strong the evidence behind a record is, from software signing only (0) to hardware evidence (1) to public logging (2). A numeric value (0, 1, or 2) that summarizes the strength of the guarantees carried by a trust record. See [Trust Levels](trust-levels.md) for the full definition of each level.
 
 ---
 
 **Trust Record**
-A signed JSON document emitted by an AI agent at the end of a governed session. It asserts the agent's identity, model, policy, data class, tool invocations, and (at Level 1+) hardware attestation state. Defined in full in the [TRACE Specification](../spec/trace-v0.2.md).
+The signed receipt TRACE defines: what an agent ran, where, under which policy, touching which data. A signed JSON document emitted by an AI agent at the end of a governed session. It asserts the agent's identity, model, policy, data class, tool invocations, and (at Level 1+) hardware attestation state. Defined in full in the [TRACE Specification](../spec/trace-v0.2.md).
 
 ---
 
 **Transparency**
-In the TRACE context, transparency means that a trust record has been submitted to an append-only log (SCITT) and can be independently audited by any party with access to the log. The `transparency` field holds the receipt URI. Required at Level 2.
+Publishing a record to a shared log so others can audit it later. In the TRACE context, transparency means that a trust record has been submitted to an append-only log (SCITT) and can be independently audited by any party with access to the log. The `transparency` field holds the receipt URI. Required at Level 2.
diff --git a/docs/integration/agt.md b/docs/integration/agt.md
index 8778bf22..166de1f9 100644
--- a/docs/integration/agt.md
+++ b/docs/integration/agt.md
@@ -1,6 +1,8 @@
 # Integration: AGT
 
-The [Agent Governance Toolkit](https://github.com/microsoft/agent-governance-toolkit) can supply policy and audit evidence to a TRACE producer. `TraceAGTAdapter` maps supplied session inputs into a standalone software-only record; it does not run the agent or independently verify those inputs.
+This page is for teams that already use the Agent Governance Toolkit (AGT) and want a TRACE record for each agent session. It explains what the adapter puts into the record, what it leaves to you, and how much the result proves.
+
+The [Agent Governance Toolkit](https://github.com/microsoft/agent-governance-toolkit) is open-source software that checks what AI agents do against rules while they run, and keeps an audit log. `TraceAGTAdapter` takes a session's policy, audit log and identity, as you supply them, and turns them into a standalone TRACE record signed in software, with no hardware evidence. It does not run the agent or independently verify those inputs.
 
 ## Choose the integration path
 
@@ -10,6 +12,8 @@ A record under the superseded v0.1 EAT profile is not accepted by the current v0
 
 ## Field mapping
 
+Most inputs go into the record as a SHA-256 hash, a short fingerprint that changes if a single byte of the input changes. A verifier holding the original policy file or audit log can recompute the hash and compare.
+
 | Input | TRACE commitment |
 |---|---|
 | Agent SPIFFE URI or DID | `subject` |
@@ -19,7 +23,7 @@ A record under the superseded v0.1 EAT profile is not accepted by the current v0
 | UTF-8 chain-tip string | SHA-256 software commitment in `runtime.measurement` |
 | Deployment metadata | Model, classification, and build-provenance declarations |
 
-The adapter uses RFC 8785 for transcript canonicalization. It currently accepts a transparency string but does not submit to a registry. `appraisal.status` defaults to `none`, because the adapter does not evaluate the session and `appraisal.status` is the verifier's field (spec section 3.3.1); pass `appraisal_status` only when an appraisal actually happened. A producer must accurately set those fields before signing; the tutorial shows how to avoid claiming an anchor for synthetic input.
+Before hashing the audit log, the adapter writes it out in one fixed byte form (RFC 8785 canonicalization), so any implementation gets the same hash. It currently accepts a transparency string but does not submit to a registry. `appraisal.status` defaults to `none`, because the adapter does not evaluate the session and `appraisal.status` is the verifier's field (spec section 3.3.1); pass `appraisal_status` only when an appraisal actually happened. A producer must accurately set those fields before signing; the tutorial shows how to avoid claiming an anchor for synthetic input.
 
 `enforcement_mode` is required and has no default. The adapter observes a session; it
 does not evaluate the policy, so it cannot know which mode applied. A default of
@@ -30,4 +34,6 @@ the runtime's enforcement default or behavior.
 
 ## Assurance
 
+The record proves who signed it and that it has not changed since. It does not prove the session ran on particular hardware.
+
 Software signing authenticates the producer's statement when the recipient trusts its key. Hardware evidence requires a separately verified runtime and key binding. Level 2 additionally requires transparency anchoring. Placing an AGT application near a cMCP gateway does not automatically create matching or superseding records; use the [cMCP integration guide](cmcp.md) for that runtime's boundary.
diff --git a/docs/integration/cmcp.md b/docs/integration/cmcp.md
index 1817a413..e4e84d2a 100644
--- a/docs/integration/cmcp.md
+++ b/docs/integration/cmcp.md
@@ -1,6 +1,8 @@
 # Integration: cMCP
 
-[cMCP](https://cmcp.agentrust-io.com/) is a gateway between an MCP client and its tool servers. It evaluates routed calls against Cedar policy, blocks policy denials in enforcing mode, records decisions, and signs a session claim when the session closes. The client and upstream tools remain outside the gateway's enforcement boundary.
+This page is for anyone who receives TRACE evidence from cMCP and needs to know how to check it. It explains what cMCP covers, which verifier to use, and what a cMCP session does and does not prove.
+
+MCP (Model Context Protocol) is the common way AI agents call outside tools. [cMCP](https://cmcp.agentrust-io.com/) is a gateway that sits between an agent (the MCP client) and the tool servers it calls. It checks each call passing through it against rules written in the Cedar policy language, blocks calls the rules deny when it is set to enforce, records each decision, and signs a session claim when the session closes. The client and upstream tools remain outside the gateway's enforcement boundary.
 
 ## Start with a local call
 
@@ -10,14 +12,14 @@ cMCP only governs traffic routed through it. Other tool connections are not cove
 
 ## Verify the correct envelope
 
-cMCP's `RuntimeClaim` contains nested TRACE fields and runtime-specific evidence. It is not the flat standalone object accepted by `agentrust_trace.verify_record`. Use `cmcp_verify.verify_trace_claim` with independently approved policy and catalog hashes and the required evidence inputs.
+cMCP wraps its evidence in its own format, so the standalone TRACE verifier is the wrong tool for it. cMCP's `RuntimeClaim` contains nested TRACE fields and runtime-specific evidence. It is not the flat standalone object accepted by `agentrust_trace.verify_record`. Use `cmcp_verify.verify_trace_claim` with independently approved policy and catalog hashes and the required evidence inputs.
 
 The [verification walkthrough](https://cmcp.agentrust-io.com/tutorials/verifying-a-trace-claim/) explains the result states. A software-only or incomplete hardware result must not be promoted to `verified` by the consumer.
 
 ## Hardware and transparency
 
-Hardware assurance depends on the configured provider, actual evidence, key binding, expected measurements, and successful appraisal. Deployment on a confidential VM alone is insufficient; consult [hardware validation](https://cmcp.agentrust-io.com/testing/hardware-validation/).
+Hardware assurance depends on the configured provider, the evidence actually collected, its tie to the signing key, the expected measurements (fingerprints of the loaded code), and a successful check of all of these. Running on a confidential VM (a virtual machine sealed off from the cloud host) is not enough on its own; consult [hardware validation](https://cmcp.agentrust-io.com/testing/hardware-validation/).
 
-Level 2 additionally requires transparency anchoring. A cMCP session is not automatically Level 2 because it ran on hardware. Nor does it automatically supersede an AGT record or guarantee matching transcript hashes: their producing profiles and envelopes must be reconciled explicitly.
+Level 2 also needs transparency anchoring, an entry in a public log that anyone can check. A cMCP session is not automatically Level 2 because it ran on hardware. Nor does it automatically supersede an AGT record or guarantee matching transcript hashes: their producing profiles and envelopes must be reconciled explicitly.
 
 Continue to [trust levels](../trust-levels.md) or [AGT integration](agt.md).
diff --git a/docs/integration/openshell.md b/docs/integration/openshell.md
index bd8a65bd..6a83b652 100644
--- a/docs/integration/openshell.md
+++ b/docs/integration/openshell.md
@@ -1,14 +1,22 @@
 # Integration: NVIDIA OpenShell
 
-[NVIDIA OpenShell](https://github.com/NVIDIA/OpenShell) is a sandbox runtime
-that enforces filesystem, process, network, and inference policy. OpenShell
-emits machine-readable OCSF events for observable sandbox behavior. A TRACE
-adapter can bind those events to an execution record without treating a
-control-plane log as hardware attestation.
+This page is for teams that run agents inside NVIDIA OpenShell and want a TRACE
+record of what happened in each sandbox. It lists the inputs the adapter needs,
+how the policies and logs are tied into the record, and what the record can and
+cannot prove.
+
+[NVIDIA OpenShell](https://github.com/NVIDIA/OpenShell) is a sandbox runtime: it
+runs an agent in a confined space and enforces rules about which files,
+processes, network addresses and AI models the agent may use. OpenShell logs
+what it sees as security events in OCSF, a standard machine-readable event
+format. A TRACE adapter can tie those events to a record of the run, while
+keeping clear that a log from the software managing the sandbox is not
+hardware attestation (a signed report from the processor itself).
 
 ## Assurance boundary
 
-An OpenShell import has the following mandatory TRACE signals:
+Because the evidence comes from OpenShell's own logs and not from hardware,
+every imported record says so in four fields. An OpenShell import has the following mandatory TRACE signals:
 
 | TRACE field | Value |
 |---|---|
@@ -41,8 +49,10 @@ The adapter requires:
 
 ## Policy binding
 
-OpenShell and ACS enforce different layers. Bind both into one canonical policy
-bundle:
+Two sets of rules apply: OpenShell's sandbox policy, and the agent's
+application rules written for AGT's Agent Control Specification (ACS). The
+adapter puts both into one policy bundle, written in a fixed byte form, so one
+hash covers both:
 
 ```json
 {
@@ -70,7 +80,9 @@ single `policy.enforcement_mode` is the weakest mode among the layers:
 
 ## Transcript binding
 
-`tool_transcript.hash` commits to a canonical envelope containing:
+The record's transcript hash covers everything below, so a verifier with the
+original files can recompute it. `tool_transcript.hash` commits to a canonical
+envelope containing:
 
 - sandbox identifier;
 - capture start and end;
@@ -86,9 +98,10 @@ a complete TRACE transcript.
 ## Implementation
 
 The `agentrust-trace-adapters` package exposes `OpenShellEvidence` and
-`build_openshell_record`. Evidence assembly returns an unsigned Level 0 record;
-signing remains a separate `agentrust_trace.sign_record` operation so callers
-cannot accidentally conflate collection with key custody.
+`build_openshell_record`. Assembling the evidence returns an unsigned Level 0
+record. Signing is a separate `agentrust_trace.sign_record` call, so collecting
+evidence and holding the signing key stay separate steps that a caller cannot
+mix up by accident.
 
 See the runnable integration in
 [`agentrust-io/integrations`](https://github.com/agentrust-io/integrations/tree/main/integrations/openshell).
diff --git a/docs/integration/pic-trace-bridge-v1.md b/docs/integration/pic-trace-bridge-v1.md
index c3c371e3..7407fbf6 100644
--- a/docs/integration/pic-trace-bridge-v1.md
+++ b/docs/integration/pic-trace-bridge-v1.md
@@ -1,5 +1,12 @@
 # PIC/TRACE authorization bridge v1
 
+This page is for implementers who use the [PIC Standard](https://github.com/pic-standard/pic-standard)
+to describe an agent's tool call before it runs, and want the approval of that call tied
+to the TRACE evidence of what the agent then did. In plain terms: an authorizer signs
+"this tool call is allowed" before the call, TRACE records the call, and this bridge lets a verifier check that the call that ran
+is the one that was approved. It is a versioned profile, and the sections below state its
+rules exactly.
+
 This informative profile binds a separately authorized pre-execution decision to
 the TRACE evidence for the execution that followed it. It is an optional bridge;
 it does not make PIC a dependency of TRACE and it does not change the TRACE
diff --git a/docs/integration/sandbox-runtime.md b/docs/integration/sandbox-runtime.md
index 25550dd7..075f06ca 100644
--- a/docs/integration/sandbox-runtime.md
+++ b/docs/integration/sandbox-runtime.md
@@ -1,16 +1,22 @@
 # Integration: sandboxed agent runtimes
 
-A sandboxed agent runtime confines one agent on one machine. Filesystem, process and
-network isolation at the kernel, an egress policy, and credentials injected so the agent
-never holds them. That answers what a single agent may touch.
+This page is for people who build or run a sandbox for AI agents and want each session
+to produce a signed TRACE record. It shows the few lines of code needed, what goes into
+the record, and how far the record can be trusted with and without hardware evidence.
+
+A sandboxed agent runtime confines one agent on one machine: the operating system limits
+which files, processes and network connections it can use, a policy limits where it may
+send data, and passwords and keys are supplied from outside so the agent never holds
+them. That answers what a single agent may touch.
 
 It does not answer, on its own, three questions that arrive next:
 
 - **Across the estate.** Which agent, on which of the two hundred machines, took that
   action, and under whose authority?
 - **From a regulator.** Not what the policy said, but what actually ran, evidenced.
-- **From a sovereign or on-prem buyer.** The same answer on a machine with a TPM, or a
-  confidential VM, or no secure hardware at all.
+- **From a sovereign or on-prem buyer.** The same answer on a machine with a TPM (a
+  security chip on the motherboard), or a confidential VM (a virtual machine sealed off
+  from the cloud host), or no secure hardware at all.
 
 `TraceSandboxAdapter` answers them from what the runtime already has at session close.
 It requires no change to the runtime.
@@ -60,6 +66,11 @@ or behavior.
 
 ## Adding a root of trust
 
+A root of trust is hardware that can vouch for what ran, by producing a signed report
+called an attestation. If your machine has one, you can pass its evidence to the adapter.
+The adapter only copies that evidence into the record; checking it is your job, and the
+two warnings after the example explain exactly what is left to you.
+
 Pass a `SandboxAttestation` and the same call emits a Level 1-*shaped* record:
 `runtime.platform` and `runtime.measurement` carry the supplied evidence verbatim.
 Nothing else about the call changes. Actual Level 1 assurance requires that evidence
@@ -104,13 +115,19 @@ sandbox runtime. It does not define one: nothing here ties `measurement` or `non
 key you eventually pass to `sign_record`, and that key is chosen independently of, and
 after, whatever attestation you verified. Verifying a genuine quote and then signing with
 an unrelated key is still not Level 1 assurance; this code cannot distinguish that case
-from a fabricated one. If your platform's quote supports a caller-supplied challenge
-(TPM qualifying data, SEV-SNP `REPORT_DATA`, TDX `REPORTDATA`), request it with that field
-set to a value derived from the signing key's RFC 7638 thumbprint, verify the binding
-yourself, and only then carry the challenge through as `nonce`.
+from a fabricated one.
+
+??? info "Technical detail: binding the quote to your signing key"
+    If your platform's quote supports a caller-supplied challenge
+    (TPM qualifying data, SEV-SNP `REPORT_DATA`, TDX `REPORTDATA`), request it with that field
+    set to a value derived from the signing key's RFC 7638 thumbprint, verify the binding
+    yourself, and only then carry the challenge through as `nonce`.
 
 ## Field mapping
 
+Each record field comes from something the runtime already has. Where a field is a hash,
+anyone holding the original input can recompute it.
+
 | Record field | Source |
 |---|---|
 | `subject` | `sandbox_id`, a SPIFFE URI or DID |
@@ -132,10 +149,12 @@ bearing field: edit the policy and the record changes. Where a runtime composes
 from several files, concatenate them in a defined order and keep that order stable. A
 hash both sides derive differently proves nothing.
 
-**The decision log is canonicalised with JCS, not `json.dumps(sort_keys=True)`.** The two
-agree on ASCII and diverge on non-ASCII strings and number formatting, and a decision log
-carries paths and hostnames. Using the same canonicalisation as the signature pre-image
-keeps the record reproducible across implementations.
+**The decision log is canonicalised with JCS, not `json.dumps(sort_keys=True)`.** JCS
+(RFC 8785) is a fixed way of writing JSON as bytes, so every implementation hashes the
+same thing. The two methods agree on plain ASCII text and differ on other characters and
+on how numbers are written, and a decision log carries paths and hostnames. Using the
+same canonicalisation as the signature pre-image keeps the record reproducible across
+implementations.
 
 **An unappraised record says so.** `appraisal.status` defaults to `"none"`. Building a
 record does not appraise it, and stamping `affirming` on an unappraised record puts a
@@ -144,6 +163,10 @@ when an appraisal actually happened.
 
 ## Levels
 
+Level 0 is a record signed in software. Level 1 adds checked hardware evidence, and Level 2 adds
+an entry in a public log (a SCITT transparency receipt). The table shows what each level
+asks of you and what it proves by itself.
+
 | Level | What you pass                                    | `runtime.platform`    | Assurance this establishes on its own |
 | ----- | ------------------------------------------------ | ---------------------- | -------------------------------------- |
 | 0     | nothing extra                                    | `software-only`       | None claimed -- honestly unattested |
diff --git a/docs/platforms/amd-sev-snp.md b/docs/platforms/amd-sev-snp.md
index fca0d8e4..5330c9cc 100644
--- a/docs/platforms/amd-sev-snp.md
+++ b/docs/platforms/amd-sev-snp.md
@@ -1,21 +1,26 @@
 # Platform: AMD SEV-SNP
 
-A signed SEV-SNP report supplies evidence about a confidential VM. To use it for TRACE, a verifier must check the report's authenticity, accepted platform state and measurement, freshness, and binding to the record-signing key. A digest copied into JSON is not that verification.
+This page is for teams running agents on AMD processors with SEV-SNP, AMD's technology for running a virtual machine sealed off from the cloud host (a confidential VM). It explains what the processor's signed report proves, how a TRACE record refers to it, and what a verifier still has to check.
+
+A signed SEV-SNP report is evidence about a confidential VM. To rely on it for a TRACE record, a verifier must check four things: that the report is genuine, that the platform state and the measurement (the fingerprint of what the VM booted) are ones it accepts, that the report is fresh, and that it is tied to the key that signed the record. A digest copied into JSON is not that verification.
 
 ## Measurement and key binding
 
-The SNP report's `MEASUREMENT` field is a 48-byte launch measurement. It is distinct from guest-supplied `REPORT_DATA`, which a profile can use to bind a key and challenge. See Google's [SEV-SNP ABI implementation](https://pkg.go.dev/github.com/google/go-sev-guest/abi) for the field sizes.
+The report carries two different values. `MEASUREMENT` is the fingerprint of what was loaded at launch. `REPORT_DATA` is a slot the guest fills in itself, which a profile can use to tie the report to a signing key and a one-time challenge.
+
+??? info "Technical detail: field sizes and reference values"
+    The SNP report's `MEASUREMENT` field is a 48-byte launch measurement. It is distinct from guest-supplied `REPORT_DATA`, which a profile can use to bind a key and challenge. See Google's [SEV-SNP ABI implementation](https://pkg.go.dev/github.com/google/go-sev-guest/abi) for the field sizes.
 
-An expected launch measurement must be independently approved. A certificate-distribution endpoint supplies signing collateral; it is not a Reference Integrity Manifest describing the expected workload. Matching a report's measurement to a record also does not establish what that measurement represents without the producing profile and reference values.
+    An expected launch measurement must be independently approved. A certificate-distribution endpoint supplies signing collateral; it is not a Reference Integrity Manifest describing the expected workload. Matching a report's measurement to a record also does not establish what that measurement represents without the producing profile and reference values.
 
 ## TRACE representation
 
 Standalone records use `runtime.platform="amd-sev-snp"`, or `azure-cvm-sev-snp` when the producing profile requires that identifier. `runtime.measurement` uses the schema's digest syntax; the producer must define its relationship to the verified report. Do not hash an already-computed measurement again unless the profile explicitly defines that transformation.
 
-Hardware appraisal supports Level 1. Level 2 adds a separately verified transparency anchor. See [trust levels](../trust-levels.md).
+Checked hardware evidence supports Level 1. Level 2 also needs a public log entry (a transparency anchor) that is checked separately. See [trust levels](../trust-levels.md).
 
 ## Deployment and verification
 
-Cloud support depends on machine family, region, firmware, and guest configuration. For GCP, consult the current [Confidential VM configurations](https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/supported-configurations). C3 is an Intel TDX family; N2D is used for AMD SEV-SNP.
+Whether a cloud offers SEV-SNP depends on the machine family, region, firmware and guest configuration. For GCP, consult the current [Confidential VM configurations](https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/supported-configurations). C3 is an Intel TDX family; N2D is used for AMD SEV-SNP.
 
 For the actual AgenTrust implementation and recorded hardware runs, use [cMCP hardware validation](https://cmcp.agentrust-io.com/testing/hardware-validation/) and its [verification tutorial](https://cmcp.agentrust-io.com/tutorials/verifying-a-trace-claim/). The TRACE SDK's signature verifier does not perform this hardware appraisal.
diff --git a/docs/platforms/bernstein.md b/docs/platforms/bernstein.md
index 2411c87c..a4b53563 100644
--- a/docs/platforms/bernstein.md
+++ b/docs/platforms/bernstein.md
@@ -1,20 +1,25 @@
 # Platform: Bernstein (software-only)
 
-Bernstein is an open-source governance layer for AI agents: a deterministic Python scheduler that coordinates agent workloads with no model in the coordination loop, records every run into a hash-chained journal, and signs a TRACE Trust Record over that journal with an Ed25519 install identity. This annex maps that producer onto the Trust Record. It is informative, in the sense GOVERNANCE gives vendor annexes: it binds no implementation, and where it quotes a requirement it names the section that carries it.
+This page is for anyone who runs Bernstein or receives TRACE records from it. It shows how Bernstein fills in each field of a TRACE record, what a verifier can check without asking Bernstein's operator, and where the evidence stops.
 
-There is no hardware root. `runtime.platform` is `software-only` on every record, for the reason section 3.1.1 gives: nothing attested the execution. What the producer has instead is a different kind of evidence, and this page says exactly what it is and what it is not: a signed record whose digests a verifier recomputes from the journal, and, once the emitter carries section 3.1.4's claim, a coordination sequence a verifier re-derives without the producer.
+Bernstein is open-source software that coordinates AI agents. A fixed set of Python rules decides what runs next (no AI model makes those decisions), every step of a run is written to a log where each entry includes a hash of the one before (a hash-chained journal, so an edited entry breaks the chain), and at the end Bernstein signs a TRACE Trust Record over that log with a key unique to each installation (an Ed25519 install identity). This annex maps that producer onto the Trust Record. It is informative, in the sense GOVERNANCE gives vendor annexes: it binds no implementation, and where it quotes a requirement it names the section that carries it.
+
+No hardware vouches for these runs. `runtime.platform` is `software-only` on every record, for the reason section 3.1.1 gives: nothing attested the execution. What Bernstein offers instead is a different kind of evidence, and this page says exactly what it is and what it is not: a signed record whose digests a verifier recomputes from the journal, and, once the emitter carries section 3.1.4's claim, a coordination sequence a verifier re-derives without the producer.
 
 Every code path and vector below is pinned to `sipyourdrink-ltd/bernstein` at [`4281e3c1`](https://github.com/sipyourdrink-ltd/bernstein/tree/4281e3c1ac86adbfae704dc4d1e69d4bb2a61559). The emitter is [`src/bernstein/core/observability/trust_record.py`](https://github.com/sipyourdrink-ltd/bernstein/blob/4281e3c1ac86adbfae704dc4d1e69d4bb2a61559/src/bernstein/core/observability/trust_record.py); its module docstring is the producer's own specification of the mapping and this page follows it.
 
 ## What the producer records
 
-Each run writes one journal, `.sdd/runs/<run_id>/journal.jsonl`, through a single always-on recorder. Every row carries `event_hash = H(prev_hash, event_type, payload_hash, index)`, where `payload_hash` is a digest of the event payload with the wall-clock envelope (`ts`, `elapsed_s`) excluded, so two identical executions chain to the same hashes regardless of timing. The head hash content-addresses the surviving journal state. A seal, taken separately, is what identifies that state as the complete finished journal; an unsealed clean prefix says the rows were not edited, not that none are missing. That is the seal boundary the emitter states for itself: the signed record proves the journal presented matches what was sealed, and cannot prove that every action taken was recorded in the first place.
+Each run writes one journal file. Every entry carries a hash that covers the entry before it, so changing or reordering an entry changes every hash after it. Timing fields are left out of the hashes, so two identical runs produce the same chain. A separate seal marks the journal as finished. The signed record proves the journal you are shown matches what was sealed; it cannot prove that every action was recorded in the first place.
+
+??? info "Technical detail: journal hashing and the two encodings"
+    Each run writes one journal, `.sdd/runs/<run_id>/journal.jsonl`, through a single always-on recorder. Every row carries `event_hash = H(prev_hash, event_type, payload_hash, index)`, where `payload_hash` is a digest of the event payload with the wall-clock envelope (`ts`, `elapsed_s`) excluded, so two identical executions chain to the same hashes regardless of timing. The head hash content-addresses the surviving journal state. A seal, taken separately, is what identifies that state as the complete finished journal; an unsealed clean prefix says the rows were not edited, and does not say none are missing. That is the seal boundary the emitter states for itself: the signed record proves the journal presented matches what was sealed, and cannot prove that every action taken was recorded in the first place.
 
-One distinction matters for anyone recomputing anything. The journal's own hashes are computed under a code-point key order with ASCII escaping, the encoding this repository's `canonicalization-boundary` vectors exist to warn about. They identify journal state inside Bernstein and are not TRACE digests. Every digest that reaches a Trust Record is computed with the producer's `canonicalize_jcs`, an RFC 8785 canonicalizer with UTF-16 code-unit key order; the supplementary-plane pair below is the vector that tells the two apart.
+    One distinction matters for anyone recomputing anything. The journal's own hashes are computed under a code-point key order with ASCII escaping, the encoding this repository's `canonicalization-boundary` vectors exist to warn about. They identify journal state inside Bernstein and are not TRACE digests. Every digest that reaches a Trust Record is computed with the producer's `canonicalize_jcs`, an RFC 8785 canonicalizer with UTF-16 code-unit key order; the supplementary-plane pair below is the vector that tells the two apart.
 
 ## TRACE representation
 
-One record per execution hop, minted from that hop's journal by `bernstein trace export`. The mapping, field by field:
+Bernstein writes one record for each step of a run where one agent hands work to another (an execution hop), built from that hop's journal by `bernstein trace export`. Most fields are digests (hashes) of something in the journal, so a verifier holding the journal can recompute them. The mapping, field by field:
 
 | Field | Value on a Bernstein record | Derived from |
 |---|---|---|
@@ -40,18 +45,24 @@ Optional members are omitted when absent, never carried as `null`. RFC 8785 trea
 
 ### Delegation: one record per hop
 
+When one agent hands work to another, each hop gets its own record, and the child's record points at its parent by including a hash of the parent's whole signed record. Swapping in a different parent record breaks that link.
+
 A delegated run is a chain of hops, each with its own record, linked and not nested, which is the shape section 3.4 fixes. A child hop's `delegation.parent_record_hash` is SHA-256 over the RFC 8785 bytes of the complete signed parent record, `signature` included, the preimage section 3.1.3 states. The choice is load-bearing for an orchestrator: a digest over the signed body alone would let a chain be rebuilt from a differently-signed parent that says the same thing, and for a multi-agent run that is the attack. `credential_id` names the delegation credential the hop acted under.
 
 The scheduler bounds spawn depth and narrows a child's `data_class` from its parent's. The three-hop vector set below is built so that both rules have something to fire on: a chain two links deep, and a narrowing pair.
 
 ### Aggregate: one record per run
 
+Bernstein can also write one summary record for a whole run, which lists every hop's record by name and hash.
+
 A run-level record rolls the hops up. It reads no journal, since no journal exists for the run as a whole, and every member is a rollup: `iat` is the latest member's; `model` the last member's; `policy.bundle_hash` a digest over the ordered list of member bundle hashes, a hash of hashes and not a policy of its own; `data_class` the most restrictive member's; `tool_transcript` a digest over the ordered member transcript hashes with the counts summed. It carries no `delegation`. Its `references` hold one `{rel: "member-execution", id, resolver, digest}` entry per hop: `id` is the member's own `subject`, `digest` is SHA-256 over the RFC 8785 bytes of the member's complete signed record, the same preimage a delegation link uses, so a verifier resolves a member by name and binds it by recomputing that digest over the record it holds. Its `subject` is `spiffe://bernstein.run/run/<run_id>`.
 
 Neither `member-execution` nor `produced-artifact` is a registered `rel` value. Section 3.1.2 keeps `rel` open and calls its values a registry; both are producer-defined relations until registered.
 
 ## Two commitments, and where they sit today
 
+A commitment is a hash in the record that a verifier can recompute from the original data. A software-only record can carry two of them, and today a Bernstein record fills in only one.
+
 Section 3.1.4 notes that a software-only record can carry two recomputable commitments, `runtime.measurement` and `transcript_digest`, over different objects. On a Bernstein record today:
 
 - `runtime.measurement` is all-zero. The value was chosen while the meaning of `measurement` under `software-only` was being settled, and it is left there deliberately until agentrust-io/trace-spec#242 settles it; the emitter records the choice in its own source. The reference SDK's adapters carry a non-zero software commitment in the same field, so the all-zero value is one reading of the field and not the field's definition.
@@ -59,17 +70,20 @@ Section 3.1.4 notes that a software-only record can carry two recomputable commi
 
 ## The reproducibility claim
 
-The coordination logic is a deterministic function of the run, and the producer already ships the check that re-runs it: `bernstein replay <run> --re-derive` takes the two things coordination did not choose, the recorded plan graph and the recorded per-task outcomes, walks them through the scheduler's coordination state machine, refuses any step the rules could not have produced at that point, and appends the accepted steps to a fresh journal in a sandbox, so the result ends with a head computed from inputs rather than copied from the recorded chain. It re-executes no agent, needs no adapter, task server or network, and reads one file to write another. That is the shape section 3.1.4 gives the claim, and the mapping onto it is:
+Because Bernstein's scheduling decisions follow fixed rules, anyone can replay a run's recorded plan and outcomes through those rules and check that they arrive at the same sequence of steps. The replay does not re-run any agent or call any model. The schema has a place to record this claim, but Bernstein's emitter does not fill it in yet (see the end of this section).
 
-| Claim member | Bernstein value |
-|---|---|
-| `function` | the coordination state machine in `bernstein.core.replay.rederive` |
-| `code_identity` | the digest of the release artifact that contains it; where `build_provenance.digest` names that same artifact the two are equal, as section 3.1.4 provides |
-| `code_resolver` | the package index the release is published to |
-| `input_closure` | the recorded plan graph and every recorded outcome the function reads, each as a content-addressed journal row; a recorded model interaction is an input here, never something a verifier re-invokes |
-| `transcript_digest` | SHA-256 over the RFC 8785 bytes of the ordered list of accepted coordination steps, each projected as the journal projects a payload, chain and timing fields excluded |
+??? info "Technical detail: how the replay works and how it maps to the claim"
+    The coordination logic is a deterministic function of the run, and the producer already ships the check that re-runs it: `bernstein replay <run> --re-derive` takes the two things coordination did not choose, the recorded plan graph and the recorded per-task outcomes, walks them through the scheduler's coordination state machine, refuses any step the rules could not have produced at that point, and appends the accepted steps to a fresh journal in a sandbox, so the result ends with a head computed from inputs rather than copied from the recorded chain. It re-executes no agent, needs no adapter, task server or network, and reads one file to write another. That is the shape section 3.1.4 gives the claim, and the mapping onto it is:
+
+    | Claim member | Bernstein value |
+    |---|---|
+    | `function` | the coordination state machine in `bernstein.core.replay.rederive` |
+    | `code_identity` | the digest of the release artifact that contains it; where `build_provenance.digest` names that same artifact the two are equal, as section 3.1.4 provides |
+    | `code_resolver` | the package index the release is published to |
+    | `input_closure` | the recorded plan graph and every recorded outcome the function reads, each as a content-addressed journal row; a recorded model interaction is an input here, never something a verifier re-invokes |
+    | `transcript_digest` | SHA-256 over the RFC 8785 bytes of the ordered list of accepted coordination steps, each projected as the journal projects a payload, chain and timing fields excluded |
 
-Two things a verifier should know before re-running. The re-derived journal head that `--re-derive` compares is Bernstein's own commitment, computed under the journal's code-point encoding; the record's `transcript_digest` is the RFC 8785 digest over the same sequence, and the two are not interchangeable. And the outcome vocabulary is section 3.1.4's: `reproduced` when the digests agree, `diverged` with the observed digest when they do not, and `not-attempted` with the reason when a closure row cannot be obtained, the artifact at `code_identity` cannot be obtained, or the function reads beyond the closure. The re-derivation's own refusal codes, a step the rules cannot produce and a head that differs, are both `diverged` in that vocabulary, since in both cases the re-run completed on the closure alone and did not reach the claimed transcript.
+    Two things a verifier should know before re-running. The re-derived journal head that `--re-derive` compares is Bernstein's own commitment, computed under the journal's code-point encoding; the record's `transcript_digest` is the RFC 8785 digest over the same sequence, and the two are not interchangeable. And the outcome vocabulary is section 3.1.4's: `reproduced` when the digests agree, `diverged` with the observed digest when they do not, and `not-attempted` with the reason when a closure row cannot be obtained, the artifact at `code_identity` cannot be obtained, or the function reads beyond the closure. The re-derivation's own refusal codes, a step the rules cannot produce and a head that differs, are both `diverged` in that vocabulary, since in both cases the re-run completed on the closure alone and did not reach the claimed transcript.
 
 The emitter at the pinned commit does not carry the block; the schema shape landed after it, in agentrust-io/trace-spec#366. Until it does, a verifier finds no claim on a Bernstein record and has nothing to re-run. The mapping is fixed here so that the emitter change is a change to what the record says, not to what the words mean.
 
@@ -84,13 +98,13 @@ Steps 1 to 3 need the records alone. Step 4 needs the journal, which is run-priv
 
 ## Assurance boundary
 
-Level 0. A software-only record cannot reach Level 1 by construction: the conformance suite's `TR-RTE-001` refuses `software-only` at hardware-attested levels and `TR-RTE-004` wants a verifier-issued nonce that a committed record cannot carry. A committed corpus also cannot pass `TR-ENV-002` without `--max-age`, since a record that regenerates byte-for-byte carries a fixed `iat`; this repository's own `examples/amd-sev-snp.json` has the same property. None of that is a defect of the producer; it is what a published record is. See [trust levels](../trust-levels.md).
+Bernstein records sit at Level 0, the software-signed level. Without hardware evidence a record cannot reach Level 1: the conformance suite's `TR-RTE-001` refuses `software-only` at hardware-attested levels and `TR-RTE-004` wants a verifier-issued nonce that a committed record cannot carry. A committed corpus also cannot pass `TR-ENV-002` without `--max-age`, since a record that regenerates byte-for-byte carries a fixed `iat`; this repository's own `examples/amd-sev-snp.json` has the same property. None of that is a defect of the producer; it is what a published record is. See [trust levels](../trust-levels.md).
 
 What the producer's evidence establishes, once verified: that the install identity signed these digests over this journal, that the chain of hops is the chain the parent signed, and, when the claim is carried, that the coordination sequence re-derives from its recorded inputs. What it does not establish: that the journal is complete, beyond what the seal says; and anything about the workload's side effects or the model's answers, which are inputs.
 
 ## Vectors
 
-Seven signed records in [`tests/fixtures/trust-record-vectors/`](https://github.com/sipyourdrink-ltd/bernstein/tree/4281e3c1ac86adbfae704dc4d1e69d4bb2a61559/tests/fixtures/trust-record-vectors), all minted by the emitter over journals written through the real recorder, never hand-written, under a frozen clock and a pinned Ed25519 seed. Regeneration is byte-identical and a test holds it to the committed files.
+Test vectors are fixed sample records, with known correct answers, that another implementation can check itself against. Seven signed records in [`tests/fixtures/trust-record-vectors/`](https://github.com/sipyourdrink-ltd/bernstein/tree/4281e3c1ac86adbfae704dc4d1e69d4bb2a61559/tests/fixtures/trust-record-vectors), all minted by the emitter over journals written through the real recorder, never hand-written, under a frozen clock and a pinned Ed25519 seed. Regeneration is byte-identical and a test holds it to the committed files.
 
 | Vector | What it is |
 |---|---|
diff --git a/docs/platforms/index.md b/docs/platforms/index.md
index 2c680722..2b67418a 100644
--- a/docs/platforms/index.md
+++ b/docs/platforms/index.md
@@ -1,10 +1,14 @@
 # Attestation Platforms
 
-Hardware evidence can support TRACE Level 1. Level 2 additionally requires transparency anchoring; selecting a hardware platform does not establish either level by itself. A recipient must verify the evidence and its binding to the record-signing key.
+This page is for anyone deciding which kind of machine can back a TRACE record with hardware evidence. It lists the processors and GPUs TRACE names, what evidence each one produces, and what you still have to check yourself.
+
+Some processors can run a program in a sealed-off area called a trusted execution environment (TEE) and then produce a signed report, called an attestation, that describes what is running inside. That report is what hardware evidence means here. A record that carries checked hardware evidence can reach TRACE Level 1, and Level 2 adds a public log entry (transparency anchoring) on top.
+
+Choosing a hardware platform does not give a record either level by itself. Whoever receives the record must check the evidence and confirm it is tied to the key that signed the record.
 
 ## Platform names and evidence
 
-Standalone TRACE records use the names in the [canonical schema](https://github.com/agentrust-io/trace-spec/blob/main/schema/trace-claim.json). Runtime configuration names such as cMCP's `sev-snp`, `tdx`, and `opaque` are not interchangeable with these wire values.
+A standalone TRACE record names its platform in the `runtime.platform` field, using the values in the [canonical schema](https://github.com/agentrust-io/trace-spec/blob/main/schema/trace-claim.json). Other tools have their own names: cMCP's configuration names `sev-snp`, `tdx` and `opaque` are not the same values and cannot be swapped in.
 
 | Platform guide | Standalone `runtime.platform` | Evidence to appraise |
 |---|---|---|
@@ -14,11 +18,13 @@ Standalone TRACE records use the names in the [canonical schema](https://github.
 | TPM2 | `tpm2` | Quote, selected PCRs, trusted attestation-key provenance, and challenge binding |
 | Software | `software-only` | Software signature and producer-defined commitments; no hardware assurance |
 
-The schema also registers other platform identifiers. Registration is not a claim that this Python SDK collects or appraises evidence for every platform.
+In the table, a measurement is a fingerprint (a hash) of the code and settings the hardware loaded, and a quote or report is the signed statement that carries it. "Appraise" means checking that evidence against trusted roots and expected values.
+
+The schema also lists other platform names. Listing a name does not mean this Python library (the TRACE SDK) collects or checks evidence for that platform.
 
 ## Vendor annexes
 
-A vendor annex maps one producer onto the Trust Record. Annexes are informative and reviewed by the vendor author and one Maintainer, per GOVERNANCE.
+A vendor annex is a page that shows how one specific product fills in a TRACE record. Annexes are informative (they bind no one) and are reviewed by the vendor author and one Maintainer, per GOVERNANCE.
 
 | Annex | `runtime.platform` | What the producer's evidence is |
 |---|---|---|
@@ -28,6 +34,6 @@ A vendor annex maps one producer onto the Trust Record. Annexes are informative
 
 `agentrust_trace.verify_record` checks the standalone record's schema, profile, signature against a trusted key, freshness, and configured nonce/revocation inputs. It does not collect a hardware quote or turn a platform string into verified hardware evidence. There is no `agentrust-trace verify-hardware` command in this package.
 
-Use a verifier for the producing runtime and evidence format. For cMCP's distinct `RuntimeClaim` envelope, follow [cMCP verification](https://cmcp.agentrust-io.com/tutorials/verifying-a-trace-claim/) and its [hardware-validation record](https://cmcp.agentrust-io.com/testing/hardware-validation/).
+To check hardware evidence, use a verifier built for the runtime that produced it and for that evidence format. For cMCP's own `RuntimeClaim` envelope, follow [cMCP verification](https://cmcp.agentrust-io.com/tutorials/verifying-a-trace-claim/) and its [hardware-validation record](https://cmcp.agentrust-io.com/testing/hardware-validation/).
 
 Continue to [trust levels](../trust-levels.md) or [interpreting hardware evidence](../tutorials/hardware-attestation-platforms.md).
diff --git a/docs/platforms/intel-tdx.md b/docs/platforms/intel-tdx.md
index f55effa1..7e0ad41c 100644
--- a/docs/platforms/intel-tdx.md
+++ b/docs/platforms/intel-tdx.md
@@ -1,10 +1,12 @@
 # Platform: Intel TDX
 
-Intel TDX isolates a Trust Domain and provides signed quote evidence about its measured state. A TRACE consumer still needs a verifier that checks the quote, accepted trust roots and collateral, expected measurements, freshness, and record-signing-key binding.
+This page is for teams running agents on Intel processors with TDX, Intel's technology for running a virtual machine sealed off from the cloud host. It explains what TDX evidence proves, how a TRACE record names it, and what you still have to check.
+
+Intel TDX runs a sealed-off virtual machine called a Trust Domain and can produce a signed report, called a quote, describing what was loaded into it. A TRACE consumer still needs a verifier that checks the quote, the trusted Intel roots and supporting data (collateral), the expected measurements, freshness, and that the quote is tied to the key that signed the record.
 
 ## Measurement and representation
 
-Standalone TRACE uses `runtime.platform="intel-tdx"`. MRTD describes the initial Trust Domain measurement; RTMRs can carry additional runtime measurements. The producing profile must say which evidence the record commits to and how the recipient checks it. A generic combination of these registers is not defined by this page.
+Standalone TRACE uses `runtime.platform="intel-tdx"`. A measurement is a fingerprint of what was loaded. TDX keeps several of them in registers: MRTD describes the Trust Domain as it started, and RTMRs can carry further measurements taken while it runs. The producing profile must say which evidence the record commits to and how the recipient checks it. A generic combination of these registers is not defined by this page.
 
 The `runtime.measurement` string is a claim until checked against authenticated evidence and independently approved reference values. Comparing two self-reported digests cannot establish key custody inside a Trust Domain.
 
@@ -16,4 +18,4 @@ For AgenTrust's collected evidence, verifier behavior, and remaining collateral
 
 ## Assurance boundary
 
-Hardware appraisal supports TRACE Level 1; Level 2 additionally requires transparency anchoring. The standalone TRACE SDK does not provide a `verify-hardware` CLI or automatically provision an Intel collateral service. See [trust levels](../trust-levels.md) and [attestation platforms](index.md).
+Checked hardware evidence supports TRACE Level 1; Level 2 also needs a public log entry (transparency anchoring). The standalone TRACE SDK does not provide a `verify-hardware` CLI or automatically provision an Intel collateral service. See [trust levels](../trust-levels.md) and [attestation platforms](index.md).
diff --git a/docs/platforms/nvidia-h100.md b/docs/platforms/nvidia-h100.md
index a1170893..b9075a79 100644
--- a/docs/platforms/nvidia-h100.md
+++ b/docs/platforms/nvidia-h100.md
@@ -1,6 +1,8 @@
 # Platform: NVIDIA H100 Confidential Computing
 
-NVIDIA GPU attestation provides evidence about a GPU's identity and firmware state. NVIDIA Remote Attestation Service (NRAS), its Reference Integrity Manifest service, and certificate-status services have separate roles. See [NVIDIA's attestation documentation](https://docs.nvidia.com/attestation/index.html) and [H100 attestation example](https://docs.nvidia.com/attestation/quick-start-guide/latest/attestation-examples/hopper_single_gpu.html).
+This page is for teams whose agents use NVIDIA H100 GPUs in confidential computing mode. It explains what GPU evidence covers, what it does not, and how a TRACE record refers to it.
+
+NVIDIA GPU attestation is a signed report about which GPU this is and what firmware it runs. Several NVIDIA services take part, each with its own job: NVIDIA Remote Attestation Service (NRAS) checks the evidence, a Reference Integrity Manifest service supplies the expected values, and certificate-status services say whether a certificate has been revoked. See [NVIDIA's attestation documentation](https://docs.nvidia.com/attestation/index.html) and [H100 attestation example](https://docs.nvidia.com/attestation/quick-start-guide/latest/attestation-examples/hopper_single_gpu.html).
 
 ## TRACE representation
 
@@ -10,9 +12,9 @@ The cMCP configuration name `opaque` belongs to that runtime's provider interfac
 
 ## CPU, GPU, and signing-key binding
 
-An accepted GPU attestation does not automatically attest the CPU workload, model weights, policy enforcement, or record-signing key. A combined deployment needs explicit evidence linking the relevant components and the signing key under a documented profile. This page does not define a universal combined CPU/GPU digest or an additional `runtime.extensions` wire field.
+A good GPU report covers the GPU only. It does not, by itself, vouch for the program on the CPU, the model weights, whether a policy was enforced, or the key that signed the record. A deployment that uses both needs explicit evidence linking those parts and the signing key, under a documented profile. This page does not define a universal combined CPU/GPU digest or an additional `runtime.extensions` wire field.
 
-Hardware appraisal supports Level 1. Level 2 additionally requires transparency anchoring. Read [trust levels](../trust-levels.md) and the producing runtime's [hardware-validation record](https://cmcp.agentrust-io.com/testing/hardware-validation/) before relying on a deployment claim.
+Checked hardware evidence supports Level 1. Level 2 also needs a public log entry (transparency anchoring). Read [trust levels](../trust-levels.md) and the producing runtime's [hardware-validation record](https://cmcp.agentrust-io.com/testing/hardware-validation/) before relying on a deployment claim.
 
 ## Getting started
 
diff --git a/docs/quickstart.md b/docs/quickstart.md
index 3afa7b89..9e51e934 100644
--- a/docs/quickstart.md
+++ b/docs/quickstart.md
@@ -4,11 +4,13 @@ description: Create a software-signed TRACE record, verify it with a separately
 
 # Quickstart
 
-Create a signed record, verify it, then change one field and watch verification fail. This local example uses synthetic claims and software signing. It does not execute an AI agent, enforce a policy, contact a registry, or produce hardware attestation.
+This page walks you through making your first TRACE record on your own computer in about ten minutes. A TRACE record (also called a Trust Record) is a signed receipt that says what an AI agent ran and under which rules; signing it means anyone with the matching public key can tell who made it and whether it was changed afterwards. It is for developers who want to see that work before reading the specification.
+
+You will create a signed record, check it, then change one field and watch the check fail. The example uses made-up values and a key held in software. It does not run an AI agent, enforce a policy, contact a registry, or produce hardware attestation (a signed report from the processor itself, covered under [trust levels](trust-levels.md)).
 
 ## Install
 
-Use Python 3.11+, Git, and Bash on Linux, macOS, or Windows with WSL. Install from the source checkout for this example: the published 0.9.0 package still bundles an older schema that requires a transparency entry, even for an unanchored record.
+Use Python 3.11+, Git, and Bash on Linux, macOS, or Windows with WSL. The steps below install the library from a copy of this repository, so the code matches this page. An older published release, agentrust-trace 0.9.0, bundled a schema that demanded a transparency entry even for a record that was never logged; 0.11.0 on PyPI no longer does (checked 2026-10-07 by running this page's scripts against it).
 
 ```bash
 git clone https://github.com/agentrust-io/trace-spec.git trace-quickstart
@@ -20,7 +22,7 @@ python -m pip install -e .
 
 ## Generate a signing key
 
-The script below generates one key and uses it to sign the record. It saves only the public key, so you can verify the record in another process. Keep that public key separate from untrusted records. In a real deployment, the verifier must obtain an approved issuer key through its own trust channel.
+Signing uses a key pair: a private key that only the signer holds, and a public key that anyone can use to check the signature. The script below makes one pair and signs the record with the private key. It saves only the public key, so you can check the record later in a separate run. Keep that public key apart from the records you receive, because a record cannot vouch for its own key. In a real deployment, the verifier must obtain an approved issuer key through its own trust channel.
 
 ## Emit a Trust Record (standalone)
 
@@ -87,11 +89,11 @@ PASS: changed record rejected
 Saved session.trace.json and issuer-public.pem; no hardware attestation
 ```
 
-The policy and build hashes are placeholders. A valid signature binds these declarations; it does not prove that a model ran or a policy was enforced.
+The policy and build hashes are placeholders. (A hash is a short fingerprint of a file: change one byte and the fingerprint changes.) A valid signature locks these statements in place; it does not prove that a model ran or a policy was enforced.
 
 ## Emit with a persistent key
 
-The example's private key exists only in memory. Its saved public key can still verify earlier records after the process exits. To sign future records as the same issuer, retain the private key through an approved key-management mechanism. See [signing your first trust record](tutorials/signing-your-first-trust-record.md) for signing APIs and [verification](verification.md) for trust and revocation requirements.
+The example's private key exists only while the script runs. Its saved public key can still verify earlier records after the process exits. To sign future records as the same issuer, retain the private key through an approved key-management mechanism. See [signing your first trust record](tutorials/signing-your-first-trust-record.md) for signing APIs and [verification](verification.md) for trust and revocation requirements.
 
 ## Verify
 
@@ -110,7 +112,7 @@ verify_record(record, public_key_or_jwk=trusted_key)
 print("PASS: saved record verified against the retained public key")
 ```
 
-Expected: `PASS: saved record verified against the retained public key`. Verification uses a default maximum age of 24 hours, so rerun the first script if the demo record has expired. A wrong key, changed record, or stale timestamp must fail; investigate the error instead of enabling embedded-key trust to make it pass.
+Expected: `PASS: saved record verified against the retained public key`. By default a record older than 24 hours is refused, so rerun the first script if the demo record has expired. A wrong key, changed record, or stale timestamp must fail; investigate the error instead of enabling embedded-key trust to make it pass.
 
 ## What you now have
 
@@ -122,11 +124,11 @@ Expected: `PASS: saved record verified against the retained public key`. Verific
 | `runtime.platform: software-only` | This example provides no hardware provenance |
 | `appraisal.status: none` | No external appraisal occurred |
 
-The verification call above does not check hardware attestation or registry inclusion. Production verification also needs an issuer trust policy and any required revocation, nonce, measurement, and transparency checks.
+The verification call above does not check hardware attestation or whether the record was published to a registry. Production verification also needs an issuer trust policy and any required revocation, nonce, measurement, and transparency checks.
 
-## Add hardware attestation (Level 2)
+## Add hardware evidence and transparency (Levels 1 and 2)
 
-Follow the [cMCP integration guide](integration/cmcp.md), [trust levels](trust-levels.md), and [platform documentation](platforms/index.md). Hardware evidence and transparency receipts require their own generation and verification steps. Installing a runtime or declaring a hardware platform does not automatically establish a conformance level.
+To show that a record came from protected hardware, follow the [cMCP integration guide](integration/cmcp.md), [trust levels](trust-levels.md), and [platform documentation](platforms/index.md). Hardware evidence and transparency receipts require their own generation and verification steps. Installing a runtime or declaring a hardware platform does not automatically establish a conformance level.
 
 ## Troubleshooting
 
diff --git a/docs/references-registry.md b/docs/references-registry.md
index c5430de3..3d0f60af 100644
--- a/docs/references-registry.md
+++ b/docs/references-registry.md
@@ -1,5 +1,7 @@
 # The `references` relation registry
 
+A Trust Record can point at facts kept somewhere else, such as a human approval or a test result. Each pointer carries a label, `rel`, that says what kind of thing it points at. This page lists the agreed labels, what each one points at, and how to propose a new one. It is for people building tools that write or read these pointers.
+
 Informative. The registered values of `references[].rel` (§3.1.2), what each one's
 referenced object is, what a verifier may conclude from a resolved one, and how a name
 is added.
@@ -37,6 +39,8 @@ schema description, in `docs/schema.md`, or in this document.
 
 ## Registered values
 
+The five labels agreed so far, what each one points at, and where it is defined:
+
 | `rel` | Referenced object | Defined in | Example |
 |---|---|---|---|
 | `authorized-intent` | An authorization decided before execution, held in another system | §3.1.2; one mapping in [`crosswalks/nkemba-institutional-reconstruction.md`](crosswalks/nkemba-institutional-reconstruction.md) | none committed |
diff --git a/docs/repository-consolidation.md b/docs/repository-consolidation.md
index 10db6de6..73aa0093 100644
--- a/docs/repository-consolidation.md
+++ b/docs/repository-consolidation.md
@@ -1,5 +1,7 @@
 # Conformance repository consolidation
 
+The TRACE test suite (the conformance tests that check whether an implementation follows the specification) used to live in its own repository, trace-tests. It now lives in this repository, in the `conformance/` folder. This page records how it was moved, what was kept byte for byte, and the steps left before the old repository is archived. It is for maintainers; if you only want to run the tests, see the commands under [Validation and maintenance](#validation-and-maintenance).
+
 The conformance suite is maintained in `trace-spec/conformance/`. It remains a separate Apache-2.0 Python distribution named `agentrust-trace-tests`, with the `trace_tests` import and `trace-tests` CLI. The normative specification's licensing and the root `agentrust-trace` package remain as described in their existing files.
 
 ## Imported source
diff --git a/docs/rfcs/a2a-delegation-profile.md b/docs/rfcs/a2a-delegation-profile.md
index fecf7408..d3cab573 100644
--- a/docs/rfcs/a2a-delegation-profile.md
+++ b/docs/rfcs/a2a-delegation-profile.md
@@ -1,5 +1,7 @@
 # RFC Proposal: A2A delegation-link verification profile
 
+When one AI agent hands a task to another, each can write a TRACE record, and the later record points back to the earlier one (a delegation link). This proposal sets out how a checker follows those links and decides whether each hand-off was allowed. It is for people building verifiers, or agents that pass work to each other over A2A (the agent-to-agent protocol). It is a draft: nothing in it binds an implementation yet, and it ships with 24 test vectors so independent implementations can be compared.
+
 **Status:** Draft proposal. Binds nothing.
 **Scope:** Verification rules for the existing `delegation` block. No schema change.
 **Target:** `spec/trace-v0.2.md` §3.1 surface, for the v0.3 A2A profile named in `ROADMAP.md`.
@@ -11,25 +13,28 @@ implementation; this file is informative until its rules are adopted, at which p
 become uppercase in `spec/` and this file becomes a pointer to where they went. A proposal
 that writes itself in the imperative is a specification nobody agreed to.
 
-**Why the corpus was built before the rules.** The three decisions in §4 were not read out of
-the existing text. They were hit, because no vector could be written without settling them, and
-in each case the text supports both branches. A reader passes over all three without noticing;
-someone building a fixture cannot get to the end of one. That order: corpus first, and let it
-interrogate the text: is the part of this document worth keeping if the rules themselves are
-replaced, because it produces a measurement the repository does not otherwise have.
-
-Not *do the tests cover the rules*, which measures an implementation. **Do two independent
-readings of the same normative text produce the same rules**, which measures the
-specification. Where two readings agree, the text is doing its job; where they diverge, the
-text is under-specified, and the divergence names the sentence that is missing. §7.1 is that
-measurement run once, on two implementations that were written without reference to this
-document: on the digest preimage they agree with §4.1 and with each other, and on the
-unresolvable-algorithm question they split: one treats it as unreadable and one as tampering.
-The first is the text working. The second is a missing sentence, located, in one line, and it
-took no argument to find because two implementations were asked the same question.
-
-A single reading measures nothing. That is the case for a second profile design rather than
-against one.
+The test vectors were written before the rules, on purpose. Writing them surfaced three questions the current text leaves open (§4), and comparing two independent implementations against them (§7.1) shows where the specification text is still missing a sentence.
+
+??? info "Technical detail: why the corpus was built before the rules"
+    The three decisions in §4 were not read out of
+    the existing text. They were hit, because no vector could be written without settling them, and
+    in each case the text supports both branches. A reader passes over all three without noticing;
+    someone building a fixture cannot get to the end of one. That order: corpus first, and let it
+    interrogate the text: is the part of this document worth keeping if the rules themselves are
+    replaced, because it produces a measurement the repository does not otherwise have.
+
+    Not *do the tests cover the rules*, which measures an implementation. **Do two independent
+    readings of the same normative text produce the same rules**, which measures the
+    specification. Where two readings agree, the text is doing its job; where they diverge, the
+    text is under-specified, and the divergence names the sentence that is missing. §7.1 is that
+    measurement run once, on two implementations that were written without reference to this
+    document: on the digest preimage they agree with §4.1 and with each other, and on the
+    unresolvable-algorithm question they split: one treats it as unreadable and one as tampering.
+    The first is the text working. The second is a missing sentence, located, in one line, and it
+    took no argument to find because two implementations were asked the same question.
+
+    A single reading measures nothing. That is the case for a second profile design rather than
+    against one.
 
 ---
 
diff --git a/docs/rfcs/composable-zk-assurance.md b/docs/rfcs/composable-zk-assurance.md
index 2821904e..22a95bf2 100755
--- a/docs/rfcs/composable-zk-assurance.md
+++ b/docs/rfcs/composable-zk-assurance.md
@@ -1,5 +1,7 @@
 # RFC Proposal: Composable Zero-Knowledge Proofs for TRACE
 
+This proposal, from Florian Kluge of o1Labs, suggests adding zero-knowledge proofs to TRACE. A zero-knowledge proof lets someone check that a calculation was done correctly without seeing the private data behind it. The proposal treats it as a separate kind of evidence that can be used alone or together with hardware attestation. It is a draft for discussion and changes nothing in the current specification.
+
 **Status:** Draft issue proposal
 **Author:** Florian Kluge
 **Organisation:** o1Labs
diff --git a/docs/rfcs/composite-component-appraisal.md b/docs/rfcs/composite-component-appraisal.md
index 7ee40ebf..05e96b22 100644
--- a/docs/rfcs/composite-component-appraisal.md
+++ b/docs/rfcs/composite-component-appraisal.md
@@ -1,5 +1,7 @@
 # RFC Proposal: composite component appraisal, and knowing which part failed
 
+Today a TRACE record gives one verdict for the whole agent. This proposal gives each part (the code, the model, the policy, the processor, the tools) its own verdict, so that when something fails the reader can see which part and fix the right thing. It is for people who write verifiers or set access rules for agents. It is a draft and binds nothing yet.
+
 **Status:** Draft proposal. Binds nothing.
 **Scope:** Components with stable IDs, a status per component, digest-bound evidence references, freshness, two relationship methods, delegated component appraisers, and a composite result the verifier derives rather than reads. Additive; every v0.2 record stays valid.
 **Target:** the verifier-issued token in the companion proposal, [`verifier-issued-trace-profile.md`](verifier-issued-trace-profile.md), and `spec/` only if both are adopted.
diff --git a/docs/rfcs/runtime-evidence-profile.md b/docs/rfcs/runtime-evidence-profile.md
index 523911bc..e5240b12 100644
--- a/docs/rfcs/runtime-evidence-profile.md
+++ b/docs/rfcs/runtime-evidence-profile.md
@@ -1,5 +1,7 @@
 # RFC Proposal: runtime evidence, and what a verifier may conclude without it
 
+A v0.2 record can name a hardware platform, but that name is only the producer's claim. This proposal lets a record carry the hardware's own signed report (attestation evidence), and sets out what a checker may conclude with and without it, as a small set of grades. It is a draft for v0.3, aimed at verifier authors, and its 14 test vectors are built on a real Intel TDX report.
+
 **Status:** Draft proposal. Binds nothing.
 **Scope:** A `runtime.evidence` member, the rules for checking it, and the grades a verifier may report. Additive; every v0.2 record stays valid.
 **Target:** `spec/trace-v0.2.md` §3.1 and §5, for v0.3.
diff --git a/docs/rfcs/tool-catalog-observed-digest.md b/docs/rfcs/tool-catalog-observed-digest.md
index d3d73f05..6e14c955 100644
--- a/docs/rfcs/tool-catalog-observed-digest.md
+++ b/docs/rfcs/tool-catalog-observed-digest.md
@@ -1,5 +1,7 @@
 # Tool-catalog observed digest: a recomputable preimage for `tool-catalog` components
 
+When an agent connects to an MCP server, the server sends a list of the tools it offers (its tool catalog). This note fixes one way to turn that list into a fingerprint (a digest) that anyone holding the same list can recompute and compare, without asking anyone else for the value. It is for people building gateways and verifiers, and it is a draft that binds nothing.
+
 **Status:** Draft, informative. Binds nothing.
 **Scope:** How the `observed_digest` of a `tool-catalog` component is derived from the `tools/list` a server served, so that a relying party can set `expected_observed_digest` from bytes it holds and a second implementation can recompute every value from the same bytes. Two counterexamples, digest-mismatch and wrong-subject, with the pinned bytes they recompute from.
 **Target:** `TR-COMP-MCP-001` in [`composite-component-appraisal.md`](composite-component-appraisal.md), and input to open question 6 there. What an `mcp-server` component rests on (endpoint identity, transport key binding) and the server-to-catalog relationship method (`TR-COMP-MCP-002`) stay open.
diff --git a/docs/rfcs/verifier-issued-trace-profile.md b/docs/rfcs/verifier-issued-trace-profile.md
index ffc4133d..5f847c2a 100644
--- a/docs/rfcs/verifier-issued-trace-profile.md
+++ b/docs/rfcs/verifier-issued-trace-profile.md
@@ -1,5 +1,7 @@
 # RFC Proposal: a verifier-issued, holder-bound TRACE token
 
+Today an agent signs its own TRACE record. This proposal adds a second kind of token, signed by an independent checker (a verifier) after it has assessed the agent, which only the agent it describes can present, because presenting it takes a key that agent holds. It is for people building gateways that decide whether to let an agent act. The format is experimental and can still change.
+
 **Status:** Draft proposal. Binds nothing. Experimental wire, `urn:agentrust:trace:verifier-token:experimental-v1`.
 **Scope:** A new signed token in which an appraisal verifier signs the result and `cnf` names a different key, held by the agent that presents it; a holder proof; and a separately signed gateway decision receipt. Additive: every v0.2 record keeps its meaning, and a v0.2 verifier refuses the new token as an unsupported profile.
 **Target:** a new profile document next to `spec/trace-v0.2.md`, not an edit to it.
diff --git a/docs/schema.md b/docs/schema.md
index 06c81c29..3fbe6bb0 100644
--- a/docs/schema.md
+++ b/docs/schema.md
@@ -2,18 +2,23 @@
 
 # Schema Reference {#trace-schema}
 
-JSON Schema for the TRACE v0.2 Trust Record. Source: [`schema/trace-claim.json`](https://github.com/agentrust-io/trace-spec/blob/main/schema/trace-claim.json).
+This page lists every field a TRACE v0.2 Trust Record can contain, its type, and whether it is required. A Trust Record is the signed receipt TRACE produces for one AI agent run. Use this page when you write code that produces or reads records; if you only want to see one working, start with the [quickstart](quickstart.md).
 
-Every field typed `integer` here is bounded to -9007199254740991 through 9007199254740991, and no field is
-typed `number`. That is not a size limit on the data; it is what spec section 3.2.2 can canonicalize
-unambiguously, since RFC 8785 serializes numbers through an IEEE 754 double and two integers outside that range
-can share one. A value that needs to be larger is carried as a string. The same bound applies to members a
-`cnf.jwk` carries that this schema does not name.
+The machine-readable version is a JSON Schema (a file that software uses to check a record has the right shape): [`schema/trace-claim.json`](https://github.com/agentrust-io/trace-spec/blob/main/schema/trace-claim.json).
 
-Whether a number is an integer is decided by its value, not by how it is written (spec section 3.2.2, "What
-counts as an integer"). `1785000000.0` and `1.785e9` are the integer 1785000000; `1785000000.5` is not an
-integer. JSON Schema defines `integer` the same way, so validating against this schema already gives that
-answer.
+In short: whole numbers in a record have a size limit, and anything larger is written as a string. The detail is below.
+
+??? info "Technical detail: the integer range and what counts as an integer"
+    Every field typed `integer` here is bounded to -9007199254740991 through 9007199254740991, and no field is
+    typed `number`. That is not a size limit on the data; it is what spec section 3.2.2 can canonicalize
+    unambiguously, since RFC 8785 serializes numbers through an IEEE 754 double and two integers outside that range
+    can share one. A value that needs to be larger is carried as a string. The same bound applies to members a
+    `cnf.jwk` carries that this schema does not name.
+
+    Whether a number is an integer is decided by its value, not by how it is written (spec section 3.2.2, "What
+    counts as an integer"). `1785000000.0` and `1.785e9` are the integer 1785000000; `1785000000.5` is not an
+    integer. JSON Schema defines `integer` the same way, so validating against this schema already gives that
+    answer.
 
 <a id="top-level-fields"></a>
 
@@ -43,7 +48,7 @@ answer.
 
 ## `model` {#trace-field-model}
 
-Binds the model artifact used in this session.
+Which AI model the run used. These fields tie the record to one exact model artifact (the model file and version).
 
 | Field | Type | Required | Description |
 |---|---|---|---|
@@ -57,7 +62,7 @@ Binds the model artifact used in this session.
 
 ## `runtime` {#trace-field-runtime}
 
-Binds the execution environment. Platform-specific fields vary by TEE type.
+Where the run happened: the machine or protected environment it ran in. Some fields depend on the platform, for example which kind of TEE (trusted execution environment, a hardware-isolated area of a processor) was used.
 
 | Field | Type | Required | Description |
 |---|---|---|---|
@@ -71,7 +76,7 @@ Binds the execution environment. Platform-specific fields vary by TEE type.
 
 ## `policy` {#trace-field-policy}
 
-Binds the governance policy in force during this session.
+Which rule set (the governance policy) was in force during the run, pinned by its hash.
 
 | Field | Type | Required | Description |
 |---|---|---|---|
@@ -94,7 +99,7 @@ Custom values are allowed and should follow your organization's data classificat
 
 ## `tool_transcript` {#trace-field-tool-transcript}
 
-Audit summary of tool invocations during the session.
+A summary of the tool calls the agent made during the run, with a hash that commits to the full list.
 
 | Field | Type | Required | Description |
 |---|---|---|---|
@@ -106,7 +111,7 @@ Audit summary of tool invocations during the session.
 
 ## `delegation` {#trace-field-delegation}
 
-A2A profile. Present when this execution acted on authority delegated by another agent; absent on a root (non-delegated) execution. A chain of records linked this way forms an offline-verifiable delegation DAG: a verifier walks `parent_record_hash` from a leaf record back to the root and confirms each hop acted under a credential in the delegation chain.
+Used when another agent handed this agent the authority to act (delegation, defined by the A2A profile). Present when this execution acted on authority delegated by another agent; absent on a root (non-delegated) execution. A chain of records linked this way forms an offline-verifiable delegation DAG: a verifier walks `parent_record_hash` from a leaf record back to the root and confirms each hop acted under a credential in the delegation chain.
 
 | Field | Type | Required | Description |
 |---|---|---|---|
@@ -117,7 +122,7 @@ A2A profile. Present when this execution acted on authority delegated by another
 
 ## `origin` {#trace-field-origin}
 
-Absent means the runtime produced its own record, which is what every hardware profile is and what a consumer assumes. Present means something else assembled the record from evidence it did not itself measure.
+Says who assembled the record. Absent means the runtime produced its own record, which is what every hardware profile is and what a consumer assumes. Present means something else assembled the record from evidence it did not itself measure.
 
 It exists because `runtime.platform: "software-only"` is ambiguous on its own: it is the honest value for a dev-mode record, where nothing attested the execution, and for a record transcribed from another vendor's control plane, where the party asserting the evidence also wrote the log.
 
@@ -154,6 +159,8 @@ Spec section 3.1.2 also binds verifiers: one **must not** reject a record becaus
 
 ## `reproducibility` {#trace-field-reproducibility}
 
+In plain terms: a claim that someone can re-run the part of the run that decided what happened, and get the same transcript. The precise boundary follows.
+
 The claim that re-executing a named deterministic function of the run, over a pinned input closure, yields a transcript whose RFC 8785 canonical digest equals `transcript_digest`. Spec section 3.1.4. The function is the producer's coordination logic: the code that decided what ran, in what order, on what inputs. It is not the workload's side effects, which are not re-executed, and not the model calls, which are not deterministic; the boundary is drawn around every non-deterministic interaction, and each one enters the closure as a recorded, content-addressed input.
 
 The block is the claim, not its result. The result is an appraisal attributed to the party that re-ran the function (in a record signed only by its producer, the producer's report of that party's result, not authenticated by it), carried under [`appraisal.method`](#trace-field-appraisal) and `appraisal.re_execution`. A record earns no assurance from the claim: `runtime.platform` is untouched by it, as it is by `references`, and the record signature covers it.
@@ -182,7 +189,7 @@ Signed vectors that exercise the claim and its result, two per rule the schema e
 
 ## `build_provenance` {#trace-field-build-provenance}
 
-Build-time provenance binding the deployed artifact.
+Where the deployed software came from: which build system produced it and the digest (fingerprint) of what it built, following SLSA, a common format for signed build records.
 
 | Field | Type | Required | Description |
 |---|---|---|---|
@@ -196,7 +203,7 @@ Build-time provenance binding the deployed artifact.
 
 ## `appraisal` {#trace-field-appraisal}
 
-Verifier judgment on the evidence in this record.
+A verifier's judgment on the evidence in this record, and who made it.
 
 | Field | Type | Required | Description |
 |---|---|---|---|
@@ -229,7 +236,7 @@ String. URI of the SCITT transparency log entry anchoring this record. Omitted,
 
 ## `cnf` {#trace-field-cnf}
 
-Confirmation method. Contains the signing key bound to this record.
+Confirmation method: the public key bound to this record, which a verifier uses to check the record's signature.
 
 | Field | Type | Description |
 |---|---|---|
diff --git a/docs/trust-levels.md b/docs/trust-levels.md
index b811b435..8a4a1774 100644
--- a/docs/trust-levels.md
+++ b/docs/trust-levels.md
@@ -6,7 +6,13 @@ description: Understand TRACE's software, hardware, and transparency evidence le
 
 # Trust Levels {#trace-trust-levels}
 
-TRACE's conformance suite groups checks into three levels. A level describes required checks; it is not a blanket guarantee that an agent behaved correctly. The recipient supplies trust anchors, evidence, and an acceptance policy.
+This page explains the three levels of evidence a TRACE record can carry, from a plain software signature up to hardware proof and a public log entry. Read it if you produce records and need to know what each level asks of you, or if you receive records and need to decide how much to trust them.
+
+TRACE's conformance suite (the public set of tests an implementation runs to show it follows the specification) groups its checks into three levels. A level describes which checks are required; it is not a blanket guarantee that an agent behaved correctly. The recipient still supplies its own trust anchors (the keys and roots it already trusts), the evidence, and the rules for what it will accept.
+
+- **Level 0, software:** the record is signed with a key held in ordinary software.
+- **Level 1, hardware evidence:** the record also carries a signed report from the processor showing where it ran.
+- **Level 2, transparency:** the record is also published to an append-only log that others can audit.
 
 ## Summary
 
@@ -22,21 +28,26 @@ See the [suite's level definitions](https://tests.agentrust-io.com/docs/levels/)
 
 ## Level 0: software-only {#trace-l0}
 
-A software-held key signs the record. `software-only` identifies the absence of hardware assurance. A recipient checks the signature against a key obtained through its own trust channel; the key embedded in an incoming record cannot establish its own authority.
+A key held in ordinary software signs the record. The platform value `software-only` says plainly that no hardware backs the record. A recipient checks the signature against a key obtained through its own trust channel; the key embedded in an incoming record cannot establish its own authority.
 
-A valid signature authenticates the key's statement. It does not prove that a policy ran or an action completed. A privileged party holding that key can sign other statements.
+A valid signature shows that the holder of that key made the statement. It does not prove that a policy ran or an action completed, and anyone who controls that key can sign other statements too.
 
-`runtime.measurement` is required on every record, including `software-only` ones. Under `software-only`, the field is not a hardware measurement: it is a software commitment defined by the producing profile (for example, a hash over an image digest and policy bundle, or over a chain-tip), and that profile must document its preimage so a verifier can recompute it. All-zero (`sha256:000...000`) is reserved for a producer that has no commitment to offer at all, such as a bare development record with nothing measured; it is not the default for `software-only` in general. The `appraisal.status` of `"none"` is correct when no hardware verifier is in the path. Use the [quick start](quickstart.md) for a complete runnable record rather than copying abbreviated field examples.
+Every record, even a software-only one, carries a `runtime.measurement` value, and `appraisal.status` is `"none"` when no hardware checker was involved. Use the [quick start](quickstart.md) for a complete runnable record rather than copying abbreviated field examples.
+
+??? info "Technical detail: `runtime.measurement` on a software-only record"
+    `runtime.measurement` is required on every record, including `software-only` ones. Under `software-only`, the field is not a hardware measurement: it is a software commitment defined by the producing profile (for example, a hash over an image digest and policy bundle, or over a chain-tip), and that profile must document its preimage so a verifier can recompute it. All-zero (`sha256:000...000`) is reserved for a producer that has no commitment to offer at all, such as a bare development record with nothing measured; it is not the default for `software-only` in general. The `appraisal.status` of `"none"` is correct when no hardware verifier is in the path.
 
 <a id="level-1-hardware-evidence"></a>
 
 ## Level 1: hardware evidence {#trace-l1}
 
+At Level 1 the record also points to evidence from the hardware it ran on. Confidential-computing processors from AMD, Intel and NVIDIA can produce a signed report (called a quote or attestation) describing the protected environment, and a verifier checks that report against the manufacturer's keys. It also records build provenance: where the software came from and how it was built.
+
 | Build-provenance field | Schema range |
 |---|---|
 | `build_provenance.slsa_level` | SLSA Build Level (0-3); verify the supporting provenance separately |
 
-A hardware-backed deployment needs authenticated evidence binding the record-signing key to the expected environment. Merely changing `runtime.platform`, copying a nonzero digest, or setting `appraisal.status="affirming"` does not establish that evidence.
+A hardware-backed deployment needs authenticated evidence tying the record-signing key to the expected environment. Merely changing `runtime.platform`, copying a nonzero digest, or setting `appraisal.status="affirming"` does not establish that evidence.
 
 Use the standalone platform identifiers from the [schema](https://github.com/agentrust-io/trace-spec/blob/main/schema/trace-claim.json), not a runtime's configuration aliases. Provider guarantees differ: a TPM quote is not equivalent to protecting application memory in a confidential VM. See [attestation platforms](platforms/index.md).
 
@@ -46,9 +57,9 @@ Use the standalone platform identifiers from the [schema](https://github.com/age
 
 ## Level 2: transparency anchoring {#trace-l2}
 
-Level 2 adds transparency and transcript requirements to the lower levels. A `transparency` URI is a reference, not an inclusion proof. The verifier needs proof bound to the record and a log or checkpoint it independently trusts. Inclusion does not establish that every event was logged or that each claim is true.
+Level 2 adds two things on top of the lower levels: the record is published to a transparency log (an append-only public list that nobody can quietly edit), and the record commits to the transcript of tool calls the agent made. A `transparency` URI is a reference, not an inclusion proof. The verifier needs proof bound to the record and a log or checkpoint it independently trusts. Inclusion does not establish that every event was logged or that each claim is true.
 
-Changing any signed field, including `transparency`, changes the signature preimage. Re-sign after adding or changing that field. The [registry anchor format](../spec/registry-anchor-v1.md) defines which bytes the anchor commits to; the receipt must match that format and the signed record being checked.
+Changing any signed field, including `transparency`, changes the bytes the signature covers. Re-sign after adding or changing that field. The [registry anchor format](../spec/registry-anchor-v1.md) defines which bytes the anchor commits to; the receipt must match that format and the signed record being checked.
 
 For the worked sequence, see [anchoring to the registry](tutorials/anchoring-to-the-registry.md). A software-only record does not become hardware-backed simply because it is logged.
 
@@ -56,6 +67,6 @@ For the worked sequence, see [anchoring to the registry](tutorials/anchoring-to-
 
 ## Choosing an acceptance policy {#trace-acceptance-policy}
 
-Decide which issuer, hardware evidence, artifact commitments, freshness, revocation status, and log you require for the operation. A successful signature check is only one input to that decision. These levels do not certify regulatory compliance or replace application authorization.
+An acceptance policy is your own rule for when you will rely on a record. Decide which issuer, hardware evidence, artifact commitments, freshness, revocation status, and log you require for the operation. A successful signature check is only one input to that decision. These levels do not certify regulatory compliance or replace application authorization.
 
 Read [verification protocol](verification.md) for the checks and [limitations](../LIMITATIONS.md) for the remaining boundaries.
diff --git a/docs/tutorials/agt-adapter.md b/docs/tutorials/agt-adapter.md
index 8686ddd9..ffae7ac9 100644
--- a/docs/tutorials/agt-adapter.md
+++ b/docs/tutorials/agt-adapter.md
@@ -1,6 +1,8 @@
 # Build a TRACE Record from AGT Session Inputs
 
-Map policy bytes and audit entries into a signed software record. This local example uses synthetic inputs; it does not run AGT, call a model, or appraise hardware.
+This page is for developers who use AGT (the Agent Governance Toolkit, open-source software that checks an AI agent's actions against rules) and want each session to produce a TRACE record. You will turn a session's rule file and its log of tool calls into a signed record on your own computer, in about one minute.
+
+The example uses made-up inputs. It does not run AGT, call an AI model, or check any hardware.
 
 ## Setup
 
@@ -42,16 +44,23 @@ assert "transparency" not in signed
 print("PASS: mapped and signed synthetic session; no hardware appraisal or registry anchor")
 ```
 
-The nonzero build digest is illustrative metadata, not verified build provenance. The chain tip is synthetic. The example checks mapping and a software signature only.
+The script prints `PASS` when the session has been turned into a record and signed. Some values are placeholders: the build digest (a fingerprint meant to identify how the software was built) is illustrative, and nobody checked it, and the chain tip (the last link in AGT's tamper-evident log) is made up. So the example checks two things only: that the fields were filled in correctly, and that the software signature works.
 
 ## Use real session evidence
 
-Supply the exact policy bytes used for the session, audit entries as plain dictionaries, the session's chain tip, and its authenticated identity. The adapter hashes the audit list with RFC 8785 and the chain-tip string as UTF-8. Its default call count is the list length; supply `call_count` only when your producing profile defines a different count.
+For a real session, pass in four things: the exact rule file (policy) the session used, byte for byte; the log entries as plain dictionaries; the session's chain tip; and the agent's checked identity. The adapter turns the log and the chain tip into fingerprints (hashes) that go into the record. By default it counts one call per log entry.
+
+The record says which enforcement mode you configured, meaning whether the rules were meant to block actions or only to be noted. Writing the mode down does not prove the rules ran. That is why the adapter has no default and makes you choose the mode yourself. This tutorial passes `"declared"` because no rule engine ran on the made-up input. Pass the mode your deployment really ran under.
+
+The appraisal status (whether anyone checked the evidence) starts as `none` for the same reason. Building a record is not checking it. Before signing, set each claim to match the checks that really happened.
+
+??? info "Technical detail: how the adapter hashes its inputs and why the defaults are what they are"
+    The adapter hashes the audit list with RFC 8785 and the chain-tip string as UTF-8. Its default call count is the list length; supply `call_count` only when your producing profile defines a different count.
 
-The adapter records the configured enforcement mode; it does not enforce that mode or prove the policy was evaluated. `enforcement_mode` is required and has no default: a default of `"enforce"` would claim an evaluation nobody saw, and spec section 4.3 says `"declared"` must not be a default. This tutorial passes `"declared"` because synthetic input ran through no policy engine; pass the mode your deployment actually ran under. This does not change runtime enforcement defaults or behavior.
+    The adapter records the configured enforcement mode; it does not enforce that mode or prove the policy was evaluated. `enforcement_mode` is required and has no default: a default of `"enforce"` would claim an evaluation nobody saw, and spec section 4.3 says `"declared"` must not be a default. This does not change runtime enforcement defaults or behavior.
 
-`appraisal.status` defaults to `none` for the same reason: building a record does not appraise it, and the field is the verifier's (spec section 3.3.1). Set the record's claims to the checks actually performed before signing.
+    `appraisal.status` defaults to `none` because the field is the verifier's (spec section 3.3.1).
 
 ## Verify and extend
 
-Recipients obtain the issuer key independently and use [record verification](verifying-a-trust-record.md). Add hardware evidence through a runtime-specific profile and verifier; adding a platform name is insufficient. For Level 2, also follow the [registry anchor format](../../spec/registry-anchor-v1.md). Re-sign after changing signed fields.
+Whoever receives the record should get your public key through their own trusted channel, then follow [record verification](verifying-a-trust-record.md). To add hardware evidence, use a profile and checker built for that hardware; writing a hardware name into the record proves nothing by itself. For Level 2 (records also published to a public log), follow the [registry anchor format](../../spec/registry-anchor-v1.md). If you change any signed field, sign the record again.
diff --git a/docs/tutorials/anchoring-to-the-registry.md b/docs/tutorials/anchoring-to-the-registry.md
index 23d76c3a..ae3ac8fa 100644
--- a/docs/tutorials/anchoring-to-the-registry.md
+++ b/docs/tutorials/anchoring-to-the-registry.md
@@ -1,6 +1,8 @@
 # Anchoring a Trust Record to the TRACE registry
 
-After signing a Trust Record, you can anchor it to the TRACE transparency registry. An inclusion proof binds the signed record to a batch root. Any claim about when it existed also depends on authenticating and trusting the registry's checkpoint and timestamp.
+This page is for anyone who has signed a TRACE record and wants a public, hard-to-rewrite trace that the record existed. You will add the record to the TRACE registry (a public, append-only log of records), get back a small proof that it is in there, and check that proof yourself.
+
+The proof shows your exact signed record is part of one batch in the registry. Any claim about *when* the record existed also depends on trusting the registry's own published history and its timestamps, which you check separately.
 
 **What you need:** A signed Trust Record (from [Signing your first trust record](signing-your-first-trust-record.md)).
 
@@ -13,16 +15,21 @@ After signing a Trust Record, you can anchor it to the TRACE transparency regist
 
 ## Why transparency anchoring matters
 
-A Trust Record carries a signature from the issuer's key. A verifier holding that key can confirm the record has not been modified, but only if the key is trustworthy. If the issuer is later compromised, an attacker holding the key could forge records backdated to before the compromise.
+A signed record shows it has not changed since the issuer (whoever produced it) signed it, as long as you trust the issuer's key. Keys can be stolen. If that happens, the thief could sign fake records and date them before the theft, and the signature alone could not tell them apart.
+
+Anchoring adds a second, independent witness: the registry. Once a record is in a published registry batch, a later forger cannot slip a backdated record into that batch. The check only counts if you get the registry entry from the registry itself. A record, proof and registry entry that all arrive from the same untrusted sender only show that the three agree with each other.
 
-Anchoring introduces a separate trust input: the registry entry or checkpoint. A verifier recomputes the Merkle root from the record and proof and compares it to an independently authenticated entry. Accepting a record, proof, and root from the same untrusted sender establishes only internal consistency. Check the registry's append-only history and timestamp policy separately.
+??? info "Technical detail: Merkle proofs and the two canonical forms"
+    A verifier recomputes the Merkle root from the record and proof and compares it to an independently authenticated entry. Check the registry's append-only history and timestamp policy separately.
 
-The normative format is [TRACE Registry Anchor Format v1](../../spec/registry-anchor-v1.md). Read §0 of it before you implement anything: TRACE uses **RFC 8785 (JCS)** to canonicalize a record for *signing* and **sorted-key JSON** to canonicalize it for the *anchor leaf*. Assuming JCS at the leaf produces proofs that never verify, and the failure has no useful diagnostic.
+    The normative format is [TRACE Registry Anchor Format v1](../../spec/registry-anchor-v1.md). Read §0 of it before you implement anything: TRACE uses **RFC 8785 (JCS)** to canonicalize a record for *signing* and **sorted-key JSON** to canonicalize it for the *anchor leaf*. Assuming JCS at the leaf produces proofs that never verify, and the failure has no useful diagnostic.
 
 ---
 
 ## The `transparency` field
 
+The record has one field, `transparency`, that points at its registry entry. It is optional for Levels 0 and 1 and needed from Level 2 up.
+
 In the `TrustRecord` schema, `transparency` is optional below Level 2:
 
 ```python
@@ -37,7 +44,7 @@ Where present, it identifies the registry entry anchoring the record. At Level 2
 
 ## Step 1: Sign the record
 
-Sign the final record. Leave `transparency` absent if the registry entry URI is not known yet; distribute the receipt separately. If the registry supports reserving an entry URI, set that URI before signing and submit those exact signed bytes. Do not invent a placeholder URI.
+Sign the record in its final form first, because the registry stores the exact signed bytes. Leave `transparency` absent if the registry entry URI is not known yet; distribute the receipt separately. If the registry supports reserving an entry URI, set that URI before signing and submit those exact signed bytes. Do not invent a placeholder URI.
 
 ```python
 import time
@@ -67,7 +74,7 @@ signed = sign_record(record, key)
 
 ## Step 2: Submit the record
 
-Producers submit signed records to the registry's staging area, one JSON file per record. The anchor pipeline runs on a schedule, groups pending records by producer, builds one Merkle batch per group, and writes both the registry entry and one inclusion proof per record.
+You hand the signed record to the registry's staging area (a waiting area), one JSON file per record. On a schedule, the registry collects waiting records, groups them by who produced them, seals each group into a batch, and writes back the registry entry plus one inclusion proof (the evidence your record is in the batch) for each record.
 
 You do not have to use the reference registry. Anything implementing [Anchor Format v1 §8](../../spec/registry-anchor-v1.md) works, and running your own is a reasonable choice for a deployment that cannot publish record bytes to a third party.
 
@@ -81,13 +88,13 @@ The pipeline writes one proof per submitted record:
 {"leaf_index": 0, "audit_path": ["sha256:...", "sha256:..."]}
 ```
 
-`leaf_index` is your record's position in the batch. `audit_path` is the sibling hash at each tree level, ordered leaf to root. A batch of one has an empty `audit_path`, which is valid and not an error.
+`leaf_index` is your record's position in the batch. `audit_path` is the list of fingerprints needed to rebuild the batch's top-level fingerprint from your record, ordered from your record upward (technically, the sibling hash at each Merkle tree level, leaf to root). A batch of one has an empty `audit_path`, which is valid and not an error.
 
 ---
 
 ## Step 4: Verify the proof yourself
 
-This is the step that matters, and the one most likely to be skipped. A proof you have never checked is a receipt, not evidence.
+This is the step that matters, and the one most likely to be skipped. A proof you have never checked is only a piece of paper. Checking it is what turns it into evidence.
 
 ```bash
 pip install trace-verify
@@ -115,13 +122,13 @@ The verifier is standard library only and small enough to read in one sitting. R
 
 ## Step 5: Preserve the anchored record
 
-Keep the signed object unchanged with its proof and registry entry. Adding `transparency` and re-signing creates a different object; the original proof no longer covers it. Submit that new object for anchoring if you change any signed field. A Level 2 workflow needs a registry arrangement that lets the final record name its entry before its bytes are committed.
+Store the signed record exactly as it is, together with its proof and registry entry. If you later add `transparency` and sign again, you have a different record, and the old proof no longer covers it. Submit that new record for anchoring if you change any signed field. A Level 2 setup needs a registry that can tell you the entry address before you sign, so the final record can name it.
 
 ---
 
 ## What this proves, and what it does not
 
-Inclusion verifies the exact signed object against the supplied batch root. Authenticity and timing depend on the separately trusted registry entry or checkpoint.
+A passing check shows this exact signed record is part of the registry batch you checked against. Whether that batch is genuine, and when it was made, depends on how you got the registry entry and whether you trust it.
 
 Signature verification is a separate question from inclusion, and `trace-verify` answers both: it verifies the producer's Ed25519 signature against the registered key unless you pass `--no-verify-signature`, which warns loudly, because inclusion alone does not prove the named producer signed anything. Exit code 0 means both passed.
 
diff --git a/docs/tutorials/hardware-attestation-platforms.md b/docs/tutorials/hardware-attestation-platforms.md
index 217cbd75..a8ee726c 100644
--- a/docs/tutorials/hardware-attestation-platforms.md
+++ b/docs/tutorials/hardware-attestation-platforms.md
@@ -1,11 +1,17 @@
 # Interpreting Hardware Attestation
 
-A platform name and measurement in a signed TRACE record are claims. To treat them as hardware evidence, a recipient needs authenticated attestation evidence, accepted reference values, and a binding to the signing key. This guide explains that distinction; it does not provision a TEE.
+This page is for anyone deciding whether a TRACE record really came from protected hardware. A record can name a hardware platform and a measurement (a fingerprint of the software that was loaded), but those are only the producer's claims until someone checks them. You will learn what has to be checked before you can rely on them.
+
+To count as hardware evidence, a recipient needs three things: attestation (a report signed by the processor itself, checked back to the chip maker), the expected measurement values the recipient has approved, and proof that the report is tied to the key that signed the record. This guide explains that difference; it does not set up a TEE (trusted execution environment, a sealed area of the processor that even the machine's operator cannot look into).
 
 ## Start with the right format
 
+TRACE records and cMCP session claims are two different file formats, and each has its own checker.
+
 Standalone TRACE records use the [canonical schema](https://github.com/agentrust-io/trace-spec/blob/main/schema/trace-claim.json). cMCP emits a distinct `RuntimeClaim` envelope and uses its own verifier. Do not pass that envelope directly to `agentrust_trace.verify_record`.
 
+The table lists each piece of evidence and what the recipient has to check before relying on it.
+
 | Evidence | What the recipient checks |
 |---|---|
 | Signed record | Schema, supported profile, trusted signing key, signature, freshness, configured revocation and nonce checks |
@@ -16,10 +22,12 @@ Standalone TRACE records use the [canonical schema](https://github.com/agentrust
 
 ## Software-only records
 
-`runtime.platform="software-only"` carries no hardware assurance. Its measurement can be a producer-defined software commitment; all-zero is appropriate only when no commitment is offered. Software-signed records can support uses whose trust policy accepts software key custody. They must not satisfy a requirement for verified hardware evidence.
+`runtime.platform="software-only"` means there is no hardware protection behind the record. Its measurement can be a fingerprint the producer chose to describe its software; all zeros means the producer offers none. A software-signed record is fine where your rules accept a signing key kept in ordinary software. They must not satisfy a requirement for verified hardware evidence.
 
 ## Hardware-specific evidence
 
+Each kind of hardware reports different values, and each page below explains what its values do and do not show.
+
 - [AMD SEV-SNP](../platforms/amd-sev-snp.md): distinguish the launch measurement from guest-supplied report data.
 - [Intel TDX](../platforms/intel-tdx.md): interpret MRTD and RTMRs under the producing profile.
 - [NVIDIA H100](../platforms/nvidia-h100.md): GPU appraisal does not automatically establish CPU workload or signing-key identity.
@@ -27,10 +35,10 @@ Standalone TRACE records use the [canonical schema](https://github.com/agentrust
 
 ## What the TRACE SDK does
 
-`verify_record` verifies the standalone signed object. It does not collect or appraise hardware quotes, fetch a Reference Integrity Manifest, or independently substantiate `appraisal.status`. There is no `verify-hardware` command in this package.
+`verify_record` checks the signature and contents of a standalone record. It does not collect or appraise hardware quotes, fetch a Reference Integrity Manifest, or independently substantiate `appraisal.status`. There is no `verify-hardware` command in this package.
 
 For cMCP evidence, use its [verification tutorial](https://cmcp.agentrust-io.com/tutorials/verifying-a-trace-claim/), approved policy/catalog hashes, and required attestation inputs. For a local software example, use [quick start](../quickstart.md).
 
 ## Report the checks performed
 
-Hardware appraisal corresponds to Level 1; Level 2 adds transparency anchoring. Report unavailable evidence as unavailable, and a contradictory result as a failure. A record that says `affirming` does not authorize an action without the recipient's own acceptance policy. See [trust levels](../trust-levels.md) and [verification outcomes](../verification-outcome-statements.md).
+Checking the hardware evidence is Level 1; Level 2 also publishes the record to a public log (transparency anchoring). Say which checks you ran. If evidence was missing, report it as missing, and if it contradicted the record, report a failure. A record that says `affirming` does not authorize an action without the recipient's own acceptance policy. See [trust levels](../trust-levels.md) and [verification outcomes](../verification-outcome-statements.md).
diff --git a/docs/tutorials/integrating-with-cmcp.md b/docs/tutorials/integrating-with-cmcp.md
index dfd32ffe..6e08b14e 100644
--- a/docs/tutorials/integrating-with-cmcp.md
+++ b/docs/tutorials/integrating-with-cmcp.md
@@ -1,6 +1,8 @@
 # Integration with cMCP
 
-Use cMCP's runtime verifier for its signed session claims. The standalone TRACE SDK and cMCP share evidence concepts, but their record envelopes are different.
+This page is for people running cMCP, a gateway that sits between an AI agent and its tools (MCP is the common protocol agents use to call tools) and checks each call against rules. It points you to the cMCP pages that create and check its signed session records, and explains where TRACE fits.
+
+cMCP and the standalone TRACE library describe the same kinds of evidence but package them in different formats, so use cMCP's own checker for cMCP's records.
 
 ## Walkthrough
 
@@ -12,10 +14,12 @@ These pages contain the runtime's maintained commands and complete examples. Do
 
 ## Trust boundary
 
+The gateway can only vouch for what passes through it.
+
 The gateway checks routed tool calls and records its decisions. It does not observe calls that bypass it, prove an upstream tool's internal behavior, or establish physical task completion. Its [architecture](https://cmcp.agentrust-io.com/concepts/) separates the client, gateway, tools, and evidence consumer.
 
-The signing key's hardware protection must be established by actual provider evidence and key binding. A development-mode claim remains software evidence. A claimed policy hash must be compared with an independently approved artifact, not copied from the incoming claim into the verifier's allowlist.
+The signing key's hardware protection must be established by actual provider evidence and key binding. In plain terms: a key only counts as hardware-protected when a report signed by the hardware says so and is tied to that key. A claim made in development mode is still software evidence. A claimed policy hash must be compared with an independently approved artifact, not copied from the incoming claim into the verifier's allowlist.
 
 ## TRACE levels
 
-Hardware appraisal supports Level 1. Level 2 adds a verified transparency anchor. Neither a TEE platform name nor the presence of a registry URL establishes those checks. See [trust levels](../trust-levels.md) and [verification protocol](../verification.md).
+TRACE grades evidence in levels. Checked hardware evidence supports Level 1. Level 2 adds a checked entry in a public log (a transparency anchor). Neither a TEE platform name nor the presence of a registry URL establishes those checks. See [trust levels](../trust-levels.md) and [verification protocol](../verification.md).
diff --git a/docs/tutorials/signing-your-first-trust-record.md b/docs/tutorials/signing-your-first-trust-record.md
index d011cf8c..42f0568f 100644
--- a/docs/tutorials/signing-your-first-trust-record.md
+++ b/docs/tutorials/signing-your-first-trust-record.md
@@ -1,23 +1,28 @@
 # Sign Your First Trust Record
 
-Sign a complete standalone TRACE record, then verify it using a separately retained public key. Start with the [quick start](../quickstart.md), which includes the source installation, complete script, expected output, and an edited-record rejection.
+This page is for developers producing their first TRACE record, a signed file describing one AI agent run. It explains what the signature protects and what it does not, so you can describe your record honestly.
+
+The steps themselves are in the [quick start](../quickstart.md): install, run one complete script, see the expected output, and watch an edited record get rejected. You sign a record, then check it with a copy of the public key you kept aside.
 
 ## What the signature covers
 
-`sign_record(record, key)` adds the public confirmation key and signs the RFC 8785 canonical representation of every field except `signature`. The confirmation key is part of the signed preimage. Changing the subject, policy hash, transcript, appraisal, or transparency reference requires a new signature.
+The signature covers every field in the record, plus the public key that matches the signing key. Change anything (the agent's name, the policy fingerprint, the tool-call log, the appraisal, the registry link) and the record needs a new signature.
+
+??? info "Technical detail: what exactly gets signed"
+    `sign_record(record, key)` adds the public confirmation key and signs the RFC 8785 canonical representation of every field except `signature`. The confirmation key is part of the signed preimage.
 
-`json.dumps(sort_keys=True)` is not a substitute for RFC 8785 canonicalization. Use the SDK signing function so non-ASCII strings and numeric constraints follow the same rules as verification.
+    `json.dumps(sort_keys=True)` is not a substitute for RFC 8785 canonicalization. Use the SDK signing function so non-ASCII strings and numeric constraints follow the same rules as verification.
 
 ## Keep trust separate
 
-Retain the public key when creating your local demo authority. A recipient of a production record obtains its trusted issuer key through an approved channel; the incoming record cannot choose that authority.
+Keep a copy of the public key when you create your demo signing key. In real use, whoever receives a record gets the producer's public key through a channel they already trust. The record cannot tell them which key to trust, since a forger would simply name their own.
 
-The embedded `cnf.jwk` supports key binding. It does not remove the need to distribute trust. `verify_record` requires a trusted key by default and performs schema/profile validation as well as signature verification. The explicit embedded-key option checks internal consistency only.
+The record carries its own copy of the public key (`cnf.jwk`), which ties the record to the key. That does not replace getting the key from a trusted source. `verify_record` asks for a trusted key by default, and checks the record's structure as well as its signature. The option to use the key inside the record only shows the record agrees with itself.
 
 ## Describe the evidence honestly
 
-The quick-start record contains synthetic claims and software signing. It does not run an agent, enforce policy, produce hardware attestation, or submit to a registry. `appraisal.status="none"` records that no appraisal was performed. Set `affirming` only for an appraisal actually performed by an authorized producer under a stated policy.
+The quick-start record contains made-up claims and a software signature. It does not run an agent, apply any rules, produce a hardware report, or publish to a registry. `appraisal.status="none"` says nobody checked the evidence. Set `affirming` only when an authorized producer really checked it under stated rules.
 
-A software measurement can be a documented commitment to inputs. Use an all-zero measurement only when no commitment is offered. Do not add a placeholder registry URI and describe it as an anchor.
+A software measurement can be a documented fingerprint of the inputs. Use an all-zero measurement only when no commitment is offered. Do not add a placeholder registry URI and describe it as an anchor.
 
 Continue to [verify a received record](verifying-a-trust-record.md), [hardware evidence](hardware-attestation-platforms.md), or [transparency anchoring](anchoring-to-the-registry.md).
diff --git a/docs/tutorials/verifying-a-trust-record.md b/docs/tutorials/verifying-a-trust-record.md
index 4e28515f..ed90b93c 100644
--- a/docs/tutorials/verifying-a-trust-record.md
+++ b/docs/tutorials/verifying-a-trust-record.md
@@ -1,10 +1,12 @@
 # Verify a Trust Record
 
-Verify a standalone TRACE record against a separately trusted issuer key, reject a changed record, and preserve the result of the revocation check. This walkthrough checks signed evidence; it does not authorize an agent action or appraise hardware.
+This page is for anyone who receives a TRACE record and needs to check it. You will confirm the record was signed by the producer you trust and has not been changed, watch an edited copy get rejected, and see how the result reports whether the key was checked for revocation (being withdrawn).
+
+A passing check tells you the record is authentic and unchanged. It does not approve whatever the agent did, and it does not check any hardware.
 
 ## Prerequisites
 
-Complete the [quick start](../quickstart.md) from a source checkout. It creates `session.trace.json` and `issuer-public.pem`. Run the blocks below from that directory, in one Python script. In production, obtain the issuer key through your own trust configuration rather than accepting a key supplied with an incoming record.
+Complete the [quick start](../quickstart.md) from a source checkout. It creates `session.trace.json` (the record) and `issuer-public.pem` (the producer's public key). Run the blocks below from that directory, in one Python script. In real use, get the producer's key from your own trusted settings, never from the record or the message it came with.
 
 ## Verify the record
 
@@ -21,7 +23,10 @@ assert result.revocation.outcome == "no_check_performed"
 print("signature and record checks passed; no revocation check performed")
 ```
 
-`verify_record` checks schema and profile, key binding and signature, record age, future clock skew, and any nonce/revocation inputs you configure. It requires a trusted key by default. `allow_embedded_key=True` is an explicit consistency-only option, not issuer authentication.
+`verify_record` checks that the record has the right structure, that the signature matches your trusted key, that the record is not too old or dated in the future, and any replay or revocation checks you set up. It asks for a trusted key by default. `allow_embedded_key=True` uses the key inside the record instead, which only shows the record agrees with itself; it does not tell you who produced it.
+
+??? info "Technical detail: the full list of checks"
+    `verify_record` checks schema and profile, key binding and signature, record age, future clock skew, and any nonce/revocation inputs you configure. `allow_embedded_key=True` is an explicit consistency-only option, not issuer authentication.
 
 The default maximum age is 24 hours. If the quick-start record has expired, recreate it. For historical evaluation, pin the evaluation time and retain the trust and revocation evidence used for that decision.
 
@@ -41,22 +46,24 @@ else:
     raise AssertionError("edited record accepted")
 ```
 
-The replacement subject is schema-valid, so this case reaches the signature check. A malformed field can fail schema validation earlier and does not exercise the same check.
+The new agent name is well formed, so the record passes the structure check and fails at the signature, which is the check this example is meant to show. A malformed field can fail schema validation earlier and does not exercise the same check.
 
 ## Revocation is a separate outcome
 
+Revocation means a producer's key has been withdrawn, for example after it was stolen. Checking for it needs a list of withdrawn keys, so the result reports it separately.
+
 Without a store or bundle, the result reports `no_check_performed`. A supplied bundle that cannot establish status can produce `unverified_for_revocation`; it does not necessarily raise. If your policy requires a current revocation check, inspect the result and refuse to proceed unless that requirement is satisfied.
 
 See [checking revocation status](../verification.md#checking-revocation-status) for store and bundle inputs, freshness bounds, and implementation limits.
 
 ## Appraisal and hardware claims
 
-A signed `appraisal.status` authenticates a statement about appraisal. This function does not independently verify the hardware report, expected measurement, policy execution, or transcript contents. Do not treat `affirming` or a non-software platform string as sufficient evidence to act.
+A signed `appraisal.status` proves the producer said the evidence was checked; it does not prove the check happened. This function does not independently verify the hardware report, expected measurement, policy execution, or transcript contents. Do not treat `affirming` or a non-software platform string as sufficient evidence to act.
 
 For cMCP's `RuntimeClaim`, use [cmcp-verify](https://cmcp.agentrust-io.com/tutorials/verifying-a-trace-claim/). That envelope is different from standalone TRACE. For the wider distinction, read [hardware evidence](hardware-attestation-platforms.md) and [trust levels](../trust-levels.md).
 
 ## Failure handling
 
-`InvalidSignature` rejects a signature mismatch. `ValueError` rejects other supported verification failures, such as malformed input, an unsupported profile, an untrusted/mismatched key, stale timestamps, or configured nonce/revocation failures. Do not return a successful verification result when either is raised.
+Any error means the record failed. `InvalidSignature` rejects a signature mismatch. `ValueError` rejects other supported verification failures, such as malformed input, an unsupported profile, an untrusted/mismatched key, stale timestamps, or configured nonce/revocation failures. Do not return a successful verification result when either is raised.
 
 The returned verification result still needs the recipient's acceptance policy. A signed statement is not proof of task completion, hardware isolation, or complete audit history.
diff --git a/docs/tutorials/verifying-the-audit-chain.md b/docs/tutorials/verifying-the-audit-chain.md
index eef19f6d..42d47604 100644
--- a/docs/tutorials/verifying-the-audit-chain.md
+++ b/docs/tutorials/verifying-the-audit-chain.md
@@ -1,12 +1,14 @@
 # Verify the Tool Call Transcript
 
-Check that a signed record commits to the transcript you received. This establishes integrity of the supplied transcript; it cannot show that the producer recorded every real call.
+This page is for anyone who has a TRACE record and the log of tool calls (the transcript) that came with it, and wants to know the log is the one the producer signed. The record holds a fingerprint (hash) of the transcript; you will recompute it and compare.
+
+A match shows the transcript you hold is the one the record vouches for. It cannot show that the producer logged every call the agent really made.
 
 ## Run a complete local example
 
 First save the complete [AGT adapter example](agt-adapter.md) as `adapter_example.py`. It creates synthetic audit entries and a signed software record. Append the following block to that same file, then run `python adapter_example.py`.
 
-This producer hashes RFC 8785 canonical JSON. Other producers can define different transcript encodings; use their documented byte format instead of assuming every TRACE transcript is a JSON array or a hash of an HTTP response.
+To recompute a fingerprint you need the exact bytes the producer hashed. This producer writes the log as JSON in one fixed standard layout (RFC 8785). Other producers may write their logs differently; use the format they document instead of assuming every TRACE transcript is a JSON list or a hash of an HTTP response.
 
 ```python
 import hmac
@@ -47,16 +49,16 @@ else:
     raise RuntimeError("Changed transcript was accepted")
 ```
 
-The final two lines should report a matching transcript and rejection of changed bytes. The verifier's key is retained independently by the demo; a recipient needs its own trusted issuer-key configuration.
+The final two lines should report a matching transcript and then a rejected copy with one extra byte. The demo keeps its own copy of the public key; a real recipient needs the producer's key from its own trusted settings.
 
 ## Verify a received transcript
 
-Use the saved-record key-loading sequence in [verify a trust record](verifying-a-trust-record.md). Obtain transcript bytes through your application's approved artifact channel. `transcript_uri` is optional, so a record does not always provide a download location. Apply your application's URL, response-size, and access controls before fetching a producer-supplied URI.
+For a record someone sent you, use the saved-record key-loading sequence in [verify a trust record](verifying-a-trust-record.md). Obtain transcript bytes through your application's approved artifact channel. `transcript_uri` is optional, so a record does not always provide a download location. Apply your application's URL, response-size, and access controls before fetching a producer-supplied URI.
 
-Verify the signature, compute the digest using the producing profile's encoding, and reject mismatches. If a count is supplied, compare it using that profile's definition of a call. Do not silently treat absent evidence or a count mismatch as successful transcript verification.
+Check the signature, recompute the fingerprint from the bytes in the producer's format, and reject any mismatch. If the record states a number of calls, compare it, counting calls the way that producer defines them. Do not silently treat absent evidence or a count mismatch as successful transcript verification.
 
 ## Interpret the result
 
-A matching digest binds these bytes to the trusted key's signed statement. A matching count shows consistency with the declared count. Neither establishes that the producer disclosed every call, that an action completed, or that its outputs are correct. Hashing sensitive input also does not guarantee confidentiality, particularly for predictable values.
+A matching fingerprint ties these exact bytes to what the trusted key signed. A matching count shows the log has as many calls as the record says. Neither establishes that the producer disclosed every call, that an action completed, or that its outputs are correct. Hashing sensitive input also does not guarantee confidentiality, particularly for predictable values.
 
-External action receipts require their own issuer trust, signature, action binding, and freshness checks. Use the [action-receipt verification guide](../verification.md#action-receipts-and-embodied-workflows) for those checks; a generic transcript hash does not perform them.
+Receipts that another system issues for an action (action receipts) need their own issuer trust, signature, action binding, and freshness checks. Use the [action-receipt verification guide](../verification.md#action-receipts-and-embodied-workflows) for those checks; a generic transcript hash does not perform them.
diff --git a/docs/verification-outcome-statements.md b/docs/verification-outcome-statements.md
index 488d3e48..28fb54c9 100644
--- a/docs/verification-outcome-statements.md
+++ b/docs/verification-outcome-statements.md
@@ -4,11 +4,13 @@ description: "How a relying party turns a TRACE verifier outcome into a bounded
 
 # Verification outcome statements
 
+When software checks a TRACE record, it reports a result. This page is for auditors, assessors, customers and anyone else who has to turn that result into a written conclusion: for each kind of result it gives the strongest sentence the evidence supports, the claim to leave out, and what to keep on file.
+
 > **Non-normative.** This page is informative. It changes no schema field, wire format, required claim or conformance requirement, and carries no uppercase RFC 2119 keyword. [Section 3.3 of the specification](../spec/trace-v0.2.md) and the [verification protocol](verification.md) carry the normative rules; where those documents already speak, this page repeats their wording rather than adding to it.
 
 ## Purpose
 
-A TRACE verifier produces an outcome: an `appraisal.status`, a recorded provenance depth, a set of checks it ran and did not run. The people who consume that outcome are often not verifiers. Auditors, assessors, customers and regulators read verifier output and have to turn it into a written conclusion. The failure mode this page exists to prevent is assurance overclaim - a conclusion written slightly stronger than the evidence behind it, so that a valid signature quietly becomes "the agent complied", or a signed acceptance receipt becomes "the action succeeded".
+A TRACE verifier (the software that checks a record) produces an outcome: an `appraisal.status`, a recorded provenance depth, a set of checks it ran and did not run. The people who use that outcome are often not the ones who ran the check. Auditors, assessors, customers and regulators read verifier output and have to turn it into a written conclusion. The mistake this page exists to prevent is overclaiming: writing a conclusion slightly stronger than the evidence behind it, so that a valid signature quietly becomes "the agent complied", or a signed acceptance receipt becomes "the action succeeded".
 
 Two pages already tell a reader what not to conclude, each cut a different way: [Trust Levels](trust-levels.md) carries a *What it does not prove* line under each level, and the [OWASP Agentic Top 10 crosswalk](crosswalks/owasp-agentic-top-10.md) carries a *Limitations / out of scope* column and a closing *What TRACE does not do* list. This page is the third view of the same discipline, indexed by verifier outcome rather than by trust level or risk category. Where wording overlaps, those two pages carry the meaning and this page follows them.
 
@@ -20,7 +22,7 @@ Machine-checkable verifier-output/statement pairs are out of scope for this page
 
 ## Interpretation matrix
 
-The rows are representative, not exhaustive. Each row reads: the outcome a verifier records, the strongest statement the evidence supports, the claim that has to stay out of the same sentence, the evidence worth retaining alongside the record, and a sensible follow-up.
+The rows are typical cases; the list is not complete. Each row reads: the outcome a verifier records, the strongest statement the evidence supports, the claim that has to stay out of the same sentence, the evidence worth retaining alongside the record, and a sensible follow-up.
 
 | Verification outcome | Supported bounded statement | Required non-claim | Evidence to retain | Follow-up |
 |---|---|---|---|---|
diff --git a/docs/verification.md b/docs/verification.md
index e7d1a3c6..fc87d773 100644
--- a/docs/verification.md
+++ b/docs/verification.md
@@ -1,5 +1,7 @@
 # Verification Protocol
 
+This page explains how to check a TRACE record you have received: that it really came from the issuer you trust, that nobody changed it, and what else you must check before relying on what it says. It is for engineers who build or run a verifier (the program that does these checks). You get the five basic steps first, then the extra checks for revoked keys, hardware evidence, build history, public logs and per-action receipts.
+
 A TRACE verifier authenticates a signed record and evaluates the evidence required by the recipient's policy. Offline verification needs the relevant artifacts and trust inputs already available. It cannot infer missing hardware, revocation, or transparency evidence from the record's assertions.
 
 ## Five-step verification
@@ -8,20 +10,22 @@ This is an implementation guide to [section 3.3 of the specification](../spec/tr
 
 ### Step 1: Parse the envelope
 
-Validate the complete standalone record against the canonical schema and supported EAT profile. A cMCP `RuntimeClaim` is a different envelope and requires its runtime-specific verifier.
+Check that the record has the expected shape before trusting anything in it. Validate the complete standalone record against the canonical schema and supported EAT profile. A cMCP `RuntimeClaim` is a different envelope and requires its runtime-specific verifier.
 
 ### Step 2: Resolve the public key
 
-Obtain an approved issuer key through the recipient's own trust configuration. The incoming `cnf.jwk` cannot establish its own authority. The trusted key and signed confirmation key must match under the signature profile.
+Decide which public key should have signed this record, using your own list of trusted issuers. Obtain an approved issuer key through the recipient's own trust configuration. The incoming `cnf.jwk` cannot establish its own authority. The trusted key and signed confirmation key must match under the signature profile.
 
 ### Step 3: Verify the signature
 
-Use `agentrust_trace.verify_record(record, public_key_or_jwk=trusted_key)`. It checks the standalone schema, supported profile, key binding, and Ed25519 signature, with configured freshness, nonce, and revocation inputs. It rejects missing trust input by default. The signature covers every field except `signature`, including `cnf` and any `transparency` value, using RFC 8785 canonicalization.
+Confirm the signature matches that key, which shows the record was not changed after signing. Use `agentrust_trace.verify_record(record, public_key_or_jwk=trusted_key)`. It checks the standalone schema, supported profile, key binding, and Ed25519 signature, with configured freshness, nonce, and revocation inputs. It rejects missing trust input by default. The signature covers every field except `signature`, including `cnf` and any `transparency` value, using RFC 8785 canonicalization.
 
 A signature proves a statement came from the trusted key. It does not establish the truth of every claim in that statement.
 
 ### Step 4: Check the EAT profile
 
+The `eat_profile` value names which version of the TRACE format the record follows (EAT, the Entity Attestation Token of RFC 9711, is the IETF format TRACE builds on). Accept only versions your verifier actually understands.
+
 [Section 3.3](../spec/trace-v0.2.md#33-verification) requires a nonempty `accepted_profiles` set containing only profiles whose schemas and verification semantics the verifier implements. Reject an unsupported member anywhere in that declaration, even if the record names a supported profile. Also reject a record whose `eat_profile` is outside the declared set.
 
 A successful verification result records both the verified `profile` and the complete `accepted_profiles` set configured at verification time. Retaining only the record's profile loses which other profiles the verifier claimed to support. These fields belong to the verifier's result; they do not alter the signed record.
@@ -30,7 +34,7 @@ The current SDK accepts only `tag:agentrust-io.com,2026:trace-v0.2` and rejects
 
 ### Step 5: Appraise the claims
 
-Resolve and verify the evidence your policy requires: hardware reports, expected measurements, policy and transcript artifacts, build provenance, revocation state, and transparency proofs. The record's `appraisal.status` is itself a signed claim, not an independent appraisal performed by `verify_record`.
+To appraise is to check each claim against outside evidence, instead of taking the record's word for it. Resolve and verify the evidence your policy requires: hardware reports, expected measurements, policy and transcript artifacts, build provenance, revocation state, and transparency proofs. The record's `appraisal.status` is itself a signed claim, not an independent appraisal performed by `verify_record`.
 
 | Claimed status | Interpretation |
 |---|---|
@@ -43,12 +47,17 @@ The recipient decides whether the checks performed satisfy the operation's requi
 
 ### Resolving cited objects
 
-A record cites objects it does not carry: `appraisal.policy_ref`, `runtime.rim_uri` and `model.aibom_uri` are URIs, and the schema checks only that each parses as one. Whether the object behind a URI can still be obtained is a fact about the world at verification time, so `verify_record` records it rather than assuming it. Pass `citation_resolver`, a function from URI to bytes that you supply, and the result's `citations` field reports one row per surface: `resolved`, with the SHA-256 over exactly the bytes the resolver returned and their count; `unresolvable`, with the cause and the exception's class name when the resolver raised or the returned value's type name when it returned something other than bytes; or `not_attempted`, when no resolver was supplied, the record does not carry the field, or the surface is deferred. The resolver is called only after the signature verifies and after every check that can raise, so a record that fails verification drives no resolution. `transparency` is deferred: its resolution is coordinated in [agentrust-io/trace-tests#92](https://github.com/agentrust-io/trace-tests/issues/92) and stays with the open question in section 7 of the specification.
+Some fields in a record are links to documents kept elsewhere, such as the policy, the expected hardware values and the model's bill of materials. `verify_record` can try to fetch each one with a function you supply and report whether it got the bytes, but it never treats a fetched document as proof that the document was in force.
+
+??? info "Technical detail: the `citation_resolver` contract"
+    A record cites objects it does not carry: `appraisal.policy_ref`, `runtime.rim_uri` and `model.aibom_uri` are URIs, and the schema checks only that each parses as one. Whether the object behind a URI can still be obtained is a fact about the world at verification time, so `verify_record` records it rather than assuming it. Pass `citation_resolver`, a function from URI to bytes that you supply, and the result's `citations` field reports one row per surface: `resolved`, with the SHA-256 over exactly the bytes the resolver returned and their count; `unresolvable`, with the cause and the exception's class name when the resolver raised or the returned value's type name when it returned something other than bytes; or `not_attempted`, when no resolver was supplied, the record does not carry the field, or the surface is deferred. The resolver is called only after the signature verifies and after every check that can raise, so a record that fails verification drives no resolution. `transparency` is deferred: its resolution is coordinated in [agentrust-io/trace-tests#92](https://github.com/agentrust-io/trace-tests/issues/92) and stays with the open question in section 7 of the specification.
 
-Three things this does not do. It does not read `references[]`: [§3.1.2](../spec/trace-v0.2.md) rule 3 says a verifier MUST NOT reject a record because an entry in `references` cannot be resolved, and MUST NOT treat a resolved reference as attested evidence; the block is a pointer this check does not follow. It does not take the resolver from the record: a record that names its own checker can name one that agrees with it, so the resolver is yours or there is none. And it does not appraise: `resolved` says bytes were produced and hashed, not that the object was in force or that it binds the record, and no row changes the revocation outcome, the thumbprint, or whether verification raises. Which `appraisal.status` an unresolvable citation carries is the question [#190](https://github.com/agentrust-io/trace-spec/issues/190) holds open, alongside the revocation outcomes in the section below. [`examples/citation-resolution/`](https://github.com/agentrust-io/trace-spec/tree/main/examples/citation-resolution/) carries the conformance vectors, with the cited bytes in hand so every vector is offline.
+    Three things this does not do. It does not read `references[]`: [§3.1.2](../spec/trace-v0.2.md) rule 3 says a verifier MUST NOT reject a record because an entry in `references` cannot be resolved, and MUST NOT treat a resolved reference as attested evidence; the block is a pointer this check does not follow. It does not take the resolver from the record: a record that names its own checker can name one that agrees with it, so the resolver is yours or there is none. And it does not appraise: `resolved` says bytes were produced and hashed, not that the object was in force or that it binds the record, and no row changes the revocation outcome, the thumbprint, or whether verification raises. Which `appraisal.status` an unresolvable citation carries is the question [#190](https://github.com/agentrust-io/trace-spec/issues/190) holds open, alongside the revocation outcomes in the section below. [`examples/citation-resolution/`](https://github.com/agentrust-io/trace-spec/tree/main/examples/citation-resolution/) carries the conformance vectors, with the cited bytes in hand so every vector is offline.
 
 ## Checking revocation status
 
+A key is revoked when its owner declares it can no longer be trusted, for example because it was stolen. A signature check cannot see that by itself, so a verifier also needs a revocation list, a live lookup, or a signed bundle of revocation statements it downloaded earlier.
+
 Signature verification alone cannot discover a later key revocation. Offline appraisal requires cached revocation evidence as well as the record and trusted key. Report which evidence was checked and whether it remains current.
 
 [§3.2.3 of the spec](../spec/trace-v0.2.md) closes that gap without giving up offline verification. Two things are worth knowing before reading the code below.
@@ -87,31 +96,38 @@ Both failure modes raise `ValueError`, including a store that cannot answer:
 
 The last row is the honest default. Omitting the store is a legitimate mode, since air-gapped audit of archived records has no other option, but the result means "this record was validly signed by this key", not "this key is still trusted", and the result says so rather than leaving it implied.
 
-`verify_record()` also consumes the bundle format §3.2.3 publishes. Pass `revocation_bundle`, a `TraceRevocationBundle/1.0` object, and `trusted_bundle_keys`, the JWKs whose signatures the caller accepts on a bundle:
+`verify_record()` can also read a signed revocation bundle, a file of revocation statements you download ahead of time so you can check revocation while offline.
 
-```python
-result = verify_record(
-    record, trusted_jwk,
-    revocation_bundle=bundle, trusted_bundle_keys=[bundle_signer_jwk],
-    max_bundle_age_seconds=86400, now=verification_time,
-)
-result.revocation.outcome    # "verified" | "unverified_for_revocation" | "no_check_performed"
-result.revocation.cause      # why a supplied bundle could not ground "verified", or None
-result.revocation.evidence   # what a second verifier needs to reach the same outcome
-```
+??? info "Technical detail: revocation bundles"
+    `verify_record()` also consumes the bundle format §3.2.3 publishes. Pass `revocation_bundle`, a `TraceRevocationBundle/1.0` object, and `trusted_bundle_keys`, the JWKs whose signatures the caller accepts on a bundle:
 
-The three outcomes are §3.2.3's own words, and none of them is an appraisal: where a verifier records an unresolvable check in the record itself is the question [#190](https://github.com/agentrust-io/trace-spec/issues/190) holds open. A bundle is evidence only while both age bounds hold, the issuer's `valid_until` and the caller's `max_bundle_age_seconds` measured from `issued_at`; the tighter bound governs, and an expired outcome names which one tripped. `now` pins the verification moment so the outcome reproduces from retained facts. A bundle that is malformed, signed by a key not in `trusted_bundle_keys`, signed with an algorithm this build cannot verify, dated in the future, or expired under either bound yields `unverified_for_revocation` with the cause named; it does not raise, because inability to check is not evidence of a defect. A statement on the bundle's log naming the trusted key raises, under the fallback above, and it is read before the time checks: the bounds say what the bundle's silence is worth, and an authenticated statement has no expiry of its own. [`examples/revocation-bundle/`](https://github.com/agentrust-io/trace-spec/tree/main/examples/revocation-bundle/) carries the conformance vectors.
+    ```python
+    result = verify_record(
+        record, trusted_jwk,
+        revocation_bundle=bundle, trusted_bundle_keys=[bundle_signer_jwk],
+        max_bundle_age_seconds=86400, now=verification_time,
+    )
+    result.revocation.outcome    # "verified" | "unverified_for_revocation" | "no_check_performed"
+    result.revocation.cause      # why a supplied bundle could not ground "verified", or None
+    result.revocation.evidence   # what a second verifier needs to reach the same outcome
+    ```
+
+    The three outcomes are §3.2.3's own words, and none of them is an appraisal: where a verifier records an unresolvable check in the record itself is the question [#190](https://github.com/agentrust-io/trace-spec/issues/190) holds open. A bundle is evidence only while both age bounds hold, the issuer's `valid_until` and the caller's `max_bundle_age_seconds` measured from `issued_at`; the tighter bound governs, and an expired outcome names which one tripped. `now` pins the verification moment so the outcome reproduces from retained facts. A bundle that is malformed, signed by a key not in `trusted_bundle_keys`, signed with an algorithm this build cannot verify, dated in the future, or expired under either bound yields `unverified_for_revocation` with the cause named; it does not raise, because inability to check is not evidence of a defect. A statement on the bundle's log naming the trusted key raises, under the fallback above, and it is read before the time checks: the bounds say what the bundle's silence is worth, and an authenticated statement has no expiry of its own. [`examples/revocation-bundle/`](https://github.com/agentrust-io/trace-spec/tree/main/examples/revocation-bundle/) carries the conformance vectors.
 
 What neither path does yet is entry-ID-scoped revocation. Both answer "is this key revoked", which is the §3.2.3 fallback, so a key revoked after a long run of legitimate records currently invalidates all of them rather than the ones logged after `last_valid_entry_id`. Carrying the entry ID through `verify_record()` is implementation work tracked in the issue that produced §3.2.3. The bundle path also verifies the bundle signature only, not each statement's own signature against the §3.2.1 hierarchy; that check needs the hierarchy, and it is stated here rather than implied.
 
 ## Verifying hardware-rooted records
 
+A hardware-rooted record carries a signed report from the processor it ran on. Checking it means confirming the report is genuine, recent, describes the software you expected, and is tied to the key that signed the record.
+
 Hardware appraisal supports Level 1; Level 2 adds transparency anchoring. Verify the report or quote signature and accepted trust chain, its freshness and platform policy, the independently approved measurement, and its binding to the record-signing key. The producing profile defines that binding.
 
 `verify_record` does not perform these hardware checks. Comparing a record's digest to an unauthenticated reference or reading `affirming` is not a substitute. See [attestation platforms](platforms/index.md) and the producing runtime's verifier.
 
 ## Verifying build provenance depth
 
+Build provenance is the record of how a piece of software was built and from what inputs. Depth says how far back the check went: `surface` checks only the finished file, `builder` also checks the build service's signed statement, and `transitive` also checks every input that went into the build. A verifier writes down the depth it really reached; when evidence is missing it may stop at a lower depth, but when evidence shows the record is wrong, the check fails.
+
 The normative rules are defined by [§3.3.1 of the specification](../spec/trace-v0.2.md).
 `build_provenance.provenance_depth` declares how far down the supply chain the issuer claims to
 have walked. A verifier records what it actually checked in
@@ -173,43 +189,46 @@ requires, together with the Cyber Resilience Act, which is the instrument most o
 for in its place. Verification at any depth is not evidence of compliance with either of
 them, and neither is a floor that is met.
 
-**Regulation (EU) 2024/1689.** Annex IV is the technical documentation schedule whose
-elements Article 11(1) requires the technical documentation to contain at a minimum. It is
-not a classification annex, since high-risk classification runs through Article 6 with
-Annexes I and III, and neither Article 11 nor Annex IV imposes a verification obligation of
-the kind `provenance_depth_verified` records. Article 12 does not impose one either, since it
-requires that a high-risk system technically allow the automatic recording of events over its
-lifetime, which is a capability requirement about logging rather than a statement about
-provenance or build inputs. Two adjacent provisions are sometimes read as supplying one, and
-neither does. Article 25(4), as amended by Regulation (EU) 2026/1744,
-requires the provider of a high-risk AI system and a third party supplying an AI system, AI
-model, tools, services, components or processes used or integrated in it to specify by
-written agreement the information, capabilities, technical access and other assistance the
-provider needs, and it does not apply to third parties making tools, services, processes or
-components other than general-purpose AI models publicly available under a free and
-open-source licence. Article 15(5) requires technical solutions addressing, where
-appropriate, data poisoning, model poisoning, adversarial examples, confidentiality attacks
-and model flaws, which is stated as an outcome rather than as a depth of supply-chain
-verification. Articles 11, 12, 15 and 25 sit in Sections 2 and 3 of Chapter III, whose
-application Regulation (EU) 2026/1744 moved to 2 December 2027 for systems high-risk under
-Article 6(2) and Annex III, and to 2 August 2028 for systems high-risk under Article 6(1)
-and Annex I. Article 111(2), as replaced by the same Regulation, applies the AI Act to
-operators of high-risk systems, other than the systems referred to in Article 111(1), that
-have been placed on the market or put into service before that date of application, only if,
-as from that date, those systems are subject to significant changes in their designs, and in
-any case requires providers and deployers of high-risk systems intended to be used by public
-authorities to take the necessary steps to comply by 2 August 2030. The reading that one unit
-lawfully placed on the market or put into service carries the other units of the same type
-and model is recital 39 of Regulation (EU) 2026/1744 rather than operative text.
-
-**Regulation (EU) 2024/2847.** Annex I Part II point 1 requires manufacturers to identify
-and document vulnerabilities and components, including by drawing up a software bill of
-materials in a commonly used and machine-readable format covering at the very least the
-top-level dependencies of the product. That is a component inventory obligation, so it does
-not by itself establish `builder` or `transitive` verification, both of which are claims
-about provenance rather than about composition. Its Annex I obligations apply from
-11 December 2027, with the reporting obligations in Article 14 applying from
-11 September 2026.
+In short, neither the EU AI Act nor the Cyber Resilience Act requires a verification depth, and meeting a floor here is not evidence of compliance with either.
+
+??? info "Technical detail: what the two Regulations say, article by article"
+    **Regulation (EU) 2024/1689.** Annex IV is the technical documentation schedule whose
+    elements Article 11(1) requires the technical documentation to contain at a minimum. It is
+    not a classification annex, since high-risk classification runs through Article 6 with
+    Annexes I and III, and neither Article 11 nor Annex IV imposes a verification obligation of
+    the kind `provenance_depth_verified` records. Article 12 does not impose one either, since it
+    requires that a high-risk system technically allow the automatic recording of events over its
+    lifetime, which is a capability requirement about logging rather than a statement about
+    provenance or build inputs. Two adjacent provisions are sometimes read as supplying one, and
+    neither does. Article 25(4), as amended by Regulation (EU) 2026/1744,
+    requires the provider of a high-risk AI system and a third party supplying an AI system, AI
+    model, tools, services, components or processes used or integrated in it to specify by
+    written agreement the information, capabilities, technical access and other assistance the
+    provider needs, and it does not apply to third parties making tools, services, processes or
+    components other than general-purpose AI models publicly available under a free and
+    open-source licence. Article 15(5) requires technical solutions addressing, where
+    appropriate, data poisoning, model poisoning, adversarial examples, confidentiality attacks
+    and model flaws, which is stated as an outcome rather than as a depth of supply-chain
+    verification. Articles 11, 12, 15 and 25 sit in Sections 2 and 3 of Chapter III, whose
+    application Regulation (EU) 2026/1744 moved to 2 December 2027 for systems high-risk under
+    Article 6(2) and Annex III, and to 2 August 2028 for systems high-risk under Article 6(1)
+    and Annex I. Article 111(2), as replaced by the same Regulation, applies the AI Act to
+    operators of high-risk systems, other than the systems referred to in Article 111(1), that
+    have been placed on the market or put into service before that date of application, only if,
+    as from that date, those systems are subject to significant changes in their designs, and in
+    any case requires providers and deployers of high-risk systems intended to be used by public
+    authorities to take the necessary steps to comply by 2 August 2030. The reading that one unit
+    lawfully placed on the market or put into service carries the other units of the same type
+    and model is recital 39 of Regulation (EU) 2026/1744 rather than operative text.
+
+    **Regulation (EU) 2024/2847.** Annex I Part II point 1 requires manufacturers to identify
+    and document vulnerabilities and components, including by drawing up a software bill of
+    materials in a commonly used and machine-readable format covering at the very least the
+    top-level dependencies of the product. That is a component inventory obligation, so it does
+    not by itself establish `builder` or `transitive` verification, both of which are claims
+    about provenance rather than about composition. Its Annex I obligations apply from
+    11 December 2027, with the reporting obligations in Article 14 applying from
+    11 September 2026.
 
 ### Why depth is recorded rather than assumed
 
@@ -245,12 +264,16 @@ The reference SDK exposes a Python API; it does not install an `agentrust-trace`
 
 ## SCITT-anchored records
 
+SCITT is an IETF design for append-only transparency logs. A record anchored there has been added to a public list that cannot be quietly edited, and the log returns a receipt proving it.
+
 A `transparency` URI names a claimed log entry. It does not establish inclusion by itself. Retrieve the receipt, verify its binding to the record, and verify the inclusion proof against an independently trusted log or checkpoint. See [anchoring to the registry](tutorials/anchoring-to-the-registry.md) for the reference format and sequence.
 
 An authenticated inclusion proof establishes inclusion under that checkpoint. It does not establish the truth of the record's claims, complete logging, or future log availability.
 
 ## Action receipts and embodied workflows
 
+An action receipt is a small signed note about one action, such as a robot controller accepting or refusing a command. "Embodied" means an agent that acts in the physical world.
+
 Some deployments attach per-action receipts below the session layer. For
 example, an embodied-agent controller can sign a receipt that says a specific
 call was accepted, rejected, aborted, or handed off to another authority. These
diff --git a/docs/verifier-token-experimental.md b/docs/verifier-token-experimental.md
index aaa8f31b..d9af4f8a 100644
--- a/docs/verifier-token-experimental.md
+++ b/docs/verifier-token-experimental.md
@@ -1,5 +1,7 @@
 # Verifier-issued, holder-bound TRACE: experimental reference
 
+This page describes trial code for a proposed kind of TRACE result: a short-lived token that a verifier (the service that checks the evidence) issues about an agent, which only the holder of a named key can present (holder-bound). It is for implementers who want to test the idea or build a second, independent version; nothing here changes how today's v0.2 records work.
+
 This prototype implements the proposals in `docs/rfcs/verifier-issued-trace-profile.md`
 and `docs/rfcs/composite-component-appraisal.md`.
 It is a proposal, not an adopted TRACE profile. Existing v0.2 records, signatures,
diff --git a/index.md b/index.md
index ab5e6b7a..f7fbb9e5 100644
--- a/index.md
+++ b/index.md
@@ -10,13 +10,13 @@ hide:
 
 # Evidence a third party can check, years later
 
-TRACE specifies the record, anchoring protocol and verification rules that tie an agent run to its workload, policy, data class and tool transcript, so anyone holding the record can verify it offline.
+TRACE is a free, open format for a signed receipt of what an AI agent did: which program ran, under which rules, on what kind of data, and which tools it called. Anyone holding the receipt can check it on their own computer, with no access to the system that produced it. This site is for engineers who produce or check these receipts, and for anyone deciding how much a receipt can be trusted ([the terms, in plain English](https://agentrust-io.com/#plain-terms)).
 
 [Create and verify your first record](docs/quickstart.md){ .md-button .md-button--primary }
 [What this proves, and what it does not](LIMITATIONS.md){ .md-button }
 
 !!! tip "TL;DR"
-    Spec v0.2 and the [agentrust-trace](https://pypi.org/project/agentrust-trace/) 0.11.0 reference library sign and verify records in software with no cloud account, and a v0.2 signature proves who produced a record and that it has not changed while every hardware field in it is still the producer's claim. The proposed [runtime evidence profile](docs/rfcs/runtime-evidence-profile.md) grades inlined quotes as platform-attested or attested, and the attested grade is specified but not yet demonstrated.
+    With spec v0.2 and the [agentrust-trace](https://pypi.org/project/agentrust-trace/) 0.11.0 Python library you can sign and check records on a laptop, with no cloud account. A v0.2 signature proves who made a record and that nobody changed it afterwards; what the record says about the hardware is still only the producer's word until the proposed [runtime evidence profile](docs/rfcs/runtime-evidence-profile.md) adds checkable hardware reports, and its top "attested" grade is specified but not yet demonstrated.
 
 <div class="grid cards" markdown>
 
@@ -24,7 +24,7 @@ TRACE specifies the record, anchoring protocol and verification rules that tie a
 
     ---
 
-    Sign a record, verify it with a separately retained key, and see what a failed check looks like.
+    Sign a record, check it with a key kept somewhere else, and see what a failed check looks like.
 
     [Quickstart](docs/quickstart.md)
 
@@ -32,7 +32,7 @@ TRACE specifies the record, anchoring protocol and verification rules that tie a
 
     ---
 
-    A signed field is a producer's claim. The verification protocol sets out what a verifier still has to check.
+    A signature tells you who said something, not that it is true. The verification page lists what a checker still has to confirm on its own.
 
     [Verification protocol](docs/verification.md)
 
@@ -40,7 +40,7 @@ TRACE specifies the record, anchoring protocol and verification rules that tie a
 
     ---
 
-    TRACE carries evidence to verifiers that already exist; the runtime evidence profile uses agent-manifest's TDX verifier. Check a real TDX quote at [agentrust-io.com/verify](https://agentrust-io.com/verify/).
+    Some processors can produce a signed report of what is running on them (attestation). TRACE carries those reports to existing checkers; the runtime evidence profile uses agent-manifest's checker for Intel TDX reports. Check a real TDX report at [agentrust-io.com/verify](https://agentrust-io.com/verify/).
 
     [Runtime evidence profile](docs/rfcs/runtime-evidence-profile.md)
 
@@ -48,7 +48,7 @@ TRACE specifies the record, anchoring protocol and verification rules that tie a
 
     ---
 
-    TRACE is the evidence step. Anchor records in the [TRACE Registry](https://agentrust-io.com/registry/) and score them with the [conformance suite](https://tests.agentrust-io.com).
+    TRACE is the evidence step, the last of four. Publish records to the public [TRACE Registry](https://agentrust-io.com/registry/) and test an implementation with the [conformance suite](https://tests.agentrust-io.com).
 
     [See the chain](https://agentrust-io.com/#chain)
 
@@ -56,6 +56,8 @@ TRACE specifies the record, anchoring protocol and verification rules that tie a
 
 ## What the record contains
 
+Each row is a question a reader might ask about an agent run, the part of the record that answers it, and what a checker needs beyond the signature before believing the answer.
+
 | Question | Fields to inspect | What the verifier still needs |
 |---|---|---|
 | Which workload is named? | `subject`, `model` | An authenticated issuer and evidence binding the workload |
@@ -65,21 +67,21 @@ TRACE specifies the record, anchoring protocol and verification rules that tie a
 | What transcript is committed? | `tool_transcript` | Transcript evidence when individual calls matter |
 | Was evidence anchored? | `transparency` | A verified receipt and the required log trust policy |
 
-A signed field is a producer's claim. Signature verification alone does not establish that the described execution occurred or that a policy was enforced. See the [verification protocol](docs/verification.md) for the full evaluation path.
+Every field is the producer's claim. A valid signature alone does not show that the run happened as described or that the rules were actually applied. The [verification protocol](docs/verification.md) walks through the full set of checks.
 
 ## Where to go next
 
-- [TRACE v0.2](spec/trace-v0.2.md): the normative specification, with the claim set, the anchoring protocol, and the verification rules.
-- [Conformance suite](https://tests.agentrust-io.com): score an implementation by conformance level before claiming compliance.
-- [Integration guides](docs/integration/agt.md): emit and consume Trust Records from AGT, cMCP, and sandboxed agent runtimes.
+- [TRACE v0.2](spec/trace-v0.2.md): the specification itself, with the fields, the publishing protocol and the checking rules.
+- [Conformance suite](https://tests.agentrust-io.com): test an implementation, level by level, before saying it complies.
+- [Integration guides](docs/integration/agt.md): produce and read Trust Records from AGT, cMCP and sandboxed agent runtimes.
 
 ## What it is built on
 
-TRACE profiles existing IETF and IRTF work rather than replacing it: [RFC 9711 (EAT)](https://www.rfc-editor.org/rfc/rfc9711) for the claim envelope, [RFC 9334 (RATS)](https://www.rfc-editor.org/rfc/rfc9334) for the attester, verifier, and relying-party roles, and the SCITT draft for transparency-ledger anchoring.
+TRACE reuses published internet standards instead of inventing new ones: [RFC 9711 (EAT)](https://www.rfc-editor.org/rfc/rfc9711) for the claim envelope, [RFC 9334 (RATS)](https://www.rfc-editor.org/rfc/rfc9334) for the attester, verifier, and relying-party roles, and the SCITT draft for transparency-ledger anchoring.
 
 ## Status and governance
 
-The specification is a **Developer Preview**. v0.2 is current and published with a conformance test suite. Read [Limitations](LIMITATIONS.md) for the scope boundaries before relying on it in production.
+The specification is a **Developer Preview**: usable now, and still expected to change. v0.2 is current and ships with a conformance test suite. Read [Limitations](LIMITATIONS.md) for what it does not cover before relying on it in production.
 
 TRACE Specification is an [LF Project](https://www.linuxfoundation.org/), hosted at the Linux Foundation as its own series, "TRACE Specification, a Series of LF Projects, LLC", under [LF Projects policies](https://lfprojects.org/policies/). It has also been proposed to the Agentic AI Foundation at the Sandbox stage ([aaif/project-proposals #42](https://github.com/aaif/project-proposals/issues/42), opened 14 September 2026). See [Governance](GOVERNANCE.md) for how decisions are made and [Contributing](CONTRIBUTING.md) for how to propose a change.
 
diff --git a/spec/content-marking-v1.md b/spec/content-marking-v1.md
index 14f1ff49..6de34228 100644
--- a/spec/content-marking-v1.md
+++ b/spec/content-marking-v1.md
@@ -8,6 +8,8 @@
 | Relevant obligation | EU AI Act Article 50(2) and 50(4), in force since 2 August 2026 |
 | License | CC BY 4.0 |
 
+**In plain terms.** When an AI system produces an image, video or text, EU law (AI Act Article 50) asks that the output carry a machine-readable label saying it is AI generated. This draft ties that label (a C2PA mark) to the TRACE record of the run that produced the content, so the label can be checked. It is for teams that generate content and must mark it.
+
 Defines one C2PA assertion, `com.agentrust-io.trace`, that ties a marked asset to the
 Trust Record of the execution that produced it.
 
diff --git a/spec/mcp-profile-v0.3-draft.md b/spec/mcp-profile-v0.3-draft.md
index 462072d9..ccef482c 100644
--- a/spec/mcp-profile-v0.3-draft.md
+++ b/spec/mcp-profile-v0.3-draft.md
@@ -5,6 +5,8 @@ This document does not change TRACE v0.2 verifier acceptance. Field names below
 describe logical requirements; serialization and a profile identifier remain
 subject to normative review before implementations claim conformance.
 
+**In plain terms.** This is a proposal for how a TRACE record should describe each tool call an agent makes through MCP (the common protocol agents use to call tools), including which tool list the agent was offered. It is for implementers and reviewers of the next TRACE version. Nothing here is adopted yet, and it does not change what a v0.2 verifier accepts.
+
 <!-- CHANGED: #324 - stateless MCP correlation and declaration binding proposal -->
 
 ## 1. Scope
diff --git a/spec/registry-anchor-v1.md b/spec/registry-anchor-v1.md
index 3713143c..d030ef89 100644
--- a/spec/registry-anchor-v1.md
+++ b/spec/registry-anchor-v1.md
@@ -7,6 +7,8 @@
 | Applies to | The `transparency` claim (TRACE v0.2 §3.1) and Level 2 conformance |
 | License | CC BY 4.0 |
 
+**In plain terms.** Anchoring means publishing a fingerprint of a record in an append-only log, so anyone can later prove the record existed and was not quietly swapped. This document is for people building or checking that log; it is a normative companion to TRACE v0.2 and the basis for Level 2 conformance.
+
 This document specifies how TRACE Trust Records are anchored into an append-only registry, and how a third party verifies, **without trusting the registry operator**, that a given record was included in an anchor.
 
 It is published here rather than only in the registry implementation for a reason that matters more than tidiness: an inclusion proof nobody outside can check is not transparency. A conforming verifier can be written from this document alone. The reference tooling named in §7 is one implementation, not the definition.
diff --git a/spec/server-provenance-v1.md b/spec/server-provenance-v1.md
index f04618be..5c7fade0 100644
--- a/spec/server-provenance-v1.md
+++ b/spec/server-provenance-v1.md
@@ -7,6 +7,8 @@
 | Anchoring | [Registry Anchor Format v1](registry-anchor-v1.md) |
 | License | CC BY 4.0 |
 
+**In plain terms.** MCP servers are the tool providers an AI agent calls. This format lets someone sign a statement about one server (what it is and which tools it offers) so others can check who said it. It is for people who publish or vet MCP servers, and it is a draft.
+
 A signed statement **about** an MCP server: what it is, what tools it exposes, who is
 saying so, and how much that is worth.
 
diff --git a/spec/server-provenance-v2.md b/spec/server-provenance-v2.md
index 8c1a4c01..43f0f5bc 100644
--- a/spec/server-provenance-v2.md
+++ b/spec/server-provenance-v2.md
@@ -6,6 +6,8 @@
 | Status | Draft proposal, companion to TRACE v0.2 |
 | License | CC BY 4.0 |
 
+**In plain terms.** Version 2 of the MCP server provenance format adds four of a tool's self-declared behaviours (for example, whether it only reads data) to what gets signed, so a later change to them is detectable. It is for people who publish or check MCP server provenance records, and it is a draft proposal.
+
 <!-- CHANGED: #406 - versioned binding of behavioral tool annotations -->
 
 ## 1. Scope and inherited requirements
diff --git a/spec/trace-v0.2.md b/spec/trace-v0.2.md
index 25682c91..3f7d57ca 100644
--- a/spec/trace-v0.2.md
+++ b/spec/trace-v0.2.md
@@ -11,6 +11,8 @@
 
 > **Note:** This is a pre-ratification draft. Fields, wire formats, and conformance requirements are subject to change before v1.0. Send feedback to: open an issue on this repository.
 
+**In plain terms.** This is the rulebook for TRACE: it defines the Trust Record (a signed receipt describing one AI agent run), how records are anchored in a public log, and the exact checks a verifier runs. You need it if you are writing software that produces or checks records; to try TRACE first, start with the [quickstart](../docs/quickstart.md). It is a draft (v0.2, Developer Preview), so details can still change before v1.0.
+
 ## Authority and conformance claims
 
 <!-- CHANGED: #247 - define specification precedence and identify conformance artifacts -->