docs: align reference pages and experiments with the runtime

CHARTER.md

@@ -44,7 +44,7 @@ Upon host organization acceptance, governance transitions from the current Proje
 
 ## 4. Intellectual Property Policy
 
-All contributions must be made under the terms of [LICENSE](LICENSE). Contributors must sign commits with the Developer Certificate of Origin (DCO). No contribution may incorporate material covered by a patent the contributor is unwilling to license royalty-free to conforming implementations.
+All contributions must be made under the terms of [LICENSE](https://github.com/agentrust-io/ca2a/blob/main/LICENSE). Contributors must sign commits with the Developer Certificate of Origin (DCO). No contribution may incorporate material covered by a patent the contributor is unwilling to license royalty-free to conforming implementations.
 
 ## 5. Trademark Policy
 

LIMITATIONS.md

@@ -4,7 +4,7 @@ cA2A 0.2 is a Developer Preview with a runnable, tested profile and runtime. Thi
 
 ## What is built
 
-- The delegation credential model and the offline chain verifier skeleton: signature checks, scope attenuation (a child grant must be a provable subset of its parent), depth limits, and cross-chain replay rejection. The hardest of these semantics is reused from [agent-manifest](https://github.com/agentrust-io/agent-manifest), where it is implemented and tested.
+- The delegation credential model and offline chain verifier: trusted-root checks, signatures, scope attenuation, depth and validity bounds, duplicate credential IDs within a chain, and cross-chain splice rejection. These checks do not maintain a global history of used credentials.
 - Configuration, error registry, and the CLI surface, including `ca2a start`, which builds a `PeerNode` from a config file and serves it over the reference transport.
 - A reference HTTP transport and the attestation handshake, in software mode. `ca2a_runtime.transport.server` and `ca2a_runtime.transport.client` (standard library only) run a live inbound A2A-profile call end to end: the caller fetches the callee's attested channel key, seals a payload to it, and sends a delegated task; the callee parses the A2A metadata with the adapter, runs verify + policy + enforce + open-sealed + provenance, and replies. `ca2a_runtime.attestation` gates the seal on a verified channel key. This is a **reference** transport, not part of the profile: the profile mandates no wire protocol (see Out of scope), and in software mode the peer key is accepted at `assurance="none"`.
 
@@ -18,7 +18,7 @@ cA2A 0.2 is a Developer Preview with a runnable, tested profile and runtime. Thi
   What **failed**, and it is the important half: `verify_tpm_report` could not chain to a pinned root, reporting "AK chain root is not among the supplied trusted TPM roots". On that host the AK certificate at NV `0x01C101D0` is 994 bytes, is issued by `CN=Global Virtual TPM CA - 03`, and carries **no AIA extension at all**, so there are no intermediates to fetch and none stored elsewhere in NV. A different Azure host (`Standard_D2s_v5`, eastus, 2026-07-31) presented a 1596-byte certificate under `Azure Cloud Virtual TPM CA - 11` with a walkable AIA chain reaching the root pinned in `ca2a_verify/tpm_roots.py`. Both observations are real: Azure runs more than one vTPM CA generation, so **the shipped Azure root is not sufficient fleet-wide** and a deployment must pin the hierarchy its own hosts actually present. Until then, treat the TPM tier as: evidence is genuine and its signature and binding are verifiable, but key provenance is host-dependent.
 - **TPM evidence proves key provenance only where a chain reaches a pinnable root.** A quote signed by the transient fallback key is a verifiable signature but carries no certificate chain, so it proves nothing about *where* the key lives, and `verify_tpm_report` rejects it. As above, a platform-provisioned certified attestation key is necessary but not sufficient: the chain must also be assemblable, which fails when the AK certificate carries no AIA. A GCP Shielded VM is weaker still (probed 2026-07-31: no EK certificate, no persistent handles, and `get-shielded-identity` returns a bare `ekPub` with no certificate). Client firmware TPM vendor roots are not yet published in a pinnable form. Separately, the TCG event log is 0 bytes on both Azure and GCP, so PCR values cannot be attributed to specific boot events on either cloud.
 
-## Platform state is not appraised
+## Platform-state appraisal is opt-in {#platform-state-is-not-appraised}
 
 <!-- The marked block below is shared verbatim with trace-spec and cmcp.
      trace-spec/LIMITATIONS.md is the source and the limitations-parity

ROADMAP.md

@@ -45,5 +45,5 @@ Real hardware attestation verification (SEV-SNP VCEK chain, Intel TDX quote via
 - Conformance suite for "cA2A-compatible" claims: **landed** (`tests/conformance/`, normative README + runnable MUST-level checks, in CI). A production run on confidential-computing hardware is the remaining step for a hardware-attested claim.
 - **Upstream A2A interoperability: not started.** Our own conformance suite says a peer implements cA2A. It says nothing about whether attaching the profile keeps us compatible with the wider A2A ecosystem, and that is a separate question worth answering with numbers. Plan: run the official [`a2aproject/a2a-tck`](https://github.com/a2aproject/a2a-tck) conformance suite first, then the A2A Interoperability Test Kit's multi-language launcher, which covers cross-SDK compatibility across Python, Go, TypeScript, Java and Rust. Publish the result as `docs/interop-report.md`, failures reported at the same volume as passes.
   - The system under test is an official `a2a-sdk` server with the extension attached through `ca2a_runtime.transport.a2a_sdk`, **not** `ca2a start`. A normative A2A transport is explicitly out of scope for this profile (see [LIMITATIONS.md](LIMITATIONS.md)), so pointing a conformance suite at the reference standard-library transport would fail baseline MUSTs for reasons that say nothing about cA2A.
-  - The first thing to look for is whether the protobuf `Struct` integer-ness round trip documented in `ca2a_runtime.transport.a2a_sdk` lands in the same safe place on every SDK. `Struct` has no integer type, so a credential's `depth` of `0` returns as `0.0`, and the chain verifies only because `DelegationCredential.from_dict` coerces with `int()` before RFC 8785 canonicalisation, which refuses floats outright. That it is safe in Python is tested. That it is safe in Go and Rust is an assumption.
+  - Check the protobuf `Struct` numeric round trip documented in `ca2a_runtime.transport.a2a_sdk` on each SDK. `Struct` represents integer fields as floating-point values. The Python bridge restores only finite integral `depth`, `not_before`, and `not_after` values before the strict credential parser; non-integral values are rejected rather than truncated. The Python boundary is tested. Equivalent behavior in Go and Rust still needs validation.
 - OWASP liaison on the multi-agent threat mapping; ITI conversation on conformance