diff --git a/drafts/agent-surface.md b/drafts/agent-surface.md
index 2574c6f..146b582 100644
--- a/drafts/agent-surface.md
+++ b/drafts/agent-surface.md
@@ -762,6 +762,90 @@ The runtime-to-agent integration layer:
 
 The adapter layer turns a concrete agent into a runtime-mediated worker.
 
+## Canonical Integrity and Provenance
+
+### Canonical Object Hash Profile
+
+ASP manifests, grants, action inputs, policy decisions, and receipts use the
+`asp-jcs-sha-256` profile when a field in this draft is named `surface_hash`,
+`grant_hash`, `input_hash`, `policy_decision_hash`, `receipt_hash`, or
+`parent_receipt_hash`. The profile identifies exact JSON content; it does not
+by itself authenticate the producer or grant authority.
+
+To compute an ASP object hash, an implementation MUST:
+
+1. Construct the hashing view for the object type according to the table below.
+2. Reject input that is not valid I-JSON, including duplicate object member
+   names, non-Unicode strings, or numbers that cannot be represented as IEEE
+   754 binary64 values. JSON negative zero also MUST be rejected rather than
+   normalized to positive zero.
+3. Construct an object with exactly two members: `domain`, containing the
+   domain URI from the table, and `object`, containing the hashing view.
+4. Serialize that wrapper with the JSON Canonicalization Scheme defined by RFC
+   8785. Object members are sorted by JCS; array order is preserved and is
+   therefore significant to the resulting hash. No additional Unicode, URI,
+   timestamp, default-value, or array normalization is performed.
+5. Compute SHA-256 over the canonical UTF-8 wrapper bytes.
+6. Encode the digest with the RFC 4648 base64url alphabet without `=` padding
+   and prepend the literal `sha-256:`.
+
+| Object | Domain URI | Hashing view exclusions |
+| --- | --- | --- |
+| Agent Surface Manifest | `https://github.com/0al-spec/agent-surface/hash/manifest/v1` | top-level `surface_hash` |
+| authoritative Agent Grant | `https://github.com/0al-spec/agent-surface/hash/grant/v1` | top-level `grant_hash`; the RFC 9396 `type` discriminator when starting from an OAuth authorization-details object |
+| Action Request `input` | `https://github.com/0al-spec/agent-surface/hash/action-input/v1` | none; the hashing view is exactly `payload.input` after schema validation and before default insertion, coercion, or other semantic normalization |
+| Policy Decision Object | `https://github.com/0al-spec/agent-surface/hash/policy-decision/v1` | top-level `policy_decision_hash` |
+| receipt | `https://github.com/0al-spec/agent-surface/hash/receipt/v1` | top-level `receipt_hash` and `receipt_signatures` |
+
+All other members, including extension members, are part of the hashing view.
+Omitting an unknown member before hashing is therefore an integrity failure,
+not extension tolerance. A party that receives a redacted or filtered object
+MAY carry its hash as an opaque reference but MUST NOT claim to have recomputed
+it without the complete hashing view.
+
+The Action Input hash commits to the exact validated wire input and prevents a
+receipt from being attached to different input. It is distinct from the
+action-specific semantic normalization used for idempotency; JCS does not
+define default insertion, equivalence, or set ordering.
+
+The following minimal vector fixes the domain separation, wrapper, JCS, and
+encoding rules. For the Grant domain and hashing view
+`{"grant_id":"grant_123","scopes":["read"]}`, the canonical wrapper is:
+
+```json
+{"domain":"https://github.com/0al-spec/agent-surface/hash/grant/v1","object":{"grant_id":"grant_123","scopes":["read"]}}
+```
+
+Its hash value is:
+
+```text
+sha-256:Xbq37_fP9PBiWI3Bv7Ch0t8TV5ikJGm55MxncSeA38Y
+```
+
+The following manifest vector demonstrates self-field exclusion and nested JCS
+member ordering. Given this received object:
+
+```json
+{"z":1,"surface_hash":"sha-256:Mckhl9gi8ePkXnuOJtPFNE1pe9LhilOGu1OgzxsXb8A","a":"x"}
+```
+
+the hashing view omits `surface_hash`, and the canonical wrapper is:
+
+```json
+{"domain":"https://github.com/0al-spec/agent-surface/hash/manifest/v1","object":{"a":"x","z":1}}
+```
+
+The recomputed value is `sha-256:Mckhl9gi8ePkXnuOJtPFNE1pe9LhilOGu1OgzxsXb8A`.
+Inputs containing duplicate members, JSON negative zero, a lone Unicode
+surrogate, or numeric input that would overflow binary64 to a non-finite value
+are negative vectors and MUST be rejected before hashing.
+
+An implementation MUST treat a supplied hash that does not match a recomputed
+hash as invalid. It MUST NOT fall back to `grant_id`, `surface_version`,
+`receipt_id`, or another mutable identifier. Hash-profile agility requires a
+future profile with a distinct identifier and domain URI; silently substituting
+a different digest or canonicalization algorithm is forbidden.
+
 ## Agent Surface Manifest
 
 ### Discovery
@@ -799,6 +883,7 @@ Cache-Control: max-age=300
   "app_id": "com.example.project-tool",
   "issuer": "https://example.com",
   "surface_version": "2026-06-25",
+  "surface_hash": "sha-256:<base64url-digest>",
   "surface_url": "https://example.com/.well-known/agent-surface.json",
   "auth": {},
   "agent_api": {},
@@ -811,6 +896,27 @@ Cache-Control: max-age=300
 }
 ```
 
+### Surface Hash
+
+Every manifest MUST contain `surface_hash` computed with the Canonical Object
+Hash Profile over the complete manifest hashing view. A runtime MUST recompute
+and verify it before using the manifest for capability matching, consent, grant
+issuance, or action validation. The authorization server MUST perform the same
+check before embedding the value in a grant.
+
+`surface_version` remains the application's opaque compatibility label;
+`surface_hash` identifies the exact manifest object published under that label,
+including schema URLs but not the transitive bytes served by those URLs. A
+runtime MUST key cached surface state by issuer, app id, surface version, and
+surface hash. A publisher MUST issue a new `surface_version` whenever the
+manifest hashing view changes, including for a backward-compatible addition.
+If the same issuer, app id, and `surface_version` appears with a different
+`surface_hash`, the runtime MUST treat it as an integrity failure and MUST NOT
+silently replace the pinned object.
+
+The hash authenticates neither the issuer nor the transport. Runtimes MUST
+still enforce HTTPS, issuer and app-id binding, and any local pinning policy.
+
 ### Endpoints
 
 The manifest MUST declare enough endpoint information for a runtime to obtain or
@@ -853,6 +959,7 @@ surface discoverable.
   "app_id": "com.example.project-tool",
   "issuer": "https://example.com",
   "surface_version": "2026-06-25",
+  "surface_hash": "sha-256:<base64url-digest>",
   "surface_url": "https://example.com/.well-known/agent-surface.json",
   "compatibility": {
     "min_runtime": "application-runtime/0.1",
@@ -923,6 +1030,7 @@ surface discoverable.
       "side_effect": true,
       "approval": "user_or_app",
       "idempotency": "required",
+      "input_hash_profile": "asp-jcs-sha-256",
       "execution": {
         "mode": "write",
         "proposal_action": "comment.propose"
@@ -945,13 +1053,33 @@ surface discoverable.
     }
   ],
   "audit": {
+    "hash_profile": "asp-jcs-sha-256",
     "receipt_schema": "https://example.com/schemas/action-receipt.schema.json",
+    "receipt_signing": {
+      "profiles_supported": ["asp-jws-detached"],
+      "algorithms_supported": ["ES256"],
+      "jwks_uri": "https://example.com/.well-known/agent-surface-receipt-jwks.json"
+    },
     "required_fields": [
+      "receipt_id",
+      "receipt_type",
+      "receipt_hash",
       "grant_id",
+      "grant_hash",
       "session_id",
+      "trace_id",
+      "span_id",
       "action_id",
+      "app_id",
+      "surface_version",
+      "surface_hash",
+      "runtime",
       "actor_agent",
-      "user",
+      "subject",
+      "idempotency_key",
+      "input_hash",
+      "policy_decision",
+      "policy_decision_hash",
       "timestamp",
       "result"
     ]
@@ -963,6 +1091,12 @@ surface discoverable.
 }
 ```
 
+`audit.required_fields` advertises the non-conditional minimum for application
+receipts and MUST NOT weaken the Receipt Requirements profile. Conditional
+fields such as `parent_receipt_hash`, `output_hash`, approval evidence, error
+classification, and required signatures remain mandatory when their receipt
+semantics require them even if they are not repeated in this list.
+
 ### Resources
 
 Resources describe data the agent MAY read, reference, or attach to an action.
@@ -1005,6 +1139,11 @@ Each action SHOULD include:
 - optional `capability_hint`
 - `idempotency` for side-effecting actions
 - `receipt` for side-effecting actions
+- `input_hash_profile` for actions requiring receipt-linked input evidence
+
+An action whose receipt chain binds the exact request input MUST set
+`input_hash_profile` to `asp-jcs-sha-256`. Other profile identifiers are not
+defined by this draft.
 
 Example:
 
@@ -1016,6 +1155,7 @@ Example:
   "side_effect": true,
   "approval": "user_or_app",
   "idempotency": "required",
+  "input_hash_profile": "asp-jcs-sha-256",
   "execution": {
     "mode": "write",
     "proposal_action": "pull_request.review.propose"
@@ -1157,6 +1297,71 @@ the approval can be linked into receipts and audited. Applications that do not
 want to accept runtime approval assertions MUST declare `app` or
 `runtime_and_app` for the affected actions.
 
+### Policy Decision Object
+
+A runtime or application that records why an action was allowed, denied, or
+paused for approval MUST use a `policy.decision` object. The object explains one
+component's final policy evaluation; it is evidence for audit and user
+explanation, not authority that another component must accept.
+
+```json
+{
+  "type": "policy.decision",
+  "decision_id": "pdec_runtime_01J2ABCDEF",
+  "enforcer": {
+    "type": "runtime",
+    "id": "application_runtime_456"
+  },
+  "outcome": "allow",
+  "policy": {
+    "id": "local-agent-action-policy",
+    "version": "2026-06-25"
+  },
+  "reason_code": "approval_satisfied",
+  "matched_rules": ["writes.require_local_approval"],
+  "safe_to_show": "The requested write is within the grant and was approved.",
+  "evaluated_at": "2026-06-25T16:29:59Z",
+  "policy_decision_hash": "sha-256:<base64url-digest>"
+}
+```
+
+`type`, `decision_id`, `enforcer`, `outcome`, `policy`, `reason_code`,
+`matched_rules`, `safe_to_show`, `evaluated_at`, and `policy_decision_hash` are
+REQUIRED. `outcome` MUST be `allow`, `deny`, or `require_approval`.
+`enforcer.type` MUST be `runtime`, `application`, or `enterprise`; `enforcer.id`
+identifies the component whose policy was evaluated. `policy.id` and
+`policy.version` identify the applied policy snapshot. Identifiers and
+`safe_to_show` are non-empty strings. `matched_rules` is an array of unique
+strings. `evaluated_at` is an RFC 3339 UTC timestamp with the `Z` suffix.
+
+`reason_code` is the primary stable machine-readable explanation. This draft
+defines `policy_allowed`, `approval_required`, `approval_satisfied`,
+`scope_denied`, `resource_denied`, `binding_invalid`, `limit_exceeded`,
+`local_policy_denied`, and `app_policy_denied`. Extensions MUST use a
+collision-resistant URI. `matched_rules` contains stable, non-secret rule
+identifiers and MAY be empty when disclosure would reveal policy internals.
+`safe_to_show` MUST be suitable for display to the affected user and MUST NOT
+contain secrets, credentials, hidden rule content, or sensitive resource data.
+
+The standard reason codes are valid only with these outcomes:
+
+| Outcome | Allowed standard reason codes |
+| --- | --- |
+| `allow` | `policy_allowed`, `approval_satisfied` |
+| `require_approval` | `approval_required` |
+| `deny` | `scope_denied`, `resource_denied`, `binding_invalid`, `limit_exceeded`, `local_policy_denied`, `app_policy_denied` |
+
+An extension reason-code specification MUST declare its allowed outcome. A
+producer and verifier MUST reject a standard or extension reason code used with
+an incompatible outcome.
+
+The producer MUST compute `policy_decision_hash` with the Canonical Object Hash
+Profile. A receipt MUST include the complete decision that directly determined
+its producer's outcome and repeat the matching hash at receipt top level. A
+runtime and application normally produce different decisions and hashes; an
+application MUST NOT treat a runtime decision as authority to widen the Agent
+Grant or bypass its own checks.
+
 ## Idempotency
 
 Every side-effecting action MUST support idempotency.
@@ -1184,10 +1389,20 @@ so a retrying runtime can converge on the outcome of the first attempt.
 Applications SHOULD retain idempotency state at least for the remaining
 lifetime of the grant and SHOULD document their retention window.
 
-Applications SHOULD define the input normalization procedure per action, or use
-the declared input schema with a canonical JSON profile. A future draft is
-expected to define canonicalization requirements for signed receipts and signed
-grants.
+An exact retry under the Receipt Hash Chain profile MUST reuse the original
+finalized runtime receipt and the same `parent_receipt_hash`; it MUST NOT create
+a second policy receipt for the already-authorized side effect. The application
+returns the original immutable app receipt. If the same grant, action,
+idempotency key, and normalized input arrives with a different parent hash, the
+application MUST NOT repeat the side effect and MUST report
+`integrity_mismatch` rather than attaching the original result to a competing
+provenance chain.
+
+Applications SHOULD define the semantic input-normalization procedure per
+action. After that procedure, they MAY use the Canonical Object Hash Profile's
+JCS rules to obtain stable JSON bytes. JCS does not define action-specific
+normalization, default insertion, set ordering, or schema equivalence, so its
+availability does not remove that requirement.
 
 ## Agent Grant
 
@@ -1199,6 +1414,7 @@ surface, scopes, and caveats.
 ```json
 {
   "grant_id": "grant_123",
+  "grant_hash": "sha-256:<base64url-digest>",
   "subject": {
     "user": "user_abc"
   },
@@ -1211,7 +1427,8 @@ surface, scopes, and caveats.
   "resource_server": {
     "app_id": "code.example.com",
     "issuer": "https://code.example.com",
-    "surface_version": "2026-06-25"
+    "surface_version": "2026-06-25",
+    "surface_hash": "sha-256:<base64url-digest>"
   },
   "locations": ["https://code.example.com/agent-actions"],
   "actions": ["pull_request.get", "comment.create"],
@@ -1255,6 +1472,32 @@ runtime, agent, and passport tuple. A DPoP binding MUST additionally contain
 `jkt`; an mTLS binding MUST instead contain `x5t#S256`. Those values use the
 same encoding and semantics as the corresponding standard `cnf` members.
 
+### Grant Hash
+
+The authorization server MUST add `grant_hash` after constructing the complete
+authoritative Agent Grant, including `grant_id`, subject, delegate,
+`resource_server.surface_hash`, effective constraints, credential profile, and
+credential binding. It computes the value with the Canonical Object Hash
+Profile and persists the exact hashing view for the lifetime of the grant and
+its audit-retention period.
+
+The client MUST NOT supply `grant_hash` in an authorization request. Token and
+introspection responses MUST return it with the authoritative grant. An action
+request and every receipt under that grant MUST carry the same value. The
+application MUST compare it with current authoritative grant state and reject a
+mismatch as `integrity_mismatch`; selecting state by `grant_id` and ignoring a
+hash mismatch is forbidden.
+
+Attenuating, renewing, or otherwise changing any hashed member creates a new
+`grant_hash`, even when a deployment retains a related identifier for lifecycle
+tracking. Token rotation alone does not change `grant_hash` when the underlying
+Agent Grant object is unchanged. Parent and child grants have independent
+hashes and retain their explicit derivation linkage.
+
+`grant_hash` does not prove that a grant is active, unrevoked, or within its
+remaining stateful budget. Those mutable checks still use authoritative grant
+state on every action.
+
 Numeric caveats need defined accounting. In this draft, `max_actions` counts
 side-effecting action requests accepted by the application under the grant.
 Reads and denied requests do not consume the budget, and neither do idempotent
@@ -1347,8 +1590,8 @@ Pros:
 
 Cons:
 
-- Requires canonicalization, trust stores, signing profiles, revocation
-  semantics, and stronger interop work.
+- Requires a signed-grant profile, trust stores, signer-key lifecycle,
+  revocation semantics, and stronger interop work beyond the receipt profile.
 - Too large for the first MVP.
 
 ### OAuth Grant Lifecycle Profile
@@ -1395,7 +1638,8 @@ Example, shown decoded from its form-encoded authorization request parameter:
     "resource_server": {
       "app_id": "code.example.com",
       "issuer": "https://code.example.com",
-      "surface_version": "2026-06-25"
+      "surface_version": "2026-06-25",
+      "surface_hash": "sha-256:<base64url-digest>"
     },
     "scopes": ["pull_request.read", "pull_request.comment"],
     "constraints": {
@@ -1422,7 +1666,8 @@ are the authoritative Grant Object wire shape defined above:
   `credential_profile`, and `audit` are REQUIRED.
 - `delegate` MUST contain `runtime`, `agent`, and `passport_hash`; it MAY contain
   `passport_ref`.
-- `resource_server` MUST contain `app_id`, `issuer`, and `surface_version`.
+- `resource_server` MUST contain `app_id`, `issuer`, `surface_version`, and the
+  verified `surface_hash`.
 - `constraints` MUST contain `expires_at`; other fields use the semantics of the
   Agent Grant object.
 - `credential_profile` MUST be `compatibility_bearer` or `proof_bound` and maps
@@ -1433,16 +1678,23 @@ are the authoritative Grant Object wire shape defined above:
   invoked action MUST be a member. The authorization applies to the product of
   the granted actions, locations, scopes, and resource filters; every allowed
   combination MUST be published by the surface and semantically compatible.
-- `grant_id`, `subject`, and `credential_binding` MUST NOT be supplied by the
-  client in an authorization request; they are authorization-server output.
+- `grant_id`, `grant_hash`, `subject`, and `credential_binding` MUST NOT be
+  supplied by the client in an authorization request; they are
+  authorization-server output.
+- A client MAY request an `audit.receipt_signing` profile and signer roles, but
+  it MUST NOT supply authoritative `signer_keys`. Before issuance, the
+  authorization server MUST reject a request containing those entries, derive
+  them from issuer metadata and the authenticated runtime key registration,
+  and include the resulting pins in `grant_hash`.
 - The request MUST NOT supply `subject.user` or another asserted user identity;
   the authorization server derives the subject from its authenticated user
   session or, at the token endpoint, from the validated `subject_token`.
 
 The authorization server MUST reject unknown fields, unknown action or scope
 values, a mismatched `resource_server.app_id` or
-`resource_server.surface_version`, an unverified passport hash, or constraints
-that are invalid for the published surface. It MUST use the RFC 9396
+`resource_server.surface_version`, a mismatched `resource_server.surface_hash`,
+an unverified passport hash, or constraints that are invalid for the published
+surface. It MUST use the RFC 9396
 `invalid_authorization_details` error for malformed or unsupported Agent Grant
 authorization details.
 
@@ -1474,7 +1726,7 @@ authority.
 The token response MUST return the granted `authorization_details` as required
 by RFC 9396. For this type, the returned object MUST be enriched with the
 authoritative `grant_id`, `subject`, delegate binding, effective constraints,
-and `credential_binding` assigned by the authorization server. The
+`credential_binding`, and `grant_hash` assigned by the authorization server. The
 authorization server and resource server MUST retain or receive the same
 granted object for later action verification and introspection.
 
@@ -1548,8 +1800,8 @@ multiply `max_actions`, `max_cost_usd`, or another stateful budget. The
 authorization server MUST treat semantically equivalent exchanges with the
 same source authorization, client and delegate tuple, target resource,
 normalized Agent Grant details, and proof-binding key as idempotent: it MUST
-reuse the same `grant_id` and accounting state, although it MAY rotate the
-access-token representation.
+reuse the same `grant_id`, `grant_hash`, and accounting state, although it MAY
+rotate the access-token representation.
 
 Example successful response:
 
@@ -1561,6 +1813,7 @@ Example successful response:
   "expires_in": 1800,
   "scope": "pull_request.read pull_request.comment",
   "grant_id": "grant_123",
+  "grant_hash": "sha-256:<base64url-digest>",
   "authorization_details": [
     {
       "type": "https://github.com/0al-spec/agent-surface/authorization-details/agent-grant",
@@ -1578,7 +1831,8 @@ Example successful response:
       "resource_server": {
         "app_id": "code.example.com",
         "issuer": "https://code.example.com",
-        "surface_version": "2026-06-25"
+        "surface_version": "2026-06-25",
+        "surface_hash": "sha-256:<base64url-digest>"
       },
       "scopes": ["pull_request.read", "pull_request.comment"],
       "constraints": {
@@ -1600,22 +1854,29 @@ Example successful response:
         "local_receipt": "required",
         "app_receipt": "required"
       },
-      "grant_id": "grant_123"
+      "grant_id": "grant_123",
+      "grant_hash": "sha-256:<base64url-digest>"
     }
   ]
 }
 ```
 
 The response MUST include `access_token`, `issued_token_type`, `token_type`,
-`expires_in`, `grant_id`, the exact `scope` projection defined above, and the
-granted `authorization_details`. This also satisfies the RFC 8693 requirement to
-return `scope` when the issued scope differs from the request. The `token_type`
-and method-specific credential confirmation data MUST match the selected
+`expires_in`, `grant_id`, `grant_hash`, the exact `scope` projection defined
+above, and the granted `authorization_details`. This also satisfies the RFC
+8693 requirement to return `scope` when the issued scope differs from the
+request. The `token_type` and method-specific credential confirmation data MUST
+match the selected
 credential profile and the binding established at the token endpoint. A
 refresh token SHOULD NOT be issued by default; if one is issued, it MUST
 preserve the tuple binding, attenuation, and revocation linkage of the Agent
 Grant and follow RFC 9700 refresh-token replay protections.
 
+Top-level `grant_id` and `grant_hash` MUST exactly match the same members in the
+sole returned Agent Grant authorization-details object. The client MUST reject
+the token response if either projection is absent or mismatched; it MUST NOT
+select one representation and ignore the other.
+
 Token responses containing a Grant Credential or its authorization details MUST
 use `Cache-Control: no-store` and `Pragma: no-cache`.
 
@@ -1641,7 +1902,7 @@ outside the caller's authority.
 
 For an active Grant Credential, the response MUST include the RFC 7662 fields
 `active`, `client_id`, `scope`, `token_type`, `exp`, `iat`, `sub`, `aud`, and
-`iss`, plus the ASP fields `grant_id`, `resource_server`, `delegate`,
+`iss`, plus the ASP fields `grant_id`, `grant_hash`, `resource_server`, `delegate`,
 `constraints`, `credential_binding`, and `authorization_details`. An active
 proof-bound credential MUST additionally include the method-specific standard
 `cnf` confirmation member. The `sub` value SHOULD be a stable app-scoped
@@ -1651,10 +1912,13 @@ pseudonymous user identifier. `client_id` identifies the OAuth client;
 
 The `authorization_details` member MUST contain the granted Agent Grant object,
 filtered only to data the authenticated caller may receive. Top-level `sub`,
-`grant_id`, `resource_server`, `delegate`, `constraints`, and
+`grant_id`, `grant_hash`, `resource_server`, `delegate`, `constraints`, and
 `credential_binding` are projections of that object and MUST match it; `sub`
 corresponds to `subject.user`. A resource server MUST treat a mismatch as an
-invalid grant proof rather than selecting one representation.
+invalid grant proof rather than selecting one representation. A filtered
+response still MUST carry `grant_hash` as an opaque authoritative commitment,
+but a caller MUST NOT claim to have recomputed it without the complete Grant
+Object.
 
 For DPoP, `cnf` MUST contain `jkt` as specified by RFC 9449; for mTLS, it MUST
 contain `x5t#S256` as specified by RFC 8705. The confirmation value MUST match
@@ -1677,10 +1941,12 @@ Bearer Credential MUST NOT fabricate a `cnf` member.
     "jkt": "<base64url-thumbprint>"
   },
   "grant_id": "grant_123",
+  "grant_hash": "sha-256:<base64url-digest>",
   "resource_server": {
     "app_id": "code.example.com",
     "issuer": "https://code.example.com",
-    "surface_version": "2026-06-25"
+    "surface_version": "2026-06-25",
+    "surface_hash": "sha-256:<base64url-digest>"
   },
   "delegate": {
     "runtime": "application_runtime_456",
@@ -1719,7 +1985,8 @@ Bearer Credential MUST NOT fabricate a `cnf` member.
       "resource_server": {
         "app_id": "code.example.com",
         "issuer": "https://code.example.com",
-        "surface_version": "2026-06-25"
+        "surface_version": "2026-06-25",
+        "surface_hash": "sha-256:<base64url-digest>"
       },
       "scopes": ["pull_request.read", "pull_request.comment"],
       "constraints": {
@@ -1741,7 +2008,8 @@ Bearer Credential MUST NOT fabricate a `cnf` member.
         "local_receipt": "required",
         "app_receipt": "required"
       },
-      "grant_id": "grant_123"
+      "grant_id": "grant_123",
+      "grant_hash": "sha-256:<base64url-digest>"
     }
   ]
 }
@@ -1850,6 +2118,10 @@ forwarded as implicit subdelegation.
 Applications MUST verify every action against grant state:
 
 - grant exists and is active
+- recomputed `grant_hash` matches both the presented action context and current
+  authoritative Grant Object
+- `resource_server.surface_hash` matches the retained, verified manifest
+  snapshot used to interpret the action and its schemas
 - grant credential or proof is valid
 - grant is bound to the user
 - grant is bound to the runtime
@@ -1876,6 +2148,8 @@ Applications MUST verify every action against grant state:
 Runtimes SHOULD verify:
 
 - grant is active
+- `grant_hash` matches the complete grant returned at issuance or introspection
+- `surface_hash` matches the verified manifest snapshot pinned for that grant
 - local user has not revoked the app, runtime, or agent
 - Agent Passport is valid
 - requested action is compatible with the Agent Passport capability set
@@ -1929,6 +2203,62 @@ Matching outputs:
 
 The matching result is shown to the user before grant issuance.
 
+## Observability Context
+
+ASP uses W3C Trace Context for cross-component diagnostic correlation. An ASP
+session, action, event, and receipt MAY participate in a distributed trace, but
+trace context is never authorization, identity, idempotency, or proof that two
+objects belong to the same grant.
+
+JSON envelopes that carry observability context use `trace_id` and `span_id`.
+`trace_id` MUST be 32 lowercase hexadecimal characters representing 16 bytes
+and MUST NOT be all zero. `span_id` MUST be 16 lowercase hexadecimal characters
+representing 8 bytes and MUST NOT be all zero. These are projections of the W3C
+`trace-id` and `parent-id` formats. `session_id` remains the ASP lifecycle and
+accounting identifier and MUST continue to be validated independently.
+
+When an implementation claims the Application Runtime or Receipt-Producing
+profile, its `session.start`, `action.request`, `action.result`, and receipt
+envelopes MUST carry `session_id`, `trace_id`, and the producer's `span_id` as
+shown below. Each runtime and application MUST record the identifiers from the
+envelope or receipt it produces in the corresponding local log entry so those
+logs can be joined without parsing human-readable messages. Trace and session
+ids can match across components while each producer records its own span id.
+This draft defines correlation fields, not a telemetry export protocol or
+vendor backend.
+
+For an HTTP binding, a component carrying valid ASP observability context MUST
+send `traceparent`. A component participating in an incoming W3C trace MUST
+propagate `traceparent` and `tracestate` according to W3C Trace Context, subject
+to its defined trust-boundary privacy policy. It preserves a valid incoming
+`trace_id`, creates a fresh `span_id` for its own operation, and propagates that
+child context downstream. A receipt records the span of the component that
+produced it. Runtime and application receipts for one action therefore normally
+share `trace_id` and `session_id` but have different `span_id` values.
+
+An intermediary is allowed to create another span, so a receiver MUST NOT
+require the JSON `span_id` to equal the `parent-id` in the HTTP header after
+intermediation. For local processing, a valid `traceparent` takes precedence
+over the JSON projection. If no valid header exists and a verified parent
+receipt is available, the receiver continues the parent receipt's `trace_id`
+with a new span. Otherwise it uses a valid JSON `trace_id` or starts a new
+trace, in that order.
+
+If the selected processing trace differs from a verified parent receipt's
+trace because an intermediary or trust boundary restarted it, the child receipt
+MUST include `linked_trace_id` equal to the parent `trace_id`. Without such a
+documented restart, parent and child receipts MUST use the same `trace_id`.
+`linked_trace_id` uses the same format as `trace_id` and is included in the
+receipt hash. Invalid or conflicting trace context MUST NOT cause an otherwise
+unauthorized action to be accepted, and it MUST NOT bypass grant, session, or
+receipt-link verification.
+
+Trace identifiers MUST be generated without embedding user, agent, resource,
+tenant, or policy semantics. Producers MUST apply the same disclosure and
+retention controls to `tracestate` and correlated telemetry as to other audit
+metadata. An Agent Adapter preserves `session_id` and a valid `trace_id` across
+its boundary and creates a new `span_id` for each adapter operation.
+
 ## Sessions and Actions
 
 ### Session Start
@@ -1940,11 +2270,15 @@ Once a grant exists, an application or runtime MAY start a session.
   "type": "session.start",
   "payload": {
     "session_id": "sess_456",
+    "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
+    "span_id": "a3ce929d0e0e4736",
     "grant_id": "grant_123",
+    "grant_hash": "sha-256:<base64url-digest>",
     "agent_id": "local_agent_789",
     "surface": {
       "app_id": "code.example.com",
-      "surface_version": "2026-06-25"
+      "surface_version": "2026-06-25",
+      "surface_hash": "sha-256:<base64url-digest>"
     },
     "task": {
       "kind": "pull_request.review",
@@ -1972,6 +2306,11 @@ presented grant. Otherwise a valid grant credential could be replayed against
 sessions created under other grants, corrupting session accounting and receipt
 linkage.
 
+The application MUST also verify that body `grant_hash` matches the complete
+authoritative grant selected by the credential and that `surface_hash` matches
+the manifest snapshot pinned by that grant. These hashes are correlation and
+integrity commitments, not substitutes for the HTTP authorization proof.
+
 If both the `Idempotency-Key` header and the body `idempotency_key` field are
 present, they MUST match, and the application MUST reject a mismatch as
 `schema_invalid`. Accepting a mismatched request and picking either value
@@ -1985,6 +2324,7 @@ POST /agent-actions HTTP/1.1
 Host: example.com
 Authorization: DPoP <grant-credential>
 DPoP: <signed-proof>
+traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-b7ad6b7169203331-01
 Idempotency-Key: idem_01HX7DS8AC6G9
 Content-Type: application/json
 ```
@@ -1994,9 +2334,15 @@ Content-Type: application/json
   "type": "action.request",
   "payload": {
     "session_id": "sess_456",
+    "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
+    "span_id": "b7ad6b7169203331",
     "grant_id": "grant_123",
+    "grant_hash": "sha-256:<base64url-digest>",
+    "surface_hash": "sha-256:<base64url-digest>",
     "action_id": "comment.create",
     "idempotency_key": "idem_01HX7DS8AC6G9",
+    "parent_receipt_hash": "sha-256:<runtime-receipt-digest>",
+    "input_hash": "sha-256:<action-input-digest>",
     "input": {
       "repository": "example-org/example-repo",
       "pull_request": 13,
@@ -2010,6 +2356,24 @@ The request's proof material MUST use the authorization mechanism selected by
 the credential-binding profile. For example, a DPoP-bound credential carries a
 DPoP proof in the `DPoP` header as defined by RFC 9449.
 
+Before forwarding a side-effecting action, the runtime MUST finalize its
+runtime receipt and place that receipt's `receipt_hash` in
+`parent_receipt_hash`. When the application requires the runtime receipt
+content, the runtime MUST either submit the complete receipt through the
+manifest `agent_api.receipt_url` before the action or carry it inline through a
+declared action-request extension. The application MUST recompute the supplied
+receipt and policy-decision hashes before treating the receipt as verified. A
+bare parent hash is correlation evidence only and is insufficient when app
+policy requires verification of the runtime decision.
+
+For an action requiring runtime receipt evidence, the action declaration MUST
+set `input_hash_profile` to `asp-jcs-sha-256`. The runtime and application MUST
+compute the Action Input hash over the exact validated wire `input` and require
+equality with both the action request and verified parent runtime receipt. A
+receipt for one input MUST NOT be attached to a different input even when the
+grant, action id, and idempotency key match. The semantic normalization used
+for idempotency remains a separate action contract.
+
 ### Action Response
 
 ```json
@@ -2017,7 +2381,11 @@ DPoP proof in the `DPoP` header as defined by RFC 9449.
   "type": "action.result",
   "payload": {
     "session_id": "sess_456",
+    "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
+    "span_id": "00f067aa0ba902b7",
     "grant_id": "grant_123",
+    "grant_hash": "sha-256:<base64url-digest>",
+    "surface_hash": "sha-256:<base64url-digest>",
     "action_id": "comment.create",
     "idempotency_key": "idem_01HX7DS8AC6G9",
     "result": "success",
@@ -2026,7 +2394,8 @@ DPoP proof in the `DPoP` header as defined by RFC 9449.
       "id": "comment_789",
       "url": "https://code.example.com/example-org/example-repo/pull/13#discussion_r..."
     },
-    "receipt_id": "receipt_abc"
+    "receipt_id": "receipt_app_abc",
+    "receipt_hash": "sha-256:<app-receipt-digest>"
   }
 }
 ```
@@ -2050,12 +2419,17 @@ This is the RECOMMENDED default for early integrations.
 
 ### Receipt Requirements
 
-Receipts SHOULD include:
+Receipts produced under the Receipt-Producing Application profile MUST include:
 
 - receipt id
 - receipt type
+- receipt hash
 - grant id
+- grant hash
 - session id
+- trace id
+- producer span id
+- linked parent trace id when a trust boundary restarted tracing
 - action id
 - app id
 - user id or stable pseudonymous user reference
@@ -2063,6 +2437,8 @@ Receipts SHOULD include:
 - agent id
 - Agent Passport hash
 - surface version
+- surface hash
+- policy decision and policy decision hash
 - input hash
 - output hash
 - approval reference
@@ -2071,6 +2447,47 @@ Receipts SHOULD include:
 - result
 - error classification when failed
 
+Fields that do not apply to the recorded outcome, such as `output_hash` for a
+denial before execution, MAY be omitted. The identity, authority, trace,
+decision, and result fields that do apply MUST be present and internally
+consistent.
+
+### Receipt Hash Chain
+
+Every runtime and application receipt MUST contain `receipt_hash` computed with
+the Canonical Object Hash Profile. A root receipt omits
+`parent_receipt_hash`; it MUST NOT encode the missing parent as `null`. A
+non-root receipt contains exactly one `parent_receipt_hash`, which is included
+in its own hashing view.
+
+For a runtime-mediated side-effecting action whose grant requires a runtime
+receipt, the application receipt MUST use the verified runtime
+`receipt_hash` from the action request as its `parent_receipt_hash`. A later
+runtime receipt MAY use the returned application `receipt_hash` as its parent.
+This single-parent model permits branches but does not represent multi-parent
+causal joins; a future profile may define a DAG representation.
+
+A parent and child receipt for one action MUST carry identical `grant_hash`,
+`surface_hash`, `session_id`, `action_id`, `idempotency_key`, and `input_hash`.
+They also carry the same `trace_id` unless the child records a trust-boundary
+restart with `linked_trace_id` equal to the parent's `trace_id`.
+Their `span_id` and `policy_decision_hash` normally differ because each producer
+records its own operation and decision. A consumer MUST recompute every
+available object hash, verify these invariants, reject a cycle, and stop at any
+missing or mismatched parent. Reusing one `receipt_id` for different
+`receipt_hash` values is an invalid receipt conflict.
+
+The runtime makes its parent receipt available to the application through the
+`agent_api.receipt_url` or an explicitly declared inline action-request
+extension, as defined in Action Request. The application MUST NOT claim a
+verified parent link when it received only an unverified hash and its policy
+requires the parent content.
+
+A hash chain is tamper-evident only relative to a trusted stored chain head or
+authenticated signature. A party that can replace an entire unsigned chain can
+recompute every hash. Receipt hashes and links therefore do not authenticate a
+producer and do not authorize an action.
+
 ### Runtime Receipt
 
 A runtime receipt records what the runtime observed and enforced, such as agent
@@ -2081,9 +2498,16 @@ redactions.
 {
   "receipt_id": "receipt_runtime_abc",
   "receipt_type": "runtime",
+  "receipt_hash": "sha-256:<runtime-receipt-digest>",
   "grant_id": "grant_123",
+  "grant_hash": "sha-256:<base64url-digest>",
   "session_id": "sess_456",
+  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
+  "span_id": "b7ad6b7169203331",
   "action_id": "comment.create",
+  "app_id": "code.example.com",
+  "surface_version": "2026-06-25",
+  "surface_hash": "sha-256:<base64url-digest>",
   "actor_agent": {
     "agent_id": "local_agent_789",
     "passport_hash": "sha256:..."
@@ -2095,13 +2519,32 @@ redactions.
     "user": "user_abc"
   },
   "idempotency_key": "idem_01HX7DS8AC6G9",
-  "input_hash": "sha256:...",
+  "input_hash": "sha-256:<action-input-digest>",
+  "policy_decision_hash": "sha-256:<runtime-policy-decision-digest>",
+  "policy_decision": {
+    "type": "policy.decision",
+    "decision_id": "pdec_runtime_01J2ABCDEF",
+    "enforcer": {
+      "type": "runtime",
+      "id": "application_runtime_456"
+    },
+    "outcome": "allow",
+    "policy": {
+      "id": "local-agent-action-policy",
+      "version": "2026-06-25"
+    },
+    "reason_code": "approval_satisfied",
+    "matched_rules": ["writes.require_local_approval"],
+    "safe_to_show": "The requested write is within the grant and was approved.",
+    "evaluated_at": "2026-06-25T16:29:59Z",
+    "policy_decision_hash": "sha-256:<runtime-policy-decision-digest>"
+  },
   "approved_by": {
     "type": "runtime_user_approval",
     "approval_id": "appr_123"
   },
   "timestamp": "2026-06-25T16:30:00Z",
-  "result": "forwarded_to_app"
+  "result": "authorized_for_forwarding"
 }
 ```
 
@@ -2114,11 +2557,17 @@ deduplicated under a grant.
 {
   "receipt_id": "receipt_app_abc",
   "receipt_type": "app",
+  "receipt_hash": "sha-256:<app-receipt-digest>",
+  "parent_receipt_hash": "sha-256:<runtime-receipt-digest>",
   "grant_id": "grant_123",
+  "grant_hash": "sha-256:<base64url-digest>",
   "session_id": "sess_456",
+  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
+  "span_id": "00f067aa0ba902b7",
   "action_id": "comment.create",
   "app_id": "code.example.com",
   "surface_version": "2026-06-25",
+  "surface_hash": "sha-256:<base64url-digest>",
   "runtime": {
     "runtime_id": "application_runtime_456"
   },
@@ -2130,8 +2579,27 @@ deduplicated under a grant.
     "user": "user_abc"
   },
   "idempotency_key": "idem_01HX7DS8AC6G9",
-  "input_hash": "sha256:...",
+  "input_hash": "sha-256:<action-input-digest>",
   "output_hash": "sha256:...",
+  "policy_decision_hash": "sha-256:<app-policy-decision-digest>",
+  "policy_decision": {
+    "type": "policy.decision",
+    "decision_id": "pdec_app_01J2ABCDEG",
+    "enforcer": {
+      "type": "application",
+      "id": "code.example.com"
+    },
+    "outcome": "allow",
+    "policy": {
+      "id": "agent-action-policy",
+      "version": "2026-06-25"
+    },
+    "reason_code": "policy_allowed",
+    "matched_rules": ["grant.active", "action.comment.create"],
+    "safe_to_show": "The application accepted the authorized comment action.",
+    "evaluated_at": "2026-06-25T16:30:00Z",
+    "policy_decision_hash": "sha-256:<app-policy-decision-digest>"
+  },
   "approved_by": {
     "type": "runtime_user_approval",
     "approval_id": "appr_123"
@@ -2141,20 +2609,147 @@ deduplicated under a grant.
     "id": "comment_789"
   },
   "timestamp": "2026-06-25T16:30:00Z",
-  "result": "success",
-  "links": {
-    "runtime_receipt_hash": "sha256:..."
+  "result": "success"
+}
+```
+
+### Receipt Signing Profile
+
+The optional `asp-jws-detached` profile lets an application, runtime, or both
+authenticate a receipt without changing `receipt_hash`. The base MVP permits
+unsigned receipts. Unsigned means that `receipt_signatures` is absent; it MUST
+NOT be represented by a JWS using `alg: none`.
+
+A grant that requires both runtime and application signatures carries:
+
+```json
+{
+  "audit": {
+    "local_receipt": "required",
+    "app_receipt": "required",
+    "receipt_signing": {
+      "profile": "asp-jws-detached",
+      "required_signers": ["runtime", "application"],
+      "signer_keys": [
+        {
+          "role": "runtime",
+          "kid": "runtime-receipt-key-2026-01",
+          "jwk_thumbprint": "<base64url-rfc7638-sha256-thumbprint>"
+        },
+        {
+          "role": "application",
+          "kid": "app-receipt-key-2026-01",
+          "jwk_thumbprint": "<base64url-rfc7638-sha256-thumbprint>"
+        }
+      ]
+    }
   }
 }
 ```
 
-Receipts MAY be signed by the app, runtime, or both. A future draft is expected
-to define canonicalization and signature profiles.
+For this profile, the signing view is the complete receipt with
+`receipt_signatures` omitted and with `receipt_hash` retained. The signer wraps
+that view as an object with `domain` equal to
+`https://github.com/0al-spec/agent-surface/signature/receipt/v1` and `receipt`
+equal to the signing view, then serializes the wrapper with RFC 8785 JCS. Those
+UTF-8 bytes are the JWS payload.
+
+The receipt carries a detached General JWS JSON Serialization as follows. The
+`payload` member is omitted according to RFC 7515 Appendix F; the verifier
+reconstructs it from the canonical signing view. Ordinary JWS base64url payload
+encoding is used, so the RFC 7797 `b64` extension MUST NOT be present.
+
+The decoded protected header for a runtime receipt has this form:
+
+```json
+{
+  "alg": "ES256",
+  "kid": "runtime-receipt-key-2026-01",
+  "typ": "asp-receipt+jws"
+}
+```
+
+The following envelope is schematic; angle-bracket strings mark values that a
+producer replaces with valid base64url JWS values.
+
+```json
+{
+  "receipt_signatures": {
+    "signatures": [
+      {
+        "protected": "<base64url-protected-header>",
+        "signature": "<base64url-es256-signature>"
+      }
+    ]
+  }
+}
+```
 
-How the application obtains the `runtime_receipt_hash` value for the `links`
-field — for example, in the action request itself or through a later
-submission to the receipt endpoint — is not defined in this draft; see Open
-Questions.
+The `receipt_signatures` object MUST contain exactly the non-empty `signatures`
+array; `payload` and every other member are forbidden in the transported
+envelope. Each signature object MUST contain exactly `protected` and
+`signature`; a JWS `header` member is forbidden. The
+decoded protected header MUST contain exactly three unique members: `alg`,
+`kid`, and `typ`. `typ` MUST be `asp-receipt+jws`; this is an ASP-private type
+string pending any media-type registration and MUST be compared exactly.
+Duplicate header members, `alg: none`, inline `jwk`, and any `jku`, `x5u`, or
+`x5c` key location MUST be rejected.
+
+Implementations of this profile MUST support `ES256` and MUST enforce an
+explicit algorithm allow-list. An ES256 JWK MUST use `kty: "EC"` and
+`crv: "P-256"`; when present, `alg` MUST be `ES256`, `use` MUST be `sig`, and
+`key_ops` MUST permit `verify`. The JWS signature decodes to the 64-octet `R ||
+S` form defined by RFC 7518, not an ASN.1 DER signature. ES256 signers SHOULD
+derive the nonce deterministically according to RFC 6979. A future profile MAY
+add a fully specified algorithm such as `Ed25519`; the polymorphic `EdDSA`
+identifier MUST NOT be substituted.
+
+`kid` is only a lookup hint. Application keys MUST be resolved through
+issuer-bound authenticated metadata such as the manifest
+`audit.receipt_signing.jwks_uri`; runtime keys MUST be resolved through the
+runtime identity or key registration bound to the grant. A verifier MUST ensure
+that the resolved key is authorized for the claimed signer and receipt role.
+For a required signer, the JWS `kid` MUST select an entry in the hashed grant's
+`audit.receipt_signing.signer_keys` whose `role` matches the receipt producer,
+and the resolved public JWK's RFC 7638 SHA-256 thumbprint MUST match
+`jwk_thumbprint`. A `kid` match without the role and pinned thumbprint is
+insufficient.
+
+An application advertising this profile MUST include `asp-jws-detached` in
+`audit.receipt_signing.profiles_supported`, `ES256` in
+`algorithms_supported`, and an issuer-bound HTTPS `jwks_uri`. A runtime signing
+receipt evidence MUST register or attest its verification key through the
+authenticated runtime relationship before a grant can require the `runtime`
+signer role. A receipt-supplied URL or inline key is never sufficient trust.
+Signers MUST retain or make their historical public keys available for at least
+the applicable receipt-retention period. Key rotation does not rewrite an old
+grant's pinned thumbprints; requiring a new key for future receipts requires a
+new grant hash or explicit grant renewal. Within one issuer and signer role, a
+`kid` MUST NOT be rebound to different key material. A compromise or revocation can make
+historical evidence indeterminate according to verifier policy because this
+profile does not provide an independent trusted timestamp.
+
+The manifest advertises supported algorithms and key metadata. A grant MAY
+make signatures mandatory through an `audit.receipt_signing` object containing
+`profile: "asp-jws-detached"` and `required_signers`, whose values are
+`runtime` and/or `application`. A listed role MUST sign the receipts it
+produces; listing both roles requires a signed runtime receipt and a signed
+application receipt, not two signatures on every receipt. Additional
+co-signatures over the same detached payload remain possible through General
+JWS. The requirement MUST include at least one pinned `signer_keys` entry for
+each required role. Because the requirement and key pins are inside the hashed
+grant rather than the removable signature envelope, they cannot be stripped
+without changing `grant_hash`. If the grant has no such requirement, an
+unsigned receipt remains conforming hash-linked audit material but MUST NOT be
+represented as authenticated portable evidence.
+
+A verifier MUST validate receipt structure and linked hashes first, reconstruct
+the canonical detached payload, enforce protected-header and key policy, verify
+the signature required for that receipt's producer role, and then validate the
+parent chain to a trusted anchor. A present but invalid, unknown, or
+unverifiable signature MUST NOT be downgraded to an unsigned receipt. Missing
+or invalid required signatures make the receipt invalid as evidence; they do
+not retroactively authorize or undo the underlying application action.
 
 ## Revocation Semantics
 
@@ -2203,7 +2798,9 @@ with this minimum envelope:
   "audience": "application_runtime_456",
   "payload": {
     "grant_id": "grant_123",
+    "grant_hash": "sha-256:<base64url-digest>",
     "app_id": "code.example.com",
+    "surface_hash": "sha-256:<base64url-digest>",
     "runtime_id": "application_runtime_456",
     "agent_id": "local_agent_789",
     "passport_hash": "sha256:...",
@@ -2217,8 +2814,9 @@ with this minimum envelope:
 ```
 
 Required event fields are `id`, `type`, `occurred_at`, `issuer`, `audience`, and
-`payload`. The payload MUST contain `grant_id`, `app_id`, `runtime_id`,
-`agent_id`, `passport_hash`, `revoked_at`, `effective_at`, `reason`, and
+`payload`. The payload MUST contain `grant_id`, `grant_hash`, `app_id`,
+`surface_hash`, `runtime_id`, `agent_id`, `passport_hash`, `revoked_at`,
+`effective_at`, `reason`, and
 `cascade`; `parent_grant_id` is REQUIRED for a child grant and otherwise MAY be
 null. Defined reason values are `user_revoked`, `application_revoked`,
 `runtime_revoked`, `credential_compromise`, `parent_revoked`, `policy_changed`,
@@ -2233,6 +2831,14 @@ of the revoked grant and MUST disclose no more grant data than the target
 runtime already possessed. A future signing profile MAY additionally define an
 application signature for portable event verification.
 
+The runtime MUST compare event `grant_hash` and `surface_hash` with its retained
+grant and manifest snapshot. If an authenticated event matches the stored
+`grant_id` and delegate tuple but either hash differs, the runtime MUST fail
+closed: mark the stored grant inactive, record `integrity_mismatch`, and
+resynchronize authoritative state. It MUST NOT replace its stored hash
+projections from the event, but it also MUST NOT ignore the revocation and keep
+using the grant.
+
 After accepting the event, the runtime MUST atomically mark the grant inactive,
 discard cached active introspection state, stop new actions and credential use,
 cancel or downgrade affected sessions according to app policy, cascade the
@@ -2301,6 +2907,7 @@ Agent Surface Protocol SHOULD define structured errors:
 | `grant_expired` | Grant has expired. |
 | `grant_revoked` | Grant was revoked. |
 | `grant_proof_invalid` | Grant credential or proof is missing, invalid, or not bound correctly. |
+| `integrity_mismatch` | A supplied surface, grant, policy-decision, receipt, or parent hash does not match its complete hashing view or authoritative projection. |
 | `scope_denied` | Grant scope does not permit the action. |
 | `resource_denied` | Grant constraints do not permit the target resource. |
 | `approval_required` | Required approval is absent. |
@@ -2325,12 +2932,13 @@ debugging.
 
 ## Versioning and Compatibility
 
-Surface manifests SHOULD include:
+Surface manifests MUST include:
 
 ```json
 {
   "protocol": "agent-surface/0.1",
   "surface_version": "2026-06-25",
+  "surface_hash": "sha-256:<base64url-digest>",
   "compatibility": {
     "min_runtime": "application-runtime/0.1",
     "schema_dialect": "https://json-schema.org/draft/2020-12/schema"
@@ -2342,6 +2950,14 @@ The `surface_version` value is an opaque identifier. Runtimes MUST compare
 surface versions for exact equality; this draft defines no ordering between
 surface versions.
 
+Any change to the manifest hashing view MUST produce both a new `surface_hash`
+and a new `surface_version`. Compatibility classification determines whether
+an existing grant requires renewal; it does not permit two different manifest
+objects to reuse one version. Applications SHOULD retain the exact old manifest
+snapshot identified by every active grant. If that snapshot is unavailable,
+the application MUST NOT interpret the action against the latest manifest and
+MUST reject the action as `surface_incompatible`.
+
 Compatibility rules:
 
 - Removing an action is a breaking change for grants whose scopes cover that
@@ -2500,13 +3116,31 @@ risk. Side-effecting actions MUST be idempotent.
 ### Surface Downgrade
 
 A malicious network or compromised app path can present an older, less safe
-surface version. Runtimes SHOULD pin issuer, app id, and minimum accepted
-protocol versions where possible.
+surface version. Runtimes SHOULD pin issuer, app id, minimum accepted protocol
+versions, and the verified version/hash tuple. Reusing one `surface_version`
+with a different hash is an integrity failure. A self-declared `surface_hash`
+does not authenticate the publisher because an attacker able to replace the
+manifest can also recompute it; HTTPS, issuer binding, and local trust policy
+remain mandatory.
+
+`surface_hash` commits to schema URLs and other manifest values, not to the
+transitive content later served by those URLs. A deployment that needs that
+property must separately pin schema content hashes or use a future canonical
+surface-bundle profile.
 
 ### Receipt Forgery
 
-Receipts SHOULD be hash-linked to normalized inputs and outputs. Future drafts
-are expected to define signing and canonicalization profiles.
+Receipts are hash-linked with the Canonical Object Hash Profile. This detects a
+changed receipt or broken parent link relative to a retained chain head, but an
+attacker that controls the whole unsigned history can replace and rehash the
+chain. The optional Receipt Signing Profile authenticates a receipt only after
+the verifier resolves an authorized signer key and validates the detached JWS;
+`kid`, hash fields, and link fields are not trust anchors by themselves.
+
+A verifier MUST reject duplicate JSON members, hash mismatches, parent cycles,
+untrusted signature keys, disallowed algorithms, and a present invalid
+signature. It MUST NOT treat an unsigned optional receipt as signed evidence or
+downgrade an invalid signature to the unsigned MVP.
 
 ## Privacy Considerations
 
@@ -2523,6 +3157,12 @@ Runtimes SHOULD minimize agent and passport disclosure when possible. Receipts
 SHOULD support pseudonymous user references where legal and operationally
 appropriate.
 
+Cross-system trace correlation can reveal relationships between otherwise
+separate user actions, tenants, and services. `trace_id`, `span_id`, and
+`tracestate` MUST NOT encode semantic identifiers or secrets. Components SHOULD
+apply bounded retention, access control, and sampling independently of whether
+the incoming trace flags request recording.
+
 ## Conformance
 
 This draft defines conformance profiles instead of a single all-or-nothing
@@ -2533,6 +3173,8 @@ profile.
 An application conforms to the Surface-Only profile when it:
 
 - publishes an Agent Surface Manifest
+- computes and publishes a valid `surface_hash` and changes
+  `surface_version` whenever the manifest hashing view changes
 - declares actions, resources, events, scopes, and schemas
 - declares risk labels for actions
 - declares endpoints or explicitly marks the surface as proposal/documentation
@@ -2547,6 +3189,8 @@ An application conforms to the Grant-Enforcing profile when it:
 - issues, validates, or introspects Agent Grants
 - validates grant state for every action
 - validates credential binding to runtime, agent, and passport evidence
+- validates `grant_hash` and binds the grant to the exact verified
+  `surface_hash` snapshot
 - treats `grant_id` as an identifier, not authority
 - supports idempotency for side-effecting actions
 - supports grant revocation
@@ -2563,6 +3207,7 @@ it:
   Rich Authorization Request Profile
 - implements the OAuth Token Exchange Profile without privilege amplification
 - returns the active and inactive Grant Introspection Profile contracts
+- returns matching top-level and authorization-details hash projections
 - implements RFC 7009 semantic grant revocation, derivation cascade, and the
   authenticated `grant.revoked` control event when an event endpoint is declared
 
@@ -2572,10 +3217,25 @@ An application conforms to the Receipt-Producing profile when it:
 
 - satisfies the Grant-Enforcing profile
 - emits app receipts for required side-effecting actions
-- links receipts to grant id, session id, action id, agent id, runtime id, and
-  idempotency key
+- emits recomputable `receipt_hash`, `grant_hash`, `surface_hash`, and
+  `policy_decision_hash` values
+- includes the complete typed Policy Decision Object and requires its embedded
+  hash to match the receipt's `policy_decision_hash`
+- links an app receipt to the verified runtime receipt through
+  `parent_receipt_hash` when runtime receipt evidence is required
+- preserves trace id, session id, action id, agent id, runtime id, and
+  idempotency key while using a producer-specific span id
+- records session id, trace id, and producer span id in the corresponding local
+  action and receipt log entry
 - records denied or failed high-risk actions
 
+An application or runtime claims the `asp-jws-detached` Receipt Signing Profile
+only when it supports the canonical detached payload, ES256 verification,
+authenticated key resolution, grant-pinned signer roles and thumbprints,
+historical public-key retention, and the no-downgrade behavior defined above.
+It MUST emit every signature required for its producer role and reject required
+or present signatures that do not verify.
+
 ### Proof-Bound Grant-Enforcing Application
 
 An application conforms to the Proof-Bound Grant-Enforcing Application profile
@@ -2594,6 +3254,7 @@ when it:
 An application runtime conforms to this profile when it:
 
 - discovers and validates Agent Surface Manifests
+- recomputes `surface_hash` and pins the exact manifest snapshot
 - verifies Agent Passport evidence before delegation
 - obtains explicit user consent before storing a grant
 - mediates agent actions instead of exposing raw authority
@@ -2610,6 +3271,10 @@ An application runtime conforms to this profile when it:
 - enforces local policy and approval rules
 - validates action input against schemas before sending to the app
 - records local audit events and runtime receipts
+- computes and validates grant, policy-decision, and receipt hashes; propagates
+  session and W3C-compatible trace context
+- records session id, trace id, and producer span id in local action and receipt
+  logs
 - stops actions when grants are revoked or expired
 
 ### Agent Adapter
@@ -2623,6 +3288,7 @@ An adapter conforms to this draft when it:
 - emits typed events
 - handles denials and approval waits
 - preserves session and grant identifiers in audit context
+- preserves valid trace ids and creates a new span id for each adapter operation
 
 ## Application MVP Mapping
 
@@ -2652,8 +3318,8 @@ To support Agent Surface Protocol, the next slices are:
 ## Example End-to-End Flow
 
 ```text
-1. App publishes /.well-known/agent-surface.json.
-2. Application runtime discovers and validates the surface.
+1. App publishes /.well-known/agent-surface.json with `surface_hash`.
+2. Application runtime recomputes the hash and pins the exact surface.
 3. User chooses "Connect my local agent".
 4. Runtime verifies the selected agent's Agent Passport.
 5. Runtime sends an Agent Grant `authorization_details` request.
@@ -2665,15 +3331,19 @@ To support Agent Surface Protocol, the next slices are:
    - duration: 2 hours
    - writes: require approval
 7. User approves a subset or the complete request.
-8. App issues or token-exchanges grant_123 and its bound Grant Credential.
+8. App issues or token-exchanges grant_123, its canonical `grant_hash`, and its
+   bound Grant Credential.
 9. Runtime stores the authoritative granted details and credential.
 10. App starts a pull-request review session.
 11. Agent reads typed PR context through runtime-mediated resources.
 12. Agent proposes a review comment.
 13. User or app approves the write.
-14. Runtime sends comment.create with an idempotency key and Grant Credential.
-15. App verifies or introspects current grant state and writes the comment.
-16. Runtime and app issue linked receipts.
+14. Runtime records its policy decision and receipt, then sends comment.create
+    with trace context, parent receipt hash, idempotency key, and Grant Credential.
+15. App verifies current grant, surface, decision, and receipt hashes and writes
+    the comment.
+16. Runtime and app receipts form a verified parent-hash chain and MAY carry
+    detached JWS signatures when required by the grant.
 17. User revokes grant_123; the app rejects it immediately.
 18. App emits authenticated `grant.revoked`; runtime stops affected work.
 ```
@@ -2686,10 +3356,6 @@ To support Agent Surface Protocol, the next slices are:
   runtime can request an Agent Grant?
 - Does grant binding require runtime attestation, or is a registered runtime id
   enough for early implementations?
-- Are receipts signed in the first version, or only hash-linked and
-  locally stored?
-- Which JSON canonicalization profile is used for signed grants and
-  receipts?
 - Is `/.well-known/agent-surface.json` public, authenticated, or both
   depending on app tenancy?
 - What is the minimal sender-constrained grant credential profile?
@@ -2698,8 +3364,6 @@ To support Agent Surface Protocol, the next slices are:
 - What happens to active sessions when an app changes surface versions?
 - What transport, ordering, acknowledgement, and replay semantics do event
   subscriptions use?
-- How does the application obtain the runtime receipt hash that an app receipt
-  links to?
 - How is `max_cost_usd` metered when runtime-side inference cost and app-side
   action cost diverge, and which side is authoritative?
 - How are runtime-side approvals proven to the application beyond an
@@ -2735,6 +3399,36 @@ To support Agent Surface Protocol, the next slices are:
   <https://www.rfc-editor.org/rfc/rfc8705>
 - OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP):
   <https://www.rfc-editor.org/rfc/rfc9449>
+- The I-JSON Message Format:
+  <https://www.rfc-editor.org/rfc/rfc7493>
+- Base-N Encodings:
+  <https://www.rfc-editor.org/rfc/rfc4648>
+- Date and Time on the Internet: Timestamps:
+  <https://www.rfc-editor.org/rfc/rfc3339>
+- JSON Web Signature (JWS):
+  <https://www.rfc-editor.org/rfc/rfc7515>
+- JSON Web Key (JWK):
+  <https://www.rfc-editor.org/rfc/rfc7517>
+- JSON Web Algorithms (JWA):
+  <https://www.rfc-editor.org/rfc/rfc7518>
+- JSON Web Key (JWK) Thumbprint:
+  <https://www.rfc-editor.org/rfc/rfc7638>
+- Deterministic Usage of DSA and ECDSA:
+  <https://www.rfc-editor.org/rfc/rfc6979>
+- JSON Web Signature Unencoded Payload Option:
+  <https://www.rfc-editor.org/rfc/rfc7797>
+- JSON Canonicalization Scheme (JCS):
+  <https://www.rfc-editor.org/rfc/rfc8785>
+- Verified erratum 7920 for JSON Canonicalization Scheme:
+  <https://www.rfc-editor.org/errata/eid7920>
+- JSON Web Token Best Current Practices:
+  <https://www.rfc-editor.org/rfc/rfc8725>
+- Fully Specified Algorithms for JOSE:
+  <https://www.rfc-editor.org/rfc/rfc9864>
+- Secure Hash Standard (SHS), FIPS 180-4:
+  <https://csrc.nist.gov/pubs/fips/180-4/upd1/final>
+- W3C Trace Context:
+  <https://www.w3.org/TR/trace-context/>
 - Key words for use in RFCs to Indicate Requirement Levels:
   <https://www.rfc-editor.org/rfc/rfc2119>
 - Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words:
diff --git a/review/agent-surface-rfc-review.html b/review/agent-surface-rfc-review.html
index 1be17ae..0accf01 100644
--- a/review/agent-surface-rfc-review.html
+++ b/review/agent-surface-rfc-review.html
@@ -779,6 +779,70 @@ <h3 id="4-agent-adapter-protocol" data-asp-heading="4. Agent Adapter Protocol">4
 <li><code>mcp-server</code></li>
 </ul>
 <p>The adapter layer turns a concrete agent into a runtime-mediated worker.</p>
+<h2 id="canonical-integrity-and-provenance" data-asp-heading="Canonical Integrity and Provenance">Canonical Integrity and Provenance</h2>
+<h3 id="canonical-object-hash-profile" data-asp-heading="Canonical Object Hash Profile">Canonical Object Hash Profile</h3>
+<p>ASP manifests, grants, action inputs, policy decisions, and receipts use the
+<code>asp-jcs-sha-256</code> profile when a field in this draft is named <code>surface_hash</code>,
+<code>grant_hash</code>, <code>input_hash</code>, <code>policy_decision_hash</code>, <code>receipt_hash</code>, or
+<code>parent_receipt_hash</code>. The profile identifies exact JSON content; it does not
+by itself authenticate the producer or grant authority.</p>
+<p>To compute an ASP object hash, an implementation MUST:</p>
+<ol>
+<li>Construct the hashing view for the object type according to the table below.</li>
+<li>Reject input that is not valid I-JSON, including duplicate object member
+names, non-Unicode strings, or numbers that cannot be represented as IEEE
+754 binary64 values. JSON negative zero also MUST be rejected rather than
+normalized to positive zero.</li>
+<li>Construct an object with exactly two members: <code>domain</code>, containing the
+domain URI from the table, and <code>object</code>, containing the hashing view.</li>
+<li>Serialize that wrapper with the JSON Canonicalization Scheme defined by RFC
+8785. Object members are sorted by JCS; array order is preserved and is
+therefore significant to the resulting hash. No additional Unicode, URI,
+timestamp, default-value, or array normalization is performed.</li>
+<li>Compute SHA-256 over the canonical UTF-8 wrapper bytes.</li>
+<li>Encode the digest with the RFC 4648 base64url alphabet without <code>=</code> padding
+and prepend the literal <code>sha-256:</code>.</li>
+</ol>
+<p>| Object | Domain URI | Hashing view exclusions |
+| --- | --- | --- |
+| Agent Surface Manifest | <code>https://github.com/0al-spec/agent-surface/hash/manifest/v1</code> | top-level <code>surface_hash</code> |
+| authoritative Agent Grant | <code>https://github.com/0al-spec/agent-surface/hash/grant/v1</code> | top-level <code>grant_hash</code>; the RFC 9396 <code>type</code> discriminator when starting from an OAuth authorization-details object |
+| Action Request <code>input</code> | <code>https://github.com/0al-spec/agent-surface/hash/action-input/v1</code> | none; the hashing view is exactly <code>payload.input</code> after schema validation and before default insertion, coercion, or other semantic normalization |
+| Policy Decision Object | <code>https://github.com/0al-spec/agent-surface/hash/policy-decision/v1</code> | top-level <code>policy_decision_hash</code> |
+| receipt | <code>https://github.com/0al-spec/agent-surface/hash/receipt/v1</code> | top-level <code>receipt_hash</code> and <code>receipt_signatures</code> |</p>
+<p>All other members, including extension members, are part of the hashing view.
+Omitting an unknown member before hashing is therefore an integrity failure,
+not extension tolerance. A party that receives a redacted or filtered object
+MAY carry its hash as an opaque reference but MUST NOT claim to have recomputed
+it without the complete hashing view.</p>
+<p>The Action Input hash commits to the exact validated wire input and prevents a
+receipt from being attached to different input. It is distinct from the
+action-specific semantic normalization used for idempotency; JCS does not
+define default insertion, equivalence, or set ordering.</p>
+<p>The following minimal vector fixes the domain separation, wrapper, JCS, and
+encoding rules. For the Grant domain and hashing view
+<code>{&quot;grant_id&quot;:&quot;grant_123&quot;,&quot;scopes&quot;:[&quot;read&quot;]}</code>, the canonical wrapper is:</p>
+<pre><code class="language-json">{&quot;domain&quot;:&quot;https://github.com/0al-spec/agent-surface/hash/grant/v1&quot;,&quot;object&quot;:{&quot;grant_id&quot;:&quot;grant_123&quot;,&quot;scopes&quot;:[&quot;read&quot;]}}
+</code></pre>
+<p>Its hash value is:</p>
+<pre><code class="language-text">sha-256:Xbq37_fP9PBiWI3Bv7Ch0t8TV5ikJGm55MxncSeA38Y
+</code></pre>
+<p>The following manifest vector demonstrates self-field exclusion and nested JCS
+member ordering. Given this received object:</p>
+<pre><code class="language-json">{&quot;z&quot;:1,&quot;surface_hash&quot;:&quot;sha-256:Mckhl9gi8ePkXnuOJtPFNE1pe9LhilOGu1OgzxsXb8A&quot;,&quot;a&quot;:&quot;x&quot;}
+</code></pre>
+<p>the hashing view omits <code>surface_hash</code>, and the canonical wrapper is:</p>
+<pre><code class="language-json">{&quot;domain&quot;:&quot;https://github.com/0al-spec/agent-surface/hash/manifest/v1&quot;,&quot;object&quot;:{&quot;a&quot;:&quot;x&quot;,&quot;z&quot;:1}}
+</code></pre>
+<p>The recomputed value is <code>sha-256:Mckhl9gi8ePkXnuOJtPFNE1pe9LhilOGu1OgzxsXb8A</code>.
+Inputs containing duplicate members, JSON negative zero, a lone Unicode
+surrogate, or numeric input that would overflow binary64 to a non-finite value
+are negative vectors and MUST be rejected before hashing.</p>
+<p>An implementation MUST treat a supplied hash that does not match a recomputed
+hash as invalid. It MUST NOT fall back to <code>grant_id</code>, <code>surface_version</code>,
+<code>receipt_id</code>, or another mutable identifier. Hash-profile agility requires a
+future profile with a distinct identifier and domain URI; silently substituting
+a different digest or canonicalization algorithm is forbidden.</p>
 <h2 id="agent-surface-manifest-2" data-asp-heading="Agent Surface Manifest">Agent Surface Manifest</h2>
 <h3 id="discovery" data-asp-heading="Discovery">Discovery</h3>
 <p>Applications SHOULD publish a manifest at:</p>
@@ -802,6 +866,7 @@ <h3 id="required-top-level-fields" data-asp-heading="Required Top-Level Fields">
   &quot;app_id&quot;: &quot;com.example.project-tool&quot;,
   &quot;issuer&quot;: &quot;https://example.com&quot;,
   &quot;surface_version&quot;: &quot;2026-06-25&quot;,
+  &quot;surface_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
   &quot;surface_url&quot;: &quot;https://example.com/.well-known/agent-surface.json&quot;,
   &quot;auth&quot;: {},
   &quot;agent_api&quot;: {},
@@ -813,6 +878,23 @@ <h3 id="required-top-level-fields" data-asp-heading="Required Top-Level Fields">
   &quot;revocation&quot;: {}
 }
 </code></pre>
+<h3 id="surface-hash" data-asp-heading="Surface Hash">Surface Hash</h3>
+<p>Every manifest MUST contain <code>surface_hash</code> computed with the Canonical Object
+Hash Profile over the complete manifest hashing view. A runtime MUST recompute
+and verify it before using the manifest for capability matching, consent, grant
+issuance, or action validation. The authorization server MUST perform the same
+check before embedding the value in a grant.</p>
+<p><code>surface_version</code> remains the application's opaque compatibility label;
+<code>surface_hash</code> identifies the exact manifest object published under that label,
+including schema URLs but not the transitive bytes served by those URLs. A
+runtime MUST key cached surface state by issuer, app id, surface version, and
+surface hash. A publisher MUST issue a new <code>surface_version</code> whenever the
+manifest hashing view changes, including for a backward-compatible addition.
+If the same issuer, app id, and <code>surface_version</code> appears with a different
+<code>surface_hash</code>, the runtime MUST treat it as an integrity failure and MUST NOT
+silently replace the pinned object.</p>
+<p>The hash authenticates neither the issuer nor the transport. Runtimes MUST
+still enforce HTTPS, issuer and app-id binding, and any local pinning policy.</p>
 <h3 id="endpoints" data-asp-heading="Endpoints">Endpoints</h3>
 <p>The manifest MUST declare enough endpoint information for a runtime to obtain or
 validate a grant and invoke typed actions.</p>
@@ -846,6 +928,7 @@ <h3 id="example-manifest" data-asp-heading="Example Manifest">Example Manifest</
   &quot;app_id&quot;: &quot;com.example.project-tool&quot;,
   &quot;issuer&quot;: &quot;https://example.com&quot;,
   &quot;surface_version&quot;: &quot;2026-06-25&quot;,
+  &quot;surface_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
   &quot;surface_url&quot;: &quot;https://example.com/.well-known/agent-surface.json&quot;,
   &quot;compatibility&quot;: {
     &quot;min_runtime&quot;: &quot;application-runtime/0.1&quot;,
@@ -916,6 +999,7 @@ <h3 id="example-manifest" data-asp-heading="Example Manifest">Example Manifest</
       &quot;side_effect&quot;: true,
       &quot;approval&quot;: &quot;user_or_app&quot;,
       &quot;idempotency&quot;: &quot;required&quot;,
+      &quot;input_hash_profile&quot;: &quot;asp-jcs-sha-256&quot;,
       &quot;execution&quot;: {
         &quot;mode&quot;: &quot;write&quot;,
         &quot;proposal_action&quot;: &quot;comment.propose&quot;
@@ -938,13 +1022,33 @@ <h3 id="example-manifest" data-asp-heading="Example Manifest">Example Manifest</
     }
   ],
   &quot;audit&quot;: {
+    &quot;hash_profile&quot;: &quot;asp-jcs-sha-256&quot;,
     &quot;receipt_schema&quot;: &quot;https://example.com/schemas/action-receipt.schema.json&quot;,
+    &quot;receipt_signing&quot;: {
+      &quot;profiles_supported&quot;: [&quot;asp-jws-detached&quot;],
+      &quot;algorithms_supported&quot;: [&quot;ES256&quot;],
+      &quot;jwks_uri&quot;: &quot;https://example.com/.well-known/agent-surface-receipt-jwks.json&quot;
+    },
     &quot;required_fields&quot;: [
+      &quot;receipt_id&quot;,
+      &quot;receipt_type&quot;,
+      &quot;receipt_hash&quot;,
       &quot;grant_id&quot;,
+      &quot;grant_hash&quot;,
       &quot;session_id&quot;,
+      &quot;trace_id&quot;,
+      &quot;span_id&quot;,
       &quot;action_id&quot;,
+      &quot;app_id&quot;,
+      &quot;surface_version&quot;,
+      &quot;surface_hash&quot;,
+      &quot;runtime&quot;,
       &quot;actor_agent&quot;,
-      &quot;user&quot;,
+      &quot;subject&quot;,
+      &quot;idempotency_key&quot;,
+      &quot;input_hash&quot;,
+      &quot;policy_decision&quot;,
+      &quot;policy_decision_hash&quot;,
       &quot;timestamp&quot;,
       &quot;result&quot;
     ]
@@ -955,6 +1059,11 @@ <h3 id="example-manifest" data-asp-heading="Example Manifest">Example Manifest</
   }
 }
 </code></pre>
+<p><code>audit.required_fields</code> advertises the non-conditional minimum for application
+receipts and MUST NOT weaken the Receipt Requirements profile. Conditional
+fields such as <code>parent_receipt_hash</code>, <code>output_hash</code>, approval evidence, error
+classification, and required signatures remain mandatory when their receipt
+semantics require them even if they are not repeated in this list.</p>
 <h3 id="resources" data-asp-heading="Resources">Resources</h3>
 <p>Resources describe data the agent MAY read, reference, or attach to an action.</p>
 <p>Each resource SHOULD include:</p>
@@ -990,7 +1099,11 @@ <h3 id="actions" data-asp-heading="Actions">Actions</h3>
 <li>optional <code>capability_hint</code></li>
 <li><code>idempotency</code> for side-effecting actions</li>
 <li><code>receipt</code> for side-effecting actions</li>
+<li><code>input_hash_profile</code> for actions requiring receipt-linked input evidence</li>
 </ul>
+<p>An action whose receipt chain binds the exact request input MUST set
+<code>input_hash_profile</code> to <code>asp-jcs-sha-256</code>. Other profile identifiers are not
+defined by this draft.</p>
 <p>Example:</p>
 <pre><code class="language-json">{
   &quot;id&quot;: &quot;pull_request.review.submit&quot;,
@@ -999,6 +1112,7 @@ <h3 id="actions" data-asp-heading="Actions">Actions</h3>
   &quot;side_effect&quot;: true,
   &quot;approval&quot;: &quot;user_or_app&quot;,
   &quot;idempotency&quot;: &quot;required&quot;,
+  &quot;input_hash_profile&quot;: &quot;asp-jcs-sha-256&quot;,
   &quot;execution&quot;: {
     &quot;mode&quot;: &quot;write&quot;,
     &quot;proposal_action&quot;: &quot;pull_request.review.propose&quot;
@@ -1108,6 +1222,61 @@ <h2 id="approval-semantics" data-asp-heading="Approval Semantics">Approval Seman
 the approval can be linked into receipts and audited. Applications that do not
 want to accept runtime approval assertions MUST declare <code>app</code> or
 <code>runtime_and_app</code> for the affected actions.</p>
+<h3 id="policy-decision-object" data-asp-heading="Policy Decision Object">Policy Decision Object</h3>
+<p>A runtime or application that records why an action was allowed, denied, or
+paused for approval MUST use a <code>policy.decision</code> object. The object explains one
+component's final policy evaluation; it is evidence for audit and user
+explanation, not authority that another component must accept.</p>
+<pre><code class="language-json">{
+  &quot;type&quot;: &quot;policy.decision&quot;,
+  &quot;decision_id&quot;: &quot;pdec_runtime_01J2ABCDEF&quot;,
+  &quot;enforcer&quot;: {
+    &quot;type&quot;: &quot;runtime&quot;,
+    &quot;id&quot;: &quot;application_runtime_456&quot;
+  },
+  &quot;outcome&quot;: &quot;allow&quot;,
+  &quot;policy&quot;: {
+    &quot;id&quot;: &quot;local-agent-action-policy&quot;,
+    &quot;version&quot;: &quot;2026-06-25&quot;
+  },
+  &quot;reason_code&quot;: &quot;approval_satisfied&quot;,
+  &quot;matched_rules&quot;: [&quot;writes.require_local_approval&quot;],
+  &quot;safe_to_show&quot;: &quot;The requested write is within the grant and was approved.&quot;,
+  &quot;evaluated_at&quot;: &quot;2026-06-25T16:29:59Z&quot;,
+  &quot;policy_decision_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;
+}
+</code></pre>
+<p><code>type</code>, <code>decision_id</code>, <code>enforcer</code>, <code>outcome</code>, <code>policy</code>, <code>reason_code</code>,
+<code>matched_rules</code>, <code>safe_to_show</code>, <code>evaluated_at</code>, and <code>policy_decision_hash</code> are
+REQUIRED. <code>outcome</code> MUST be <code>allow</code>, <code>deny</code>, or <code>require_approval</code>.
+<code>enforcer.type</code> MUST be <code>runtime</code>, <code>application</code>, or <code>enterprise</code>; <code>enforcer.id</code>
+identifies the component whose policy was evaluated. <code>policy.id</code> and
+<code>policy.version</code> identify the applied policy snapshot. Identifiers and
+<code>safe_to_show</code> are non-empty strings. <code>matched_rules</code> is an array of unique
+strings. <code>evaluated_at</code> is an RFC 3339 UTC timestamp with the <code>Z</code> suffix.</p>
+<p><code>reason_code</code> is the primary stable machine-readable explanation. This draft
+defines <code>policy_allowed</code>, <code>approval_required</code>, <code>approval_satisfied</code>,
+<code>scope_denied</code>, <code>resource_denied</code>, <code>binding_invalid</code>, <code>limit_exceeded</code>,
+<code>local_policy_denied</code>, and <code>app_policy_denied</code>. Extensions MUST use a
+collision-resistant URI. <code>matched_rules</code> contains stable, non-secret rule
+identifiers and MAY be empty when disclosure would reveal policy internals.
+<code>safe_to_show</code> MUST be suitable for display to the affected user and MUST NOT
+contain secrets, credentials, hidden rule content, or sensitive resource data.</p>
+<p>The standard reason codes are valid only with these outcomes:</p>
+<p>| Outcome | Allowed standard reason codes |
+| --- | --- |
+| <code>allow</code> | <code>policy_allowed</code>, <code>approval_satisfied</code> |
+| <code>require_approval</code> | <code>approval_required</code> |
+| <code>deny</code> | <code>scope_denied</code>, <code>resource_denied</code>, <code>binding_invalid</code>, <code>limit_exceeded</code>, <code>local_policy_denied</code>, <code>app_policy_denied</code> |</p>
+<p>An extension reason-code specification MUST declare its allowed outcome. A
+producer and verifier MUST reject a standard or extension reason code used with
+an incompatible outcome.</p>
+<p>The producer MUST compute <code>policy_decision_hash</code> with the Canonical Object Hash
+Profile. A receipt MUST include the complete decision that directly determined
+its producer's outcome and repeat the matching hash at receipt top level. A
+runtime and application normally produce different decisions and hashes; an
+application MUST NOT treat a runtime decision as authority to widen the Agent
+Grant or bypass its own checks.</p>
 <h2 id="idempotency" data-asp-heading="Idempotency">Idempotency</h2>
 <p>Every side-effecting action MUST support idempotency.</p>
 <p>Action requests SHOULD include:</p>
@@ -1127,16 +1296,26 @@ <h2 id="idempotency" data-asp-heading="Idempotency">Idempotency</h2>
 so a retrying runtime can converge on the outcome of the first attempt.
 Applications SHOULD retain idempotency state at least for the remaining
 lifetime of the grant and SHOULD document their retention window.</p>
-<p>Applications SHOULD define the input normalization procedure per action, or use
-the declared input schema with a canonical JSON profile. A future draft is
-expected to define canonicalization requirements for signed receipts and signed
-grants.</p>
+<p>An exact retry under the Receipt Hash Chain profile MUST reuse the original
+finalized runtime receipt and the same <code>parent_receipt_hash</code>; it MUST NOT create
+a second policy receipt for the already-authorized side effect. The application
+returns the original immutable app receipt. If the same grant, action,
+idempotency key, and normalized input arrives with a different parent hash, the
+application MUST NOT repeat the side effect and MUST report
+<code>integrity_mismatch</code> rather than attaching the original result to a competing
+provenance chain.</p>
+<p>Applications SHOULD define the semantic input-normalization procedure per
+action. After that procedure, they MAY use the Canonical Object Hash Profile's
+JCS rules to obtain stable JSON bytes. JCS does not define action-specific
+normalization, default insertion, set ordering, or schema equivalence, so its
+availability does not remove that requirement.</p>
 <h2 id="agent-grant-2" data-asp-heading="Agent Grant">Agent Grant</h2>
 <h3 id="grant-object" data-asp-heading="Grant Object">Grant Object</h3>
 <p>An Agent Grant binds a user, runtime, agent, passport evidence, application,
 surface, scopes, and caveats.</p>
 <pre><code class="language-json">{
   &quot;grant_id&quot;: &quot;grant_123&quot;,
+  &quot;grant_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
   &quot;subject&quot;: {
     &quot;user&quot;: &quot;user_abc&quot;
   },
@@ -1149,7 +1328,8 @@ <h3 id="grant-object" data-asp-heading="Grant Object">Grant Object</h3>
   &quot;resource_server&quot;: {
     &quot;app_id&quot;: &quot;code.example.com&quot;,
     &quot;issuer&quot;: &quot;https://code.example.com&quot;,
-    &quot;surface_version&quot;: &quot;2026-06-25&quot;
+    &quot;surface_version&quot;: &quot;2026-06-25&quot;,
+    &quot;surface_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;
   },
   &quot;locations&quot;: [&quot;https://code.example.com/agent-actions&quot;],
   &quot;actions&quot;: [&quot;pull_request.get&quot;, &quot;comment.create&quot;],
@@ -1191,6 +1371,27 @@ <h3 id="grant-object" data-asp-heading="Grant Object">Grant Object</h3>
 runtime, agent, and passport tuple. A DPoP binding MUST additionally contain
 <code>jkt</code>; an mTLS binding MUST instead contain <code>x5t#S256</code>. Those values use the
 same encoding and semantics as the corresponding standard <code>cnf</code> members.</p>
+<h3 id="grant-hash" data-asp-heading="Grant Hash">Grant Hash</h3>
+<p>The authorization server MUST add <code>grant_hash</code> after constructing the complete
+authoritative Agent Grant, including <code>grant_id</code>, subject, delegate,
+<code>resource_server.surface_hash</code>, effective constraints, credential profile, and
+credential binding. It computes the value with the Canonical Object Hash
+Profile and persists the exact hashing view for the lifetime of the grant and
+its audit-retention period.</p>
+<p>The client MUST NOT supply <code>grant_hash</code> in an authorization request. Token and
+introspection responses MUST return it with the authoritative grant. An action
+request and every receipt under that grant MUST carry the same value. The
+application MUST compare it with current authoritative grant state and reject a
+mismatch as <code>integrity_mismatch</code>; selecting state by <code>grant_id</code> and ignoring a
+hash mismatch is forbidden.</p>
+<p>Attenuating, renewing, or otherwise changing any hashed member creates a new
+<code>grant_hash</code>, even when a deployment retains a related identifier for lifecycle
+tracking. Token rotation alone does not change <code>grant_hash</code> when the underlying
+Agent Grant object is unchanged. Parent and child grants have independent
+hashes and retain their explicit derivation linkage.</p>
+<p><code>grant_hash</code> does not prove that a grant is active, unrevoked, or within its
+remaining stateful budget. Those mutable checks still use authoritative grant
+state on every action.</p>
 <p>Numeric caveats need defined accounting. In this draft, <code>max_actions</code> counts
 side-effecting action requests accepted by the application under the grant.
 Reads and denied requests do not consume the budget, and neither do idempotent
@@ -1268,8 +1469,8 @@ <h4 id="model-c-signed-delegation-object" data-asp-heading="Model C: Signed Dele
 </ul>
 <p>Cons:</p>
 <ul>
-<li>Requires canonicalization, trust stores, signing profiles, revocation
-semantics, and stronger interop work.</li>
+<li>Requires a signed-grant profile, trust stores, signer-key lifecycle,
+revocation semantics, and stronger interop work beyond the receipt profile.</li>
 <li>Too large for the first MVP.</li>
 </ul>
 <h3 id="oauth-grant-lifecycle-profile" data-asp-heading="OAuth Grant Lifecycle Profile">OAuth Grant Lifecycle Profile</h3>
@@ -1306,7 +1507,8 @@ <h4 id="rich-authorization-request-profile" data-asp-heading="Rich Authorization
     &quot;resource_server&quot;: {
       &quot;app_id&quot;: &quot;code.example.com&quot;,
       &quot;issuer&quot;: &quot;https://code.example.com&quot;,
-      &quot;surface_version&quot;: &quot;2026-06-25&quot;
+      &quot;surface_version&quot;: &quot;2026-06-25&quot;,
+      &quot;surface_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;
     },
     &quot;scopes&quot;: [&quot;pull_request.read&quot;, &quot;pull_request.comment&quot;],
     &quot;constraints&quot;: {
@@ -1332,7 +1534,8 @@ <h4 id="rich-authorization-request-profile" data-asp-heading="Rich Authorization
 <code>credential_profile</code>, and <code>audit</code> are REQUIRED.</li>
 <li><code>delegate</code> MUST contain <code>runtime</code>, <code>agent</code>, and <code>passport_hash</code>; it MAY contain
 <code>passport_ref</code>.</li>
-<li><code>resource_server</code> MUST contain <code>app_id</code>, <code>issuer</code>, and <code>surface_version</code>.</li>
+<li><code>resource_server</code> MUST contain <code>app_id</code>, <code>issuer</code>, <code>surface_version</code>, and the
+verified <code>surface_hash</code>.</li>
 <li><code>constraints</code> MUST contain <code>expires_at</code>; other fields use the semantics of the
 Agent Grant object.</li>
 <li><code>credential_profile</code> MUST be <code>compatibility_bearer</code> or <code>proof_bound</code> and maps
@@ -1343,16 +1546,23 @@ <h4 id="rich-authorization-request-profile" data-asp-heading="Rich Authorization
 invoked action MUST be a member. The authorization applies to the product of
 the granted actions, locations, scopes, and resource filters; every allowed
 combination MUST be published by the surface and semantically compatible.</li>
-<li><code>grant_id</code>, <code>subject</code>, and <code>credential_binding</code> MUST NOT be supplied by the
-client in an authorization request; they are authorization-server output.</li>
+<li><code>grant_id</code>, <code>grant_hash</code>, <code>subject</code>, and <code>credential_binding</code> MUST NOT be
+supplied by the client in an authorization request; they are
+authorization-server output.</li>
+<li>A client MAY request an <code>audit.receipt_signing</code> profile and signer roles, but
+it MUST NOT supply authoritative <code>signer_keys</code>. Before issuance, the
+authorization server MUST reject a request containing those entries, derive
+them from issuer metadata and the authenticated runtime key registration,
+and include the resulting pins in <code>grant_hash</code>.</li>
 <li>The request MUST NOT supply <code>subject.user</code> or another asserted user identity;
 the authorization server derives the subject from its authenticated user
 session or, at the token endpoint, from the validated <code>subject_token</code>.</li>
 </ul>
 <p>The authorization server MUST reject unknown fields, unknown action or scope
 values, a mismatched <code>resource_server.app_id</code> or
-<code>resource_server.surface_version</code>, an unverified passport hash, or constraints
-that are invalid for the published surface. It MUST use the RFC 9396
+<code>resource_server.surface_version</code>, a mismatched <code>resource_server.surface_hash</code>,
+an unverified passport hash, or constraints that are invalid for the published
+surface. It MUST use the RFC 9396
 <code>invalid_authorization_details</code> error for malformed or unsupported Agent Grant
 authorization details.</p>
 <p>Authorization Code use of this profile MUST use PKCE with the <code>S256</code> challenge
@@ -1379,7 +1589,7 @@ <h4 id="rich-authorization-request-profile" data-asp-heading="Rich Authorization
 <p>The token response MUST return the granted <code>authorization_details</code> as required
 by RFC 9396. For this type, the returned object MUST be enriched with the
 authoritative <code>grant_id</code>, <code>subject</code>, delegate binding, effective constraints,
-and <code>credential_binding</code> assigned by the authorization server. The
+<code>credential_binding</code>, and <code>grant_hash</code> assigned by the authorization server. The
 authorization server and resource server MUST retain or receive the same
 granted object for later action verification and introspection.</p>
 <h4 id="oauth-token-exchange-profile" data-asp-heading="OAuth Token Exchange Profile">OAuth Token Exchange Profile</h4>
@@ -1446,8 +1656,8 @@ <h4 id="oauth-token-exchange-profile" data-asp-heading="OAuth Token Exchange Pro
 authorization server MUST treat semantically equivalent exchanges with the
 same source authorization, client and delegate tuple, target resource,
 normalized Agent Grant details, and proof-binding key as idempotent: it MUST
-reuse the same <code>grant_id</code> and accounting state, although it MAY rotate the
-access-token representation.</p>
+reuse the same <code>grant_id</code>, <code>grant_hash</code>, and accounting state, although it MAY
+rotate the access-token representation.</p>
 <p>Example successful response:</p>
 <pre><code class="language-json">{
   &quot;access_token&quot;: &quot;&lt;opaque-grant-credential&gt;&quot;,
@@ -1456,6 +1666,7 @@ <h4 id="oauth-token-exchange-profile" data-asp-heading="OAuth Token Exchange Pro
   &quot;expires_in&quot;: 1800,
   &quot;scope&quot;: &quot;pull_request.read pull_request.comment&quot;,
   &quot;grant_id&quot;: &quot;grant_123&quot;,
+  &quot;grant_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
   &quot;authorization_details&quot;: [
     {
       &quot;type&quot;: &quot;https://github.com/0al-spec/agent-surface/authorization-details/agent-grant&quot;,
@@ -1473,7 +1684,8 @@ <h4 id="oauth-token-exchange-profile" data-asp-heading="OAuth Token Exchange Pro
       &quot;resource_server&quot;: {
         &quot;app_id&quot;: &quot;code.example.com&quot;,
         &quot;issuer&quot;: &quot;https://code.example.com&quot;,
-        &quot;surface_version&quot;: &quot;2026-06-25&quot;
+        &quot;surface_version&quot;: &quot;2026-06-25&quot;,
+        &quot;surface_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;
       },
       &quot;scopes&quot;: [&quot;pull_request.read&quot;, &quot;pull_request.comment&quot;],
       &quot;constraints&quot;: {
@@ -1495,20 +1707,26 @@ <h4 id="oauth-token-exchange-profile" data-asp-heading="OAuth Token Exchange Pro
         &quot;local_receipt&quot;: &quot;required&quot;,
         &quot;app_receipt&quot;: &quot;required&quot;
       },
-      &quot;grant_id&quot;: &quot;grant_123&quot;
+      &quot;grant_id&quot;: &quot;grant_123&quot;,
+      &quot;grant_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;
     }
   ]
 }
 </code></pre>
 <p>The response MUST include <code>access_token</code>, <code>issued_token_type</code>, <code>token_type</code>,
-<code>expires_in</code>, <code>grant_id</code>, the exact <code>scope</code> projection defined above, and the
-granted <code>authorization_details</code>. This also satisfies the RFC 8693 requirement to
-return <code>scope</code> when the issued scope differs from the request. The <code>token_type</code>
-and method-specific credential confirmation data MUST match the selected
+<code>expires_in</code>, <code>grant_id</code>, <code>grant_hash</code>, the exact <code>scope</code> projection defined
+above, and the granted <code>authorization_details</code>. This also satisfies the RFC
+8693 requirement to return <code>scope</code> when the issued scope differs from the
+request. The <code>token_type</code> and method-specific credential confirmation data MUST
+match the selected
 credential profile and the binding established at the token endpoint. A
 refresh token SHOULD NOT be issued by default; if one is issued, it MUST
 preserve the tuple binding, attenuation, and revocation linkage of the Agent
 Grant and follow RFC 9700 refresh-token replay protections.</p>
+<p>Top-level <code>grant_id</code> and <code>grant_hash</code> MUST exactly match the same members in the
+sole returned Agent Grant authorization-details object. The client MUST reject
+the token response if either projection is absent or mismatched; it MUST NOT
+select one representation and ignore the other.</p>
 <p>Token responses containing a Grant Credential or its authorization details MUST
 use <code>Cache-Control: no-store</code> and <code>Pragma: no-cache</code>.</p>
 <h4 id="grant-introspection-profile" data-asp-heading="Grant Introspection Profile">Grant Introspection Profile</h4>
@@ -1527,7 +1745,7 @@ <h4 id="grant-introspection-profile" data-asp-heading="Grant Introspection Profi
 outside the caller's authority.</p>
 <p>For an active Grant Credential, the response MUST include the RFC 7662 fields
 <code>active</code>, <code>client_id</code>, <code>scope</code>, <code>token_type</code>, <code>exp</code>, <code>iat</code>, <code>sub</code>, <code>aud</code>, and
-<code>iss</code>, plus the ASP fields <code>grant_id</code>, <code>resource_server</code>, <code>delegate</code>,
+<code>iss</code>, plus the ASP fields <code>grant_id</code>, <code>grant_hash</code>, <code>resource_server</code>, <code>delegate</code>,
 <code>constraints</code>, <code>credential_binding</code>, and <code>authorization_details</code>. An active
 proof-bound credential MUST additionally include the method-specific standard
 <code>cnf</code> confirmation member. The <code>sub</code> value SHOULD be a stable app-scoped
@@ -1536,10 +1754,13 @@ <h4 id="grant-introspection-profile" data-asp-heading="Grant Introspection Profi
 <code>client_id</code>.</p>
 <p>The <code>authorization_details</code> member MUST contain the granted Agent Grant object,
 filtered only to data the authenticated caller may receive. Top-level <code>sub</code>,
-<code>grant_id</code>, <code>resource_server</code>, <code>delegate</code>, <code>constraints</code>, and
+<code>grant_id</code>, <code>grant_hash</code>, <code>resource_server</code>, <code>delegate</code>, <code>constraints</code>, and
 <code>credential_binding</code> are projections of that object and MUST match it; <code>sub</code>
 corresponds to <code>subject.user</code>. A resource server MUST treat a mismatch as an
-invalid grant proof rather than selecting one representation.</p>
+invalid grant proof rather than selecting one representation. A filtered
+response still MUST carry <code>grant_hash</code> as an opaque authoritative commitment,
+but a caller MUST NOT claim to have recomputed it without the complete Grant
+Object.</p>
 <p>For DPoP, <code>cnf</code> MUST contain <code>jkt</code> as specified by RFC 9449; for mTLS, it MUST
 contain <code>x5t#S256</code> as specified by RFC 8705. The confirmation value MUST match
 the method-specific value in the Agent Grant <code>credential_binding</code>. The resource
@@ -1559,10 +1780,12 @@ <h4 id="grant-introspection-profile" data-asp-heading="Grant Introspection Profi
     &quot;jkt&quot;: &quot;&lt;base64url-thumbprint&gt;&quot;
   },
   &quot;grant_id&quot;: &quot;grant_123&quot;,
+  &quot;grant_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
   &quot;resource_server&quot;: {
     &quot;app_id&quot;: &quot;code.example.com&quot;,
     &quot;issuer&quot;: &quot;https://code.example.com&quot;,
-    &quot;surface_version&quot;: &quot;2026-06-25&quot;
+    &quot;surface_version&quot;: &quot;2026-06-25&quot;,
+    &quot;surface_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;
   },
   &quot;delegate&quot;: {
     &quot;runtime&quot;: &quot;application_runtime_456&quot;,
@@ -1601,7 +1824,8 @@ <h4 id="grant-introspection-profile" data-asp-heading="Grant Introspection Profi
       &quot;resource_server&quot;: {
         &quot;app_id&quot;: &quot;code.example.com&quot;,
         &quot;issuer&quot;: &quot;https://code.example.com&quot;,
-        &quot;surface_version&quot;: &quot;2026-06-25&quot;
+        &quot;surface_version&quot;: &quot;2026-06-25&quot;,
+        &quot;surface_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;
       },
       &quot;scopes&quot;: [&quot;pull_request.read&quot;, &quot;pull_request.comment&quot;],
       &quot;constraints&quot;: {
@@ -1623,7 +1847,8 @@ <h4 id="grant-introspection-profile" data-asp-heading="Grant Introspection Profi
         &quot;local_receipt&quot;: &quot;required&quot;,
         &quot;app_receipt&quot;: &quot;required&quot;
       },
-      &quot;grant_id&quot;: &quot;grant_123&quot;
+      &quot;grant_id&quot;: &quot;grant_123&quot;,
+      &quot;grant_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;
     }
   ]
 }
@@ -1719,6 +1944,10 @@ <h3 id="grant-verification" data-asp-heading="Grant Verification">Grant Verifica
 <p>Applications MUST verify every action against grant state:</p>
 <ul>
 <li>grant exists and is active</li>
+<li>recomputed <code>grant_hash</code> matches both the presented action context and current
+authoritative Grant Object</li>
+<li><code>resource_server.surface_hash</code> matches the retained, verified manifest
+snapshot used to interpret the action and its schemas</li>
 <li>grant credential or proof is valid</li>
 <li>grant is bound to the user</li>
 <li>grant is bound to the runtime</li>
@@ -1745,6 +1974,8 @@ <h3 id="grant-verification" data-asp-heading="Grant Verification">Grant Verifica
 <p>Runtimes SHOULD verify:</p>
 <ul>
 <li>grant is active</li>
+<li><code>grant_hash</code> matches the complete grant returned at issuance or introspection</li>
+<li><code>surface_hash</code> matches the verified manifest snapshot pinned for that grant</li>
 <li>local user has not revoked the app, runtime, or agent</li>
 <li>Agent Passport is valid</li>
 <li>requested action is compatible with the Agent Passport capability set</li>
@@ -1789,6 +2020,54 @@ <h2 id="capability-matching" data-asp-heading="Capability Matching">Capability M
 <li>expected sandbox constraints</li>
 </ul>
 <p>The matching result is shown to the user before grant issuance.</p>
+<h2 id="observability-context" data-asp-heading="Observability Context">Observability Context</h2>
+<p>ASP uses W3C Trace Context for cross-component diagnostic correlation. An ASP
+session, action, event, and receipt MAY participate in a distributed trace, but
+trace context is never authorization, identity, idempotency, or proof that two
+objects belong to the same grant.</p>
+<p>JSON envelopes that carry observability context use <code>trace_id</code> and <code>span_id</code>.
+<code>trace_id</code> MUST be 32 lowercase hexadecimal characters representing 16 bytes
+and MUST NOT be all zero. <code>span_id</code> MUST be 16 lowercase hexadecimal characters
+representing 8 bytes and MUST NOT be all zero. These are projections of the W3C
+<code>trace-id</code> and <code>parent-id</code> formats. <code>session_id</code> remains the ASP lifecycle and
+accounting identifier and MUST continue to be validated independently.</p>
+<p>When an implementation claims the Application Runtime or Receipt-Producing
+profile, its <code>session.start</code>, <code>action.request</code>, <code>action.result</code>, and receipt
+envelopes MUST carry <code>session_id</code>, <code>trace_id</code>, and the producer's <code>span_id</code> as
+shown below. Each runtime and application MUST record the identifiers from the
+envelope or receipt it produces in the corresponding local log entry so those
+logs can be joined without parsing human-readable messages. Trace and session
+ids can match across components while each producer records its own span id.
+This draft defines correlation fields, not a telemetry export protocol or
+vendor backend.</p>
+<p>For an HTTP binding, a component carrying valid ASP observability context MUST
+send <code>traceparent</code>. A component participating in an incoming W3C trace MUST
+propagate <code>traceparent</code> and <code>tracestate</code> according to W3C Trace Context, subject
+to its defined trust-boundary privacy policy. It preserves a valid incoming
+<code>trace_id</code>, creates a fresh <code>span_id</code> for its own operation, and propagates that
+child context downstream. A receipt records the span of the component that
+produced it. Runtime and application receipts for one action therefore normally
+share <code>trace_id</code> and <code>session_id</code> but have different <code>span_id</code> values.</p>
+<p>An intermediary is allowed to create another span, so a receiver MUST NOT
+require the JSON <code>span_id</code> to equal the <code>parent-id</code> in the HTTP header after
+intermediation. For local processing, a valid <code>traceparent</code> takes precedence
+over the JSON projection. If no valid header exists and a verified parent
+receipt is available, the receiver continues the parent receipt's <code>trace_id</code>
+with a new span. Otherwise it uses a valid JSON <code>trace_id</code> or starts a new
+trace, in that order.</p>
+<p>If the selected processing trace differs from a verified parent receipt's
+trace because an intermediary or trust boundary restarted it, the child receipt
+MUST include <code>linked_trace_id</code> equal to the parent <code>trace_id</code>. Without such a
+documented restart, parent and child receipts MUST use the same <code>trace_id</code>.
+<code>linked_trace_id</code> uses the same format as <code>trace_id</code> and is included in the
+receipt hash. Invalid or conflicting trace context MUST NOT cause an otherwise
+unauthorized action to be accepted, and it MUST NOT bypass grant, session, or
+receipt-link verification.</p>
+<p>Trace identifiers MUST be generated without embedding user, agent, resource,
+tenant, or policy semantics. Producers MUST apply the same disclosure and
+retention controls to <code>tracestate</code> and correlated telemetry as to other audit
+metadata. An Agent Adapter preserves <code>session_id</code> and a valid <code>trace_id</code> across
+its boundary and creates a new <code>span_id</code> for each adapter operation.</p>
 <h2 id="sessions-and-actions" data-asp-heading="Sessions and Actions">Sessions and Actions</h2>
 <h3 id="session-start" data-asp-heading="Session Start">Session Start</h3>
 <p>Once a grant exists, an application or runtime MAY start a session.</p>
@@ -1796,11 +2075,15 @@ <h3 id="session-start" data-asp-heading="Session Start">Session Start</h3>
   &quot;type&quot;: &quot;session.start&quot;,
   &quot;payload&quot;: {
     &quot;session_id&quot;: &quot;sess_456&quot;,
+    &quot;trace_id&quot;: &quot;4bf92f3577b34da6a3ce929d0e0e4736&quot;,
+    &quot;span_id&quot;: &quot;a3ce929d0e0e4736&quot;,
     &quot;grant_id&quot;: &quot;grant_123&quot;,
+    &quot;grant_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
     &quot;agent_id&quot;: &quot;local_agent_789&quot;,
     &quot;surface&quot;: {
       &quot;app_id&quot;: &quot;code.example.com&quot;,
-      &quot;surface_version&quot;: &quot;2026-06-25&quot;
+      &quot;surface_version&quot;: &quot;2026-06-25&quot;,
+      &quot;surface_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;
     },
     &quot;task&quot;: {
       &quot;kind&quot;: &quot;pull_request.review&quot;,
@@ -1823,6 +2106,10 @@ <h3 id="action-request" data-asp-heading="Action Request">Action Request</h3>
 presented grant. Otherwise a valid grant credential could be replayed against
 sessions created under other grants, corrupting session accounting and receipt
 linkage.</p>
+<p>The application MUST also verify that body <code>grant_hash</code> matches the complete
+authoritative grant selected by the credential and that <code>surface_hash</code> matches
+the manifest snapshot pinned by that grant. These hashes are correlation and
+integrity commitments, not substitutes for the HTTP authorization proof.</p>
 <p>If both the <code>Idempotency-Key</code> header and the body <code>idempotency_key</code> field are
 present, they MUST match, and the application MUST reject a mismatch as
 <code>schema_invalid</code>. Accepting a mismatched request and picking either value
@@ -1833,6 +2120,7 @@ <h3 id="action-request" data-asp-heading="Action Request">Action Request</h3>
 Host: example.com
 Authorization: DPoP &lt;grant-credential&gt;
 DPoP: &lt;signed-proof&gt;
+traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-b7ad6b7169203331-01
 Idempotency-Key: idem_01HX7DS8AC6G9
 Content-Type: application/json
 </code></pre>
@@ -1840,9 +2128,15 @@ <h3 id="action-request" data-asp-heading="Action Request">Action Request</h3>
   &quot;type&quot;: &quot;action.request&quot;,
   &quot;payload&quot;: {
     &quot;session_id&quot;: &quot;sess_456&quot;,
+    &quot;trace_id&quot;: &quot;4bf92f3577b34da6a3ce929d0e0e4736&quot;,
+    &quot;span_id&quot;: &quot;b7ad6b7169203331&quot;,
     &quot;grant_id&quot;: &quot;grant_123&quot;,
+    &quot;grant_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
+    &quot;surface_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
     &quot;action_id&quot;: &quot;comment.create&quot;,
     &quot;idempotency_key&quot;: &quot;idem_01HX7DS8AC6G9&quot;,
+    &quot;parent_receipt_hash&quot;: &quot;sha-256:&lt;runtime-receipt-digest&gt;&quot;,
+    &quot;input_hash&quot;: &quot;sha-256:&lt;action-input-digest&gt;&quot;,
     &quot;input&quot;: {
       &quot;repository&quot;: &quot;example-org/example-repo&quot;,
       &quot;pull_request&quot;: 13,
@@ -1854,12 +2148,32 @@ <h3 id="action-request" data-asp-heading="Action Request">Action Request</h3>
 <p>The request's proof material MUST use the authorization mechanism selected by
 the credential-binding profile. For example, a DPoP-bound credential carries a
 DPoP proof in the <code>DPoP</code> header as defined by RFC 9449.</p>
+<p>Before forwarding a side-effecting action, the runtime MUST finalize its
+runtime receipt and place that receipt's <code>receipt_hash</code> in
+<code>parent_receipt_hash</code>. When the application requires the runtime receipt
+content, the runtime MUST either submit the complete receipt through the
+manifest <code>agent_api.receipt_url</code> before the action or carry it inline through a
+declared action-request extension. The application MUST recompute the supplied
+receipt and policy-decision hashes before treating the receipt as verified. A
+bare parent hash is correlation evidence only and is insufficient when app
+policy requires verification of the runtime decision.</p>
+<p>For an action requiring runtime receipt evidence, the action declaration MUST
+set <code>input_hash_profile</code> to <code>asp-jcs-sha-256</code>. The runtime and application MUST
+compute the Action Input hash over the exact validated wire <code>input</code> and require
+equality with both the action request and verified parent runtime receipt. A
+receipt for one input MUST NOT be attached to a different input even when the
+grant, action id, and idempotency key match. The semantic normalization used
+for idempotency remains a separate action contract.</p>
 <h3 id="action-response" data-asp-heading="Action Response">Action Response</h3>
 <pre><code class="language-json">{
   &quot;type&quot;: &quot;action.result&quot;,
   &quot;payload&quot;: {
     &quot;session_id&quot;: &quot;sess_456&quot;,
+    &quot;trace_id&quot;: &quot;4bf92f3577b34da6a3ce929d0e0e4736&quot;,
+    &quot;span_id&quot;: &quot;00f067aa0ba902b7&quot;,
     &quot;grant_id&quot;: &quot;grant_123&quot;,
+    &quot;grant_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
+    &quot;surface_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
     &quot;action_id&quot;: &quot;comment.create&quot;,
     &quot;idempotency_key&quot;: &quot;idem_01HX7DS8AC6G9&quot;,
     &quot;result&quot;: &quot;success&quot;,
@@ -1868,7 +2182,8 @@ <h3 id="action-response" data-asp-heading="Action Response">Action Response</h3>
       &quot;id&quot;: &quot;comment_789&quot;,
       &quot;url&quot;: &quot;https://code.example.com/example-org/example-repo/pull/13#discussion_r...&quot;
     },
-    &quot;receipt_id&quot;: &quot;receipt_abc&quot;
+    &quot;receipt_id&quot;: &quot;receipt_app_abc&quot;,
+    &quot;receipt_hash&quot;: &quot;sha-256:&lt;app-receipt-digest&gt;&quot;
   }
 }
 </code></pre>
@@ -1884,12 +2199,17 @@ <h3 id="proposal-flow" data-asp-heading="Proposal Flow">Proposal Flow</h3>
 <p>This is the RECOMMENDED default for early integrations.</p>
 <h2 id="receipts" data-asp-heading="Receipts">Receipts</h2>
 <h3 id="receipt-requirements" data-asp-heading="Receipt Requirements">Receipt Requirements</h3>
-<p>Receipts SHOULD include:</p>
+<p>Receipts produced under the Receipt-Producing Application profile MUST include:</p>
 <ul>
 <li>receipt id</li>
 <li>receipt type</li>
+<li>receipt hash</li>
 <li>grant id</li>
+<li>grant hash</li>
 <li>session id</li>
+<li>trace id</li>
+<li>producer span id</li>
+<li>linked parent trace id when a trust boundary restarted tracing</li>
 <li>action id</li>
 <li>app id</li>
 <li>user id or stable pseudonymous user reference</li>
@@ -1897,6 +2217,8 @@ <h3 id="receipt-requirements" data-asp-heading="Receipt Requirements">Receipt Re
 <li>agent id</li>
 <li>Agent Passport hash</li>
 <li>surface version</li>
+<li>surface hash</li>
+<li>policy decision and policy decision hash</li>
 <li>input hash</li>
 <li>output hash</li>
 <li>approval reference</li>
@@ -1905,6 +2227,40 @@ <h3 id="receipt-requirements" data-asp-heading="Receipt Requirements">Receipt Re
 <li>result</li>
 <li>error classification when failed</li>
 </ul>
+<p>Fields that do not apply to the recorded outcome, such as <code>output_hash</code> for a
+denial before execution, MAY be omitted. The identity, authority, trace,
+decision, and result fields that do apply MUST be present and internally
+consistent.</p>
+<h3 id="receipt-hash-chain" data-asp-heading="Receipt Hash Chain">Receipt Hash Chain</h3>
+<p>Every runtime and application receipt MUST contain <code>receipt_hash</code> computed with
+the Canonical Object Hash Profile. A root receipt omits
+<code>parent_receipt_hash</code>; it MUST NOT encode the missing parent as <code>null</code>. A
+non-root receipt contains exactly one <code>parent_receipt_hash</code>, which is included
+in its own hashing view.</p>
+<p>For a runtime-mediated side-effecting action whose grant requires a runtime
+receipt, the application receipt MUST use the verified runtime
+<code>receipt_hash</code> from the action request as its <code>parent_receipt_hash</code>. A later
+runtime receipt MAY use the returned application <code>receipt_hash</code> as its parent.
+This single-parent model permits branches but does not represent multi-parent
+causal joins; a future profile may define a DAG representation.</p>
+<p>A parent and child receipt for one action MUST carry identical <code>grant_hash</code>,
+<code>surface_hash</code>, <code>session_id</code>, <code>action_id</code>, <code>idempotency_key</code>, and <code>input_hash</code>.
+They also carry the same <code>trace_id</code> unless the child records a trust-boundary
+restart with <code>linked_trace_id</code> equal to the parent's <code>trace_id</code>.
+Their <code>span_id</code> and <code>policy_decision_hash</code> normally differ because each producer
+records its own operation and decision. A consumer MUST recompute every
+available object hash, verify these invariants, reject a cycle, and stop at any
+missing or mismatched parent. Reusing one <code>receipt_id</code> for different
+<code>receipt_hash</code> values is an invalid receipt conflict.</p>
+<p>The runtime makes its parent receipt available to the application through the
+<code>agent_api.receipt_url</code> or an explicitly declared inline action-request
+extension, as defined in Action Request. The application MUST NOT claim a
+verified parent link when it received only an unverified hash and its policy
+requires the parent content.</p>
+<p>A hash chain is tamper-evident only relative to a trusted stored chain head or
+authenticated signature. A party that can replace an entire unsigned chain can
+recompute every hash. Receipt hashes and links therefore do not authenticate a
+producer and do not authorize an action.</p>
 <h3 id="runtime-receipt" data-asp-heading="Runtime Receipt">Runtime Receipt</h3>
 <p>A runtime receipt records what the runtime observed and enforced, such as agent
 intent, local policy decisions, local approvals, denials, and runtime-side
@@ -1912,9 +2268,16 @@ <h3 id="runtime-receipt" data-asp-heading="Runtime Receipt">Runtime Receipt</h3>
 <pre><code class="language-json">{
   &quot;receipt_id&quot;: &quot;receipt_runtime_abc&quot;,
   &quot;receipt_type&quot;: &quot;runtime&quot;,
+  &quot;receipt_hash&quot;: &quot;sha-256:&lt;runtime-receipt-digest&gt;&quot;,
   &quot;grant_id&quot;: &quot;grant_123&quot;,
+  &quot;grant_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
   &quot;session_id&quot;: &quot;sess_456&quot;,
+  &quot;trace_id&quot;: &quot;4bf92f3577b34da6a3ce929d0e0e4736&quot;,
+  &quot;span_id&quot;: &quot;b7ad6b7169203331&quot;,
   &quot;action_id&quot;: &quot;comment.create&quot;,
+  &quot;app_id&quot;: &quot;code.example.com&quot;,
+  &quot;surface_version&quot;: &quot;2026-06-25&quot;,
+  &quot;surface_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
   &quot;actor_agent&quot;: {
     &quot;agent_id&quot;: &quot;local_agent_789&quot;,
     &quot;passport_hash&quot;: &quot;sha256:...&quot;
@@ -1926,13 +2289,32 @@ <h3 id="runtime-receipt" data-asp-heading="Runtime Receipt">Runtime Receipt</h3>
     &quot;user&quot;: &quot;user_abc&quot;
   },
   &quot;idempotency_key&quot;: &quot;idem_01HX7DS8AC6G9&quot;,
-  &quot;input_hash&quot;: &quot;sha256:...&quot;,
+  &quot;input_hash&quot;: &quot;sha-256:&lt;action-input-digest&gt;&quot;,
+  &quot;policy_decision_hash&quot;: &quot;sha-256:&lt;runtime-policy-decision-digest&gt;&quot;,
+  &quot;policy_decision&quot;: {
+    &quot;type&quot;: &quot;policy.decision&quot;,
+    &quot;decision_id&quot;: &quot;pdec_runtime_01J2ABCDEF&quot;,
+    &quot;enforcer&quot;: {
+      &quot;type&quot;: &quot;runtime&quot;,
+      &quot;id&quot;: &quot;application_runtime_456&quot;
+    },
+    &quot;outcome&quot;: &quot;allow&quot;,
+    &quot;policy&quot;: {
+      &quot;id&quot;: &quot;local-agent-action-policy&quot;,
+      &quot;version&quot;: &quot;2026-06-25&quot;
+    },
+    &quot;reason_code&quot;: &quot;approval_satisfied&quot;,
+    &quot;matched_rules&quot;: [&quot;writes.require_local_approval&quot;],
+    &quot;safe_to_show&quot;: &quot;The requested write is within the grant and was approved.&quot;,
+    &quot;evaluated_at&quot;: &quot;2026-06-25T16:29:59Z&quot;,
+    &quot;policy_decision_hash&quot;: &quot;sha-256:&lt;runtime-policy-decision-digest&gt;&quot;
+  },
   &quot;approved_by&quot;: {
     &quot;type&quot;: &quot;runtime_user_approval&quot;,
     &quot;approval_id&quot;: &quot;appr_123&quot;
   },
   &quot;timestamp&quot;: &quot;2026-06-25T16:30:00Z&quot;,
-  &quot;result&quot;: &quot;forwarded_to_app&quot;
+  &quot;result&quot;: &quot;authorized_for_forwarding&quot;
 }
 </code></pre>
 <h3 id="app-receipt" data-asp-heading="App Receipt">App Receipt</h3>
@@ -1941,11 +2323,17 @@ <h3 id="app-receipt" data-asp-heading="App Receipt">App Receipt</h3>
 <pre><code class="language-json">{
   &quot;receipt_id&quot;: &quot;receipt_app_abc&quot;,
   &quot;receipt_type&quot;: &quot;app&quot;,
+  &quot;receipt_hash&quot;: &quot;sha-256:&lt;app-receipt-digest&gt;&quot;,
+  &quot;parent_receipt_hash&quot;: &quot;sha-256:&lt;runtime-receipt-digest&gt;&quot;,
   &quot;grant_id&quot;: &quot;grant_123&quot;,
+  &quot;grant_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
   &quot;session_id&quot;: &quot;sess_456&quot;,
+  &quot;trace_id&quot;: &quot;4bf92f3577b34da6a3ce929d0e0e4736&quot;,
+  &quot;span_id&quot;: &quot;00f067aa0ba902b7&quot;,
   &quot;action_id&quot;: &quot;comment.create&quot;,
   &quot;app_id&quot;: &quot;code.example.com&quot;,
   &quot;surface_version&quot;: &quot;2026-06-25&quot;,
+  &quot;surface_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
   &quot;runtime&quot;: {
     &quot;runtime_id&quot;: &quot;application_runtime_456&quot;
   },
@@ -1957,8 +2345,27 @@ <h3 id="app-receipt" data-asp-heading="App Receipt">App Receipt</h3>
     &quot;user&quot;: &quot;user_abc&quot;
   },
   &quot;idempotency_key&quot;: &quot;idem_01HX7DS8AC6G9&quot;,
-  &quot;input_hash&quot;: &quot;sha256:...&quot;,
+  &quot;input_hash&quot;: &quot;sha-256:&lt;action-input-digest&gt;&quot;,
   &quot;output_hash&quot;: &quot;sha256:...&quot;,
+  &quot;policy_decision_hash&quot;: &quot;sha-256:&lt;app-policy-decision-digest&gt;&quot;,
+  &quot;policy_decision&quot;: {
+    &quot;type&quot;: &quot;policy.decision&quot;,
+    &quot;decision_id&quot;: &quot;pdec_app_01J2ABCDEG&quot;,
+    &quot;enforcer&quot;: {
+      &quot;type&quot;: &quot;application&quot;,
+      &quot;id&quot;: &quot;code.example.com&quot;
+    },
+    &quot;outcome&quot;: &quot;allow&quot;,
+    &quot;policy&quot;: {
+      &quot;id&quot;: &quot;agent-action-policy&quot;,
+      &quot;version&quot;: &quot;2026-06-25&quot;
+    },
+    &quot;reason_code&quot;: &quot;policy_allowed&quot;,
+    &quot;matched_rules&quot;: [&quot;grant.active&quot;, &quot;action.comment.create&quot;],
+    &quot;safe_to_show&quot;: &quot;The application accepted the authorized comment action.&quot;,
+    &quot;evaluated_at&quot;: &quot;2026-06-25T16:30:00Z&quot;,
+    &quot;policy_decision_hash&quot;: &quot;sha-256:&lt;app-policy-decision-digest&gt;&quot;
+  },
   &quot;approved_by&quot;: {
     &quot;type&quot;: &quot;runtime_user_approval&quot;,
     &quot;approval_id&quot;: &quot;appr_123&quot;
@@ -1968,18 +2375,127 @@ <h3 id="app-receipt" data-asp-heading="App Receipt">App Receipt</h3>
     &quot;id&quot;: &quot;comment_789&quot;
   },
   &quot;timestamp&quot;: &quot;2026-06-25T16:30:00Z&quot;,
-  &quot;result&quot;: &quot;success&quot;,
-  &quot;links&quot;: {
-    &quot;runtime_receipt_hash&quot;: &quot;sha256:...&quot;
+  &quot;result&quot;: &quot;success&quot;
+}
+</code></pre>
+<h3 id="receipt-signing-profile" data-asp-heading="Receipt Signing Profile">Receipt Signing Profile</h3>
+<p>The optional <code>asp-jws-detached</code> profile lets an application, runtime, or both
+authenticate a receipt without changing <code>receipt_hash</code>. The base MVP permits
+unsigned receipts. Unsigned means that <code>receipt_signatures</code> is absent; it MUST
+NOT be represented by a JWS using <code>alg: none</code>.</p>
+<p>A grant that requires both runtime and application signatures carries:</p>
+<pre><code class="language-json">{
+  &quot;audit&quot;: {
+    &quot;local_receipt&quot;: &quot;required&quot;,
+    &quot;app_receipt&quot;: &quot;required&quot;,
+    &quot;receipt_signing&quot;: {
+      &quot;profile&quot;: &quot;asp-jws-detached&quot;,
+      &quot;required_signers&quot;: [&quot;runtime&quot;, &quot;application&quot;],
+      &quot;signer_keys&quot;: [
+        {
+          &quot;role&quot;: &quot;runtime&quot;,
+          &quot;kid&quot;: &quot;runtime-receipt-key-2026-01&quot;,
+          &quot;jwk_thumbprint&quot;: &quot;&lt;base64url-rfc7638-sha256-thumbprint&gt;&quot;
+        },
+        {
+          &quot;role&quot;: &quot;application&quot;,
+          &quot;kid&quot;: &quot;app-receipt-key-2026-01&quot;,
+          &quot;jwk_thumbprint&quot;: &quot;&lt;base64url-rfc7638-sha256-thumbprint&gt;&quot;
+        }
+      ]
+    }
+  }
+}
+</code></pre>
+<p>For this profile, the signing view is the complete receipt with
+<code>receipt_signatures</code> omitted and with <code>receipt_hash</code> retained. The signer wraps
+that view as an object with <code>domain</code> equal to
+<code>https://github.com/0al-spec/agent-surface/signature/receipt/v1</code> and <code>receipt</code>
+equal to the signing view, then serializes the wrapper with RFC 8785 JCS. Those
+UTF-8 bytes are the JWS payload.</p>
+<p>The receipt carries a detached General JWS JSON Serialization as follows. The
+<code>payload</code> member is omitted according to RFC 7515 Appendix F; the verifier
+reconstructs it from the canonical signing view. Ordinary JWS base64url payload
+encoding is used, so the RFC 7797 <code>b64</code> extension MUST NOT be present.</p>
+<p>The decoded protected header for a runtime receipt has this form:</p>
+<pre><code class="language-json">{
+  &quot;alg&quot;: &quot;ES256&quot;,
+  &quot;kid&quot;: &quot;runtime-receipt-key-2026-01&quot;,
+  &quot;typ&quot;: &quot;asp-receipt+jws&quot;
+}
+</code></pre>
+<p>The following envelope is schematic; angle-bracket strings mark values that a
+producer replaces with valid base64url JWS values.</p>
+<pre><code class="language-json">{
+  &quot;receipt_signatures&quot;: {
+    &quot;signatures&quot;: [
+      {
+        &quot;protected&quot;: &quot;&lt;base64url-protected-header&gt;&quot;,
+        &quot;signature&quot;: &quot;&lt;base64url-es256-signature&gt;&quot;
+      }
+    ]
   }
 }
 </code></pre>
-<p>Receipts MAY be signed by the app, runtime, or both. A future draft is expected
-to define canonicalization and signature profiles.</p>
-<p>How the application obtains the <code>runtime_receipt_hash</code> value for the <code>links</code>
-field — for example, in the action request itself or through a later
-submission to the receipt endpoint — is not defined in this draft; see Open
-Questions.</p>
+<p>The <code>receipt_signatures</code> object MUST contain exactly the non-empty <code>signatures</code>
+array; <code>payload</code> and every other member are forbidden in the transported
+envelope. Each signature object MUST contain exactly <code>protected</code> and
+<code>signature</code>; a JWS <code>header</code> member is forbidden. The
+decoded protected header MUST contain exactly three unique members: <code>alg</code>,
+<code>kid</code>, and <code>typ</code>. <code>typ</code> MUST be <code>asp-receipt+jws</code>; this is an ASP-private type
+string pending any media-type registration and MUST be compared exactly.
+Duplicate header members, <code>alg: none</code>, inline <code>jwk</code>, and any <code>jku</code>, <code>x5u</code>, or
+<code>x5c</code> key location MUST be rejected.</p>
+<p>Implementations of this profile MUST support <code>ES256</code> and MUST enforce an
+explicit algorithm allow-list. An ES256 JWK MUST use <code>kty: &quot;EC&quot;</code> and
+<code>crv: &quot;P-256&quot;</code>; when present, <code>alg</code> MUST be <code>ES256</code>, <code>use</code> MUST be <code>sig</code>, and
+<code>key_ops</code> MUST permit <code>verify</code>. The JWS signature decodes to the 64-octet <code>R || S</code> form defined by RFC 7518, not an ASN.1 DER signature. ES256 signers SHOULD
+derive the nonce deterministically according to RFC 6979. A future profile MAY
+add a fully specified algorithm such as <code>Ed25519</code>; the polymorphic <code>EdDSA</code>
+identifier MUST NOT be substituted.</p>
+<p><code>kid</code> is only a lookup hint. Application keys MUST be resolved through
+issuer-bound authenticated metadata such as the manifest
+<code>audit.receipt_signing.jwks_uri</code>; runtime keys MUST be resolved through the
+runtime identity or key registration bound to the grant. A verifier MUST ensure
+that the resolved key is authorized for the claimed signer and receipt role.
+For a required signer, the JWS <code>kid</code> MUST select an entry in the hashed grant's
+<code>audit.receipt_signing.signer_keys</code> whose <code>role</code> matches the receipt producer,
+and the resolved public JWK's RFC 7638 SHA-256 thumbprint MUST match
+<code>jwk_thumbprint</code>. A <code>kid</code> match without the role and pinned thumbprint is
+insufficient.</p>
+<p>An application advertising this profile MUST include <code>asp-jws-detached</code> in
+<code>audit.receipt_signing.profiles_supported</code>, <code>ES256</code> in
+<code>algorithms_supported</code>, and an issuer-bound HTTPS <code>jwks_uri</code>. A runtime signing
+receipt evidence MUST register or attest its verification key through the
+authenticated runtime relationship before a grant can require the <code>runtime</code>
+signer role. A receipt-supplied URL or inline key is never sufficient trust.
+Signers MUST retain or make their historical public keys available for at least
+the applicable receipt-retention period. Key rotation does not rewrite an old
+grant's pinned thumbprints; requiring a new key for future receipts requires a
+new grant hash or explicit grant renewal. Within one issuer and signer role, a
+<code>kid</code> MUST NOT be rebound to different key material. A compromise or revocation can make
+historical evidence indeterminate according to verifier policy because this
+profile does not provide an independent trusted timestamp.</p>
+<p>The manifest advertises supported algorithms and key metadata. A grant MAY
+make signatures mandatory through an <code>audit.receipt_signing</code> object containing
+<code>profile: &quot;asp-jws-detached&quot;</code> and <code>required_signers</code>, whose values are
+<code>runtime</code> and/or <code>application</code>. A listed role MUST sign the receipts it
+produces; listing both roles requires a signed runtime receipt and a signed
+application receipt, not two signatures on every receipt. Additional
+co-signatures over the same detached payload remain possible through General
+JWS. The requirement MUST include at least one pinned <code>signer_keys</code> entry for
+each required role. Because the requirement and key pins are inside the hashed
+grant rather than the removable signature envelope, they cannot be stripped
+without changing <code>grant_hash</code>. If the grant has no such requirement, an
+unsigned receipt remains conforming hash-linked audit material but MUST NOT be
+represented as authenticated portable evidence.</p>
+<p>A verifier MUST validate receipt structure and linked hashes first, reconstruct
+the canonical detached payload, enforce protected-header and key policy, verify
+the signature required for that receipt's producer role, and then validate the
+parent chain to a trusted anchor. A present but invalid, unknown, or
+unverifiable signature MUST NOT be downgraded to an unsigned receipt. Missing
+or invalid required signatures make the receipt invalid as evidence; they do
+not retroactively authorize or undo the underlying application action.</p>
 <h2 id="revocation-semantics" data-asp-heading="Revocation Semantics">Revocation Semantics</h2>
 <p>The protocol MUST define what happens when authority changes.</p>
 <p>Revocation MUST be possible from both sides. Applications SHOULD give users an
@@ -2018,7 +2534,9 @@ <h3 id="oauth-grant-revocation-profile" data-asp-heading="OAuth Grant Revocation
   &quot;audience&quot;: &quot;application_runtime_456&quot;,
   &quot;payload&quot;: {
     &quot;grant_id&quot;: &quot;grant_123&quot;,
+    &quot;grant_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
     &quot;app_id&quot;: &quot;code.example.com&quot;,
+    &quot;surface_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
     &quot;runtime_id&quot;: &quot;application_runtime_456&quot;,
     &quot;agent_id&quot;: &quot;local_agent_789&quot;,
     &quot;passport_hash&quot;: &quot;sha256:...&quot;,
@@ -2031,8 +2549,9 @@ <h3 id="oauth-grant-revocation-profile" data-asp-heading="OAuth Grant Revocation
 }
 </code></pre>
 <p>Required event fields are <code>id</code>, <code>type</code>, <code>occurred_at</code>, <code>issuer</code>, <code>audience</code>, and
-<code>payload</code>. The payload MUST contain <code>grant_id</code>, <code>app_id</code>, <code>runtime_id</code>,
-<code>agent_id</code>, <code>passport_hash</code>, <code>revoked_at</code>, <code>effective_at</code>, <code>reason</code>, and
+<code>payload</code>. The payload MUST contain <code>grant_id</code>, <code>grant_hash</code>, <code>app_id</code>,
+<code>surface_hash</code>, <code>runtime_id</code>, <code>agent_id</code>, <code>passport_hash</code>, <code>revoked_at</code>,
+<code>effective_at</code>, <code>reason</code>, and
 <code>cascade</code>; <code>parent_grant_id</code> is REQUIRED for a child grant and otherwise MAY be
 null. Defined reason values are <code>user_revoked</code>, <code>application_revoked</code>,
 <code>runtime_revoked</code>, <code>credential_compromise</code>, <code>parent_revoked</code>, <code>policy_changed</code>,
@@ -2045,6 +2564,13 @@ <h3 id="oauth-grant-revocation-profile" data-asp-heading="OAuth Grant Revocation
 of the revoked grant and MUST disclose no more grant data than the target
 runtime already possessed. A future signing profile MAY additionally define an
 application signature for portable event verification.</p>
+<p>The runtime MUST compare event <code>grant_hash</code> and <code>surface_hash</code> with its retained
+grant and manifest snapshot. If an authenticated event matches the stored
+<code>grant_id</code> and delegate tuple but either hash differs, the runtime MUST fail
+closed: mark the stored grant inactive, record <code>integrity_mismatch</code>, and
+resynchronize authoritative state. It MUST NOT replace its stored hash
+projections from the event, but it also MUST NOT ignore the revocation and keep
+using the grant.</p>
 <p>After accepting the event, the runtime MUST atomically mark the grant inactive,
 discard cached active introspection state, stop new actions and credential use,
 cancel or downgrade affected sessions according to app policy, cascade the
@@ -2103,6 +2629,7 @@ <h2 id="error-model" data-asp-heading="Error Model">Error Model</h2>
 | <code>grant_expired</code> | Grant has expired. |
 | <code>grant_revoked</code> | Grant was revoked. |
 | <code>grant_proof_invalid</code> | Grant credential or proof is missing, invalid, or not bound correctly. |
+| <code>integrity_mismatch</code> | A supplied surface, grant, policy-decision, receipt, or parent hash does not match its complete hashing view or authoritative projection. |
 | <code>scope_denied</code> | Grant scope does not permit the action. |
 | <code>resource_denied</code> | Grant constraints do not permit the target resource. |
 | <code>approval_required</code> | Required approval is absent. |
@@ -2123,10 +2650,11 @@ <h2 id="error-model" data-asp-heading="Error Model">Error Model</h2>
 <p>Errors SHOULD be safe to show to users and precise enough for runtime policy
 debugging.</p>
 <h2 id="versioning-and-compatibility" data-asp-heading="Versioning and Compatibility">Versioning and Compatibility</h2>
-<p>Surface manifests SHOULD include:</p>
+<p>Surface manifests MUST include:</p>
 <pre><code class="language-json">{
   &quot;protocol&quot;: &quot;agent-surface/0.1&quot;,
   &quot;surface_version&quot;: &quot;2026-06-25&quot;,
+  &quot;surface_hash&quot;: &quot;sha-256:&lt;base64url-digest&gt;&quot;,
   &quot;compatibility&quot;: {
     &quot;min_runtime&quot;: &quot;application-runtime/0.1&quot;,
     &quot;schema_dialect&quot;: &quot;https://json-schema.org/draft/2020-12/schema&quot;
@@ -2136,6 +2664,13 @@ <h2 id="versioning-and-compatibility" data-asp-heading="Versioning and Compatibi
 <p>The <code>surface_version</code> value is an opaque identifier. Runtimes MUST compare
 surface versions for exact equality; this draft defines no ordering between
 surface versions.</p>
+<p>Any change to the manifest hashing view MUST produce both a new <code>surface_hash</code>
+and a new <code>surface_version</code>. Compatibility classification determines whether
+an existing grant requires renewal; it does not permit two different manifest
+objects to reuse one version. Applications SHOULD retain the exact old manifest
+snapshot identified by every active grant. If that snapshot is unavailable,
+the application MUST NOT interpret the action against the latest manifest and
+MUST reject the action as <code>surface_incompatible</code>.</p>
 <p>Compatibility rules:</p>
 <ul>
 <li>Removing an action is a breaking change for grants whose scopes cover that
@@ -2265,11 +2800,27 @@ <h3 id="replay-and-duplicate-actions" data-asp-heading="Replay and Duplicate Act
 risk. Side-effecting actions MUST be idempotent.</p>
 <h3 id="surface-downgrade" data-asp-heading="Surface Downgrade">Surface Downgrade</h3>
 <p>A malicious network or compromised app path can present an older, less safe
-surface version. Runtimes SHOULD pin issuer, app id, and minimum accepted
-protocol versions where possible.</p>
+surface version. Runtimes SHOULD pin issuer, app id, minimum accepted protocol
+versions, and the verified version/hash tuple. Reusing one <code>surface_version</code>
+with a different hash is an integrity failure. A self-declared <code>surface_hash</code>
+does not authenticate the publisher because an attacker able to replace the
+manifest can also recompute it; HTTPS, issuer binding, and local trust policy
+remain mandatory.</p>
+<p><code>surface_hash</code> commits to schema URLs and other manifest values, not to the
+transitive content later served by those URLs. A deployment that needs that
+property must separately pin schema content hashes or use a future canonical
+surface-bundle profile.</p>
 <h3 id="receipt-forgery" data-asp-heading="Receipt Forgery">Receipt Forgery</h3>
-<p>Receipts SHOULD be hash-linked to normalized inputs and outputs. Future drafts
-are expected to define signing and canonicalization profiles.</p>
+<p>Receipts are hash-linked with the Canonical Object Hash Profile. This detects a
+changed receipt or broken parent link relative to a retained chain head, but an
+attacker that controls the whole unsigned history can replace and rehash the
+chain. The optional Receipt Signing Profile authenticates a receipt only after
+the verifier resolves an authorized signer key and validates the detached JWS;
+<code>kid</code>, hash fields, and link fields are not trust anchors by themselves.</p>
+<p>A verifier MUST reject duplicate JSON members, hash mismatches, parent cycles,
+untrusted signature keys, disallowed algorithms, and a present invalid
+signature. It MUST NOT treat an unsigned optional receipt as signed evidence or
+downgrade an invalid signature to the unsigned MVP.</p>
 <h2 id="privacy-considerations" data-asp-heading="Privacy Considerations">Privacy Considerations</h2>
 <p>Agent Surface Protocol can reveal sensitive metadata:</p>
 <ul>
@@ -2283,6 +2834,11 @@ <h2 id="privacy-considerations" data-asp-heading="Privacy Considerations">Privac
 Runtimes SHOULD minimize agent and passport disclosure when possible. Receipts
 SHOULD support pseudonymous user references where legal and operationally
 appropriate.</p>
+<p>Cross-system trace correlation can reveal relationships between otherwise
+separate user actions, tenants, and services. <code>trace_id</code>, <code>span_id</code>, and
+<code>tracestate</code> MUST NOT encode semantic identifiers or secrets. Components SHOULD
+apply bounded retention, access control, and sampling independently of whether
+the incoming trace flags request recording.</p>
 <h2 id="conformance" data-asp-heading="Conformance">Conformance</h2>
 <p>This draft defines conformance profiles instead of a single all-or-nothing
 profile.</p>
@@ -2290,6 +2846,8 @@ <h3 id="surface-only-application" data-asp-heading="Surface-Only Application">Su
 <p>An application conforms to the Surface-Only profile when it:</p>
 <ul>
 <li>publishes an Agent Surface Manifest</li>
+<li>computes and publishes a valid <code>surface_hash</code> and changes
+<code>surface_version</code> whenever the manifest hashing view changes</li>
 <li>declares actions, resources, events, scopes, and schemas</li>
 <li>declares risk labels for actions</li>
 <li>declares endpoints or explicitly marks the surface as proposal/documentation
@@ -2303,6 +2861,8 @@ <h3 id="grant-enforcing-application" data-asp-heading="Grant-Enforcing Applicati
 <li>issues, validates, or introspects Agent Grants</li>
 <li>validates grant state for every action</li>
 <li>validates credential binding to runtime, agent, and passport evidence</li>
+<li>validates <code>grant_hash</code> and binds the grant to the exact verified
+<code>surface_hash</code> snapshot</li>
 <li>treats <code>grant_id</code> as an identifier, not authority</li>
 <li>supports idempotency for side-effecting actions</li>
 <li>supports grant revocation</li>
@@ -2318,6 +2878,7 @@ <h3 id="oauth-grant-lifecycle-application" data-asp-heading="OAuth Grant Lifecyc
 Rich Authorization Request Profile</li>
 <li>implements the OAuth Token Exchange Profile without privilege amplification</li>
 <li>returns the active and inactive Grant Introspection Profile contracts</li>
+<li>returns matching top-level and authorization-details hash projections</li>
 <li>implements RFC 7009 semantic grant revocation, derivation cascade, and the
 authenticated <code>grant.revoked</code> control event when an event endpoint is declared</li>
 </ul>
@@ -2326,10 +2887,24 @@ <h3 id="receipt-producing-application" data-asp-heading="Receipt-Producing Appli
 <ul>
 <li>satisfies the Grant-Enforcing profile</li>
 <li>emits app receipts for required side-effecting actions</li>
-<li>links receipts to grant id, session id, action id, agent id, runtime id, and
-idempotency key</li>
+<li>emits recomputable <code>receipt_hash</code>, <code>grant_hash</code>, <code>surface_hash</code>, and
+<code>policy_decision_hash</code> values</li>
+<li>includes the complete typed Policy Decision Object and requires its embedded
+hash to match the receipt's <code>policy_decision_hash</code></li>
+<li>links an app receipt to the verified runtime receipt through
+<code>parent_receipt_hash</code> when runtime receipt evidence is required</li>
+<li>preserves trace id, session id, action id, agent id, runtime id, and
+idempotency key while using a producer-specific span id</li>
+<li>records session id, trace id, and producer span id in the corresponding local
+action and receipt log entry</li>
 <li>records denied or failed high-risk actions</li>
 </ul>
+<p>An application or runtime claims the <code>asp-jws-detached</code> Receipt Signing Profile
+only when it supports the canonical detached payload, ES256 verification,
+authenticated key resolution, grant-pinned signer roles and thumbprints,
+historical public-key retention, and the no-downgrade behavior defined above.
+It MUST emit every signature required for its producer role and reject required
+or present signatures that do not verify.</p>
 <h3 id="proof-bound-grant-enforcing-application" data-asp-heading="Proof-Bound Grant-Enforcing Application">Proof-Bound Grant-Enforcing Application</h3>
 <p>An application conforms to the Proof-Bound Grant-Enforcing Application profile
 when it:</p>
@@ -2346,6 +2921,7 @@ <h3 id="application-runtime-profile" data-asp-heading="Application Runtime Profi
 <p>An application runtime conforms to this profile when it:</p>
 <ul>
 <li>discovers and validates Agent Surface Manifests</li>
+<li>recomputes <code>surface_hash</code> and pins the exact manifest snapshot</li>
 <li>verifies Agent Passport evidence before delegation</li>
 <li>obtains explicit user consent before storing a grant</li>
 <li>mediates agent actions instead of exposing raw authority</li>
@@ -2362,6 +2938,10 @@ <h3 id="application-runtime-profile" data-asp-heading="Application Runtime Profi
 <li>enforces local policy and approval rules</li>
 <li>validates action input against schemas before sending to the app</li>
 <li>records local audit events and runtime receipts</li>
+<li>computes and validates grant, policy-decision, and receipt hashes; propagates
+session and W3C-compatible trace context</li>
+<li>records session id, trace id, and producer span id in local action and receipt
+logs</li>
 <li>stops actions when grants are revoked or expired</li>
 </ul>
 <h3 id="agent-adapter" data-asp-heading="Agent Adapter">Agent Adapter</h3>
@@ -2374,6 +2954,7 @@ <h3 id="agent-adapter" data-asp-heading="Agent Adapter">Agent Adapter</h3>
 <li>emits typed events</li>
 <li>handles denials and approval waits</li>
 <li>preserves session and grant identifiers in audit context</li>
+<li>preserves valid trace ids and creates a new span id for each adapter operation</li>
 </ul>
 <h2 id="application-mvp-mapping" data-asp-heading="Application MVP Mapping">Application MVP Mapping</h2>
 <p>An application implementation can start with a small runtime bridge:</p>
@@ -2400,8 +2981,8 @@ <h2 id="application-mvp-mapping" data-asp-heading="Application MVP Mapping">Appl
 <li>Integrate Agent Passport verification as an admission precondition.</li>
 </ol>
 <h2 id="example-end-to-end-flow" data-asp-heading="Example End-to-End Flow">Example End-to-End Flow</h2>
-<pre><code class="language-text">1. App publishes /.well-known/agent-surface.json.
-2. Application runtime discovers and validates the surface.
+<pre><code class="language-text">1. App publishes /.well-known/agent-surface.json with `surface_hash`.
+2. Application runtime recomputes the hash and pins the exact surface.
 3. User chooses &quot;Connect my local agent&quot;.
 4. Runtime verifies the selected agent's Agent Passport.
 5. Runtime sends an Agent Grant `authorization_details` request.
@@ -2413,15 +2994,19 @@ <h2 id="example-end-to-end-flow" data-asp-heading="Example End-to-End Flow">Exam
    - duration: 2 hours
    - writes: require approval
 7. User approves a subset or the complete request.
-8. App issues or token-exchanges grant_123 and its bound Grant Credential.
+8. App issues or token-exchanges grant_123, its canonical `grant_hash`, and its
+   bound Grant Credential.
 9. Runtime stores the authoritative granted details and credential.
 10. App starts a pull-request review session.
 11. Agent reads typed PR context through runtime-mediated resources.
 12. Agent proposes a review comment.
 13. User or app approves the write.
-14. Runtime sends comment.create with an idempotency key and Grant Credential.
-15. App verifies or introspects current grant state and writes the comment.
-16. Runtime and app issue linked receipts.
+14. Runtime records its policy decision and receipt, then sends comment.create
+    with trace context, parent receipt hash, idempotency key, and Grant Credential.
+15. App verifies current grant, surface, decision, and receipt hashes and writes
+    the comment.
+16. Runtime and app receipts form a verified parent-hash chain and MAY carry
+    detached JWS signatures when required by the grant.
 17. User revokes grant_123; the app rejects it immediately.
 18. App emits authenticated `grant.revoked`; runtime stops affected work.
 </code></pre>
@@ -2433,10 +3018,6 @@ <h2 id="open-questions" data-asp-heading="Open Questions">Open Questions</h2>
 runtime can request an Agent Grant?</li>
 <li>Does grant binding require runtime attestation, or is a registered runtime id
 enough for early implementations?</li>
-<li>Are receipts signed in the first version, or only hash-linked and
-locally stored?</li>
-<li>Which JSON canonicalization profile is used for signed grants and
-receipts?</li>
 <li>Is <code>/.well-known/agent-surface.json</code> public, authenticated, or both
 depending on app tenancy?</li>
 <li>What is the minimal sender-constrained grant credential profile?</li>
@@ -2445,8 +3026,6 @@ <h2 id="open-questions" data-asp-heading="Open Questions">Open Questions</h2>
 <li>What happens to active sessions when an app changes surface versions?</li>
 <li>What transport, ordering, acknowledgement, and replay semantics do event
 subscriptions use?</li>
-<li>How does the application obtain the runtime receipt hash that an app receipt
-links to?</li>
 <li>How is <code>max_cost_usd</code> metered when runtime-side inference cost and app-side
 action cost diverge, and which side is authoritative?</li>
 <li>How are runtime-side approvals proven to the application beyond an
@@ -2482,6 +3061,36 @@ <h2 id="references" data-asp-heading="References">References</h2>
 <a href="https://www.rfc-editor.org/rfc/rfc8705">https://www.rfc-editor.org/rfc/rfc8705</a></li>
 <li>OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP):
 <a href="https://www.rfc-editor.org/rfc/rfc9449">https://www.rfc-editor.org/rfc/rfc9449</a></li>
+<li>The I-JSON Message Format:
+<a href="https://www.rfc-editor.org/rfc/rfc7493">https://www.rfc-editor.org/rfc/rfc7493</a></li>
+<li>Base-N Encodings:
+<a href="https://www.rfc-editor.org/rfc/rfc4648">https://www.rfc-editor.org/rfc/rfc4648</a></li>
+<li>Date and Time on the Internet: Timestamps:
+<a href="https://www.rfc-editor.org/rfc/rfc3339">https://www.rfc-editor.org/rfc/rfc3339</a></li>
+<li>JSON Web Signature (JWS):
+<a href="https://www.rfc-editor.org/rfc/rfc7515">https://www.rfc-editor.org/rfc/rfc7515</a></li>
+<li>JSON Web Key (JWK):
+<a href="https://www.rfc-editor.org/rfc/rfc7517">https://www.rfc-editor.org/rfc/rfc7517</a></li>
+<li>JSON Web Algorithms (JWA):
+<a href="https://www.rfc-editor.org/rfc/rfc7518">https://www.rfc-editor.org/rfc/rfc7518</a></li>
+<li>JSON Web Key (JWK) Thumbprint:
+<a href="https://www.rfc-editor.org/rfc/rfc7638">https://www.rfc-editor.org/rfc/rfc7638</a></li>
+<li>Deterministic Usage of DSA and ECDSA:
+<a href="https://www.rfc-editor.org/rfc/rfc6979">https://www.rfc-editor.org/rfc/rfc6979</a></li>
+<li>JSON Web Signature Unencoded Payload Option:
+<a href="https://www.rfc-editor.org/rfc/rfc7797">https://www.rfc-editor.org/rfc/rfc7797</a></li>
+<li>JSON Canonicalization Scheme (JCS):
+<a href="https://www.rfc-editor.org/rfc/rfc8785">https://www.rfc-editor.org/rfc/rfc8785</a></li>
+<li>Verified erratum 7920 for JSON Canonicalization Scheme:
+<a href="https://www.rfc-editor.org/errata/eid7920">https://www.rfc-editor.org/errata/eid7920</a></li>
+<li>JSON Web Token Best Current Practices:
+<a href="https://www.rfc-editor.org/rfc/rfc8725">https://www.rfc-editor.org/rfc/rfc8725</a></li>
+<li>Fully Specified Algorithms for JOSE:
+<a href="https://www.rfc-editor.org/rfc/rfc9864">https://www.rfc-editor.org/rfc/rfc9864</a></li>
+<li>Secure Hash Standard (SHS), FIPS 180-4:
+<a href="https://csrc.nist.gov/pubs/fips/180-4/upd1/final">https://csrc.nist.gov/pubs/fips/180-4/upd1/final</a></li>
+<li>W3C Trace Context:
+<a href="https://www.w3.org/TR/trace-context/">https://www.w3.org/TR/trace-context/</a></li>
 <li>Key words for use in RFCs to Indicate Requirement Levels:
 <a href="https://www.rfc-editor.org/rfc/rfc2119">https://www.rfc-editor.org/rfc/rfc2119</a></li>
 <li>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words:
@@ -2914,7 +3523,7 @@ <h2 id="appendix-c-product-positioning" data-asp-heading="Appendix C: Product Po
   const root = document.getElementById("asp-review-019f48fb");
   if (!root) return;
 
-  const reviews = [{"id":1,"title":"Reference Monitor Invariants","description":"явно зафиксировать, что все app-действия агента должны проходить через runtime, а агент не получает прямую authority по умолчанию.","category":"Security / authority boundary","side":"left","anchors":[{"heading":"Abstract","anchorId":"abstract"},{"heading":"App Exposes, Runtime Mediates, Agent Executes","anchorId":"app-exposes-runtime-mediates-agent-executes"},{"heading":"Agent Does Not Receive Raw Authority","anchorId":"agent-does-not-receive-raw-authority"},{"heading":"Application Runtime Profile","anchorId":"application-runtime-profile"}],"status":"present","rationale":"RFC теперь определяет runtime как reference monitor: каждое agent-initiated действие к Agent Surface проходит через runtime, а app-side verification остаётся обязательной.","priority":"P0"},{"id":2,"title":"Grant Credential Binding","description":"описать, чем именно runtime доказывает app, что grant принадлежит конкретному runtime/agent/passport tuple.","category":"Security / authority boundary","side":"right","anchors":[{"heading":"Agent Grant","anchorId":"agent-grant-2"},{"heading":"Grant Object","anchorId":"grant-object"},{"heading":"Grant Credentials and Proof","anchorId":"grant-credentials-and-proof"},{"heading":"Grant Verification","anchorId":"grant-verification"}],"status":"present","rationale":"RFC требует app-verifiable binding grant credential к grant, audience, runtime, agent и passport hash; introspection и session profiles не могут подменяться runtime assertion.","priority":"P0"},{"id":3,"title":"Sender-Constrained Grants","description":"поддержать DPoP, mTLS, workload identity или аналог, чтобы украденный bearer-token не давал полномочий сам по себе.","category":"Security / authority boundary","side":"left","anchors":[{"heading":"Grant Credential","anchorId":"grant-credential"},{"heading":"Grant Credentials and Proof","anchorId":"grant-credentials-and-proof"},{"heading":"Action Request","anchorId":"action-request"},{"heading":"Stolen Grant Credential","anchorId":"stolen-grant-credential"},{"heading":"Proof-Bound Grant-Enforcing Application","anchorId":"proof-bound-grant-enforcing-application"}],"status":"present","rationale":"Proof-Bound Credential и Proof-Bound Grant-Enforcing profiles требуют per-request possession proof; DPoP, mTLS и server-session проверки имеют отдельную корректную replay semantics.","priority":"P0"},{"id":4,"title":"Credential Release Policy","description":"сделать выдачу raw app token агенту отдельной privileged capability, запрещённой по умолчанию.","category":"Security / authority boundary","side":"right","anchors":[{"heading":"Agent Does Not Receive Raw Authority","anchorId":"agent-does-not-receive-raw-authority"},{"heading":"Grant Verification","anchorId":"grant-verification"},{"heading":"Raw Token Leakage","anchorId":"raw-token-leakage"},{"heading":"Agent Adapter","anchorId":"agent-adapter"}],"status":"present","rationale":"Raw credential release — default-deny capability `credential.release`; выдаётся только новый attenuated credential для non-Agent-Surface audience, который app обязана отклонять на Surface endpoints.","priority":"P0"},{"id":5,"title":"Subdelegation Rules","description":"явно описать, может ли агент вызывать субагентов, remote models, MCP servers или другие runtimes.","category":"Security / authority boundary","side":"left","anchors":[{"heading":"Runtime","anchorId":"runtime"},{"heading":"Subdelegation","anchorId":"subdelegation"},{"heading":"Model Context Protocol","anchorId":"model-context-protocol"},{"heading":"4. Agent Adapter Protocol","anchorId":"4-agent-adapter-protocol"},{"heading":"Malicious or Compromised Agent","anchorId":"malicious-or-compromised-agent"}],"status":"present","rationale":"Компоненты без отдельного grant проходят parent runtime; отдельно granted child runtime использует собственный binding и direct app route, с parent linkage, attenuation и cascade revocation.","priority":"P0"},{"id":6,"title":"App-Side Enforcement Requirements","description":"закрепить, что app обязана проверять grant на каждое действие, а не доверять runtime assertion.","category":"Security / authority boundary","side":"right","anchors":[{"heading":"App-Side Enforcement Is Mandatory","anchorId":"app-side-enforcement-is-mandatory"},{"heading":"Model A: App-Issued Grant","anchorId":"model-a-app-issued-grant"},{"heading":"Grant Verification","anchorId":"grant-verification"},{"heading":"Malicious or Compromised Runtime","anchorId":"malicious-or-compromised-runtime"}],"status":"present","rationale":"Спецификация уже требует app-verifiable authorization для каждого действия и запрещает доверять одному runtime assertion.","priority":"P3"},{"id":7,"title":"OAuth RAR Profile","description":"описать Agent Grant как профиль OAuth Rich Authorization Requests через `authorization_details`.","category":"Grant / OAuth / authorization model","side":"left","anchors":[{"heading":"OAuth","anchorId":"oauth"},{"heading":"OAuth Grant Lifecycle Profile","anchorId":"oauth-grant-lifecycle-profile"},{"heading":"Rich Authorization Request Profile","anchorId":"rich-authorization-request-profile"},{"heading":"Agent Grant","anchorId":"agent-grant-2"},{"heading":"Grant Object","anchorId":"grant-object"},{"heading":"Grant Issuance Models","anchorId":"grant-issuance-models"}],"status":"present","rationale":"RFC задаёт collision-resistant Agent Grant authorization-details type, обязательные поля, consent/subset semantics, ошибки RFC 9396 и возврат authoritative granted object.","priority":"P2"},{"id":8,"title":"OAuth Token Exchange Profile","description":"добавить путь, где user/app session обменивается на constrained agent grant token.","category":"Grant / OAuth / authorization model","side":"right","anchors":[{"heading":"OAuth","anchorId":"oauth"},{"heading":"OAuth Token Exchange Profile","anchorId":"oauth-token-exchange-profile"},{"heading":"Grant Issuance Models","anchorId":"grant-issuance-models"},{"heading":"Model A: App-Issued Grant","anchorId":"model-a-app-issued-grant"},{"heading":"Grant Credentials and Proof","anchorId":"grant-credentials-and-proof"}],"status":"present","rationale":"RFC профилирует RFC 8693 request/response, runtime/actor authentication, resource restriction, attenuation, proof binding и explicit derivation/revocation linkage.","priority":"P2"},{"id":9,"title":"Grant Proof vs Grant ID","description":"явно сказать, что `grant_id` — это идентификатор, а не authority без credential/proof.","category":"Grant / OAuth / authorization model","side":"left","anchors":[{"heading":"Grant Credential","anchorId":"grant-credential"},{"heading":"Grant Identifier Is Not Authority","anchorId":"grant-identifier-is-not-authority"},{"heading":"Grant Credentials and Proof","anchorId":"grant-credentials-and-proof"},{"heading":"Action Request","anchorId":"action-request"}],"status":"present","rationale":"Текст прямо и нормативно определяет grant_id как correlation identifier, а не authority.","priority":"P3"},{"id":10,"title":"Grant Hash","description":"добавить канонический `grant_hash`, чтобы receipts и audit ссылались на конкретное содержимое grant.","category":"Grant / OAuth / authorization model","side":"right","anchors":[{"heading":"Grant Object","anchorId":"grant-object"},{"heading":"Receipt Requirements","anchorId":"receipt-requirements"},{"heading":"App Receipt","anchorId":"app-receipt"},{"heading":"Receipt Forgery","anchorId":"receipt-forgery"}],"status":"missing","rationale":"Receipts содержат grant_id, но canonical grant_hash и ссылка на точное содержимое grant отсутствуют.","priority":"P1"},{"id":11,"title":"Grant Introspection Contract","description":"определить минимальный ответ introspection endpoint: active, scopes, constraints, runtime, agent, passport hash, expiry.","category":"Grant / OAuth / authorization model","side":"left","anchors":[{"heading":"OAuth","anchorId":"oauth"},{"heading":"Grant Introspection Profile","anchorId":"grant-introspection-profile"},{"heading":"Endpoints","anchorId":"endpoints"},{"heading":"Grant Credentials and Proof","anchorId":"grant-credentials-and-proof"},{"heading":"Grant Verification","anchorId":"grant-verification"}],"status":"present","rationale":"RFC задаёт authenticated RFC 7662 request, privacy-preserving inactive response и минимальный active contract со scope, tuple, constraints, surface, expiry и credential binding.","priority":"P1"},{"id":12,"title":"Grant Revocation Events","description":"стандартизировать событие `grant.revoked` и поведение runtime/app при его получении.","category":"Grant / OAuth / authorization model","side":"right","anchors":[{"heading":"Event","anchorId":"event"},{"heading":"Events","anchorId":"events"},{"heading":"Revocation Semantics","anchorId":"revocation-semantics"},{"heading":"OAuth Grant Revocation Profile","anchorId":"oauth-grant-revocation-profile"},{"heading":"Grant Revoked","anchorId":"grant-revoked"}],"status":"present","rationale":"RFC определяет RFC 7009 grant transition, cascade revocation, authenticated `grant.revoked` envelope, reason codes, idempotent runtime processing и границу с общей event delivery model.","priority":"P1"},{"id":13,"title":"Wire-Level Endpoints","description":"добавить в manifest явные URLs для action requests, grant request/introspection/revocation, events и receipts.","category":"Agent Surface Manifest","side":"left","anchors":[{"heading":"Agent Surface Manifest","anchorId":"agent-surface-manifest-2"},{"heading":"Endpoints","anchorId":"endpoints"},{"heading":"Example Manifest","anchorId":"example-manifest"},{"heading":"Discovery","anchorId":"discovery"}],"status":"present","rationale":"Manifest уже объявляет grant request/introspection/revocation, actions, events и receipts URLs.","priority":"P3"},{"id":14,"title":"Surface Hash","description":"добавить `surface_hash`, чтобы runtime и receipts ссылались не только на версию, но и на точный surface contract.","category":"Agent Surface Manifest","side":"right","anchors":[{"heading":"Required Top-Level Fields","anchorId":"required-top-level-fields"},{"heading":"Grant Object","anchorId":"grant-object"},{"heading":"Receipt Requirements","anchorId":"receipt-requirements"},{"heading":"Surface Downgrade","anchorId":"surface-downgrade"}],"status":"missing","rationale":"Связь выполняется только через surface_version; canonical surface_hash в manifest, grant и receipts отсутствует.","priority":"P1"},{"id":15,"title":"Surface Version Compatibility Rules","description":"формализовать, какие изменения surface breaking, а какие non-breaking.","category":"Agent Surface Manifest","side":"left","anchors":[{"heading":"Surface Version Changed","anchorId":"surface-version-changed"},{"heading":"Versioning and Compatibility","anchorId":"versioning-and-compatibility"}],"status":"present","rationale":"Breaking и non-breaking изменения уже классифицированы, включая schema, actions, risks, receipts и endpoint semantics.","priority":"P3"},{"id":16,"title":"Agent Surface Is Not Full API","description":"подчеркнуть, что surface — curated affordance layer, а не зеркало всего public/private API приложения.","category":"Agent Surface Manifest","side":"right","anchors":[{"heading":"Non-Goals","anchorId":"non-goals"},{"heading":"Agent Surface","anchorId":"agent-surface"},{"heading":"Model Context Protocol","anchorId":"model-context-protocol"},{"heading":"Application MVP Mapping","anchorId":"application-mvp-mapping"}],"status":"partial","rationale":"Surface отделён от API endpoint list и не заменяет existing APIs, но curated/selective exposure и запрет зеркалирования API не сформулированы явно.","priority":"P2"},{"id":17,"title":"OpenAPI / AsyncAPI Extensions","description":"разрешить генерировать Agent Surface из существующих API specs через `x-agent-surface` аннотации.","category":"Agent Surface Manifest","side":"left","anchors":[{"heading":"Agent Surface Manifest","anchorId":"agent-surface-manifest-2"},{"heading":"Resources","anchorId":"resources"},{"heading":"Actions","anchorId":"actions"},{"heading":"Events","anchorId":"events"}],"status":"missing","rationale":"JSON Schema URLs поддерживаются, но import/generation и x-agent-surface annotations для OpenAPI/AsyncAPI отсутствуют.","priority":"P3"},{"id":18,"title":"Proposal-Only Surface Mode","description":"дать app способ объявить, что агенты могут только предлагать изменения, но не делать writes напрямую.","category":"Agent Surface Manifest","side":"right","anchors":[{"heading":"Proposal Mode Is the Default","anchorId":"proposal-mode-is-the-default"},{"heading":"Proposal-Only Support","anchorId":"proposal-only-support"},{"heading":"Proposal Flow","anchorId":"proposal-flow"},{"heading":"Surface-Only Application","anchorId":"surface-only-application"}],"status":"partial","rationale":"Proposal-only actions полностью описаны, но нет формального top-level surface mode, запрещающего все direct writes.","priority":"P1"},{"id":19,"title":"Action Execution Modes","description":"добавить стандартные modes: `read`, `dry_run`, `propose`, `reserve`, `commit`, `compensate`, `revert`.","category":"Action semantics","side":"left","anchors":[{"heading":"Actions","anchorId":"actions"},{"heading":"Proposal-Only Support","anchorId":"proposal-only-support"},{"heading":"Risk Taxonomy","anchorId":"risk-taxonomy"},{"heading":"Proposal Flow","anchorId":"proposal-flow"}],"status":"partial","rationale":"Есть direct, write и proposal_only, но единая stateful модель read/dry_run/reserve/commit/compensate/revert отсутствует.","priority":"P1"},{"id":20,"title":"Effect Model","description":"дополнить risk taxonomy описанием эффекта: public/private, reversible/irreversible, internal/external, financial/security/deployment/etc.","category":"Action semantics","side":"right","anchors":[{"heading":"Actions","anchorId":"actions"},{"heading":"Risk Taxonomy","anchorId":"risk-taxonomy"},{"heading":"Approval Semantics","anchorId":"approval-semantics"},{"heading":"Security Considerations","anchorId":"security-considerations"}],"status":"partial","rationale":"Risk labels покрывают часть эффектов, но независимые dimensions visibility, reversibility, boundary и effect domain не моделируются.","priority":"P1"},{"id":21,"title":"Idempotency Normalization","description":"определить, как нормализуется input для проверки повторного idempotency key.","category":"Action semantics","side":"left","anchors":[{"heading":"Every Write Is Idempotent","anchorId":"every-write-is-idempotent"},{"heading":"Idempotency","anchorId":"idempotency"},{"heading":"Replay and Duplicate Actions","anchorId":"replay-and-duplicate-actions"}],"status":"partial","rationale":"Требование normalization есть, но canonical algorithm/profile оставлен приложению или будущему draft.","priority":"P1"},{"id":22,"title":"Preconditions and Effects Schemas","description":"дать actions схемы для preconditions и expected effects, чтобы runtime мог показать impact до commit.","category":"Action semantics","side":"right","anchors":[{"heading":"Actions","anchorId":"actions"},{"heading":"Action Request","anchorId":"action-request"},{"heading":"Action Response","anchorId":"action-response"},{"heading":"Proposal Flow","anchorId":"proposal-flow"}],"status":"missing","rationale":"Action model содержит input/output schemas, но не preconditions_schema, expected_effects_schema или impact preview.","priority":"P1"},{"id":23,"title":"Resource Lease / Reservation","description":"добавить lease model для задач, tickets, branch names и других ресурсов, чтобы несколько агентов не делали одно и то же.","category":"Action semantics","side":"left","anchors":[{"heading":"Capability Lease","anchorId":"capability-lease"},{"heading":"Resources","anchorId":"resources"},{"heading":"Actions","anchorId":"actions"},{"heading":"Sessions and Actions","anchorId":"sessions-and-actions"}],"status":"missing","rationale":"Capability Lease относится к authorization grant; protocol-level reservation конкретных ресурсов и conflict semantics отсутствуют.","priority":"P2"},{"id":24,"title":"Compensation Semantics","description":"описать, какие действия можно откатить и какой action является компенсацией.","category":"Action semantics","side":"right","anchors":[{"heading":"Actions","anchorId":"actions"},{"heading":"Risk Taxonomy","anchorId":"risk-taxonomy"},{"heading":"Proposal Flow","anchorId":"proposal-flow"},{"heading":"Receipts","anchorId":"receipts"}],"status":"missing","rationale":"Reversibility частично отражена риском destructive, но compensation/revert action linkage и гарантии отката не определены.","priority":"P1"},{"id":25,"title":"CloudEvents Binding","description":"сделать app events совместимыми с CloudEvents или определить эквивалентный envelope.","category":"Events / sessions / AHP","side":"left","anchors":[{"heading":"Event","anchorId":"event"},{"heading":"3. Runtime Bridge Protocol","anchorId":"3-runtime-bridge-protocol"},{"heading":"Events","anchorId":"events"},{"heading":"Sessions and Actions","anchorId":"sessions-and-actions"}],"status":"missing","rationale":"ASP определяет typed events со schema и scope, но CloudEvents envelope или эквивалентный canonical envelope отсутствует.","priority":"P2"},{"id":26,"title":"Event Delivery Semantics","description":"описать at-least-once delivery, ordering, replay cursor, retention, ack и backpressure.","category":"Events / sessions / AHP","side":"right","anchors":[{"heading":"Conceptual Architecture","anchorId":"conceptual-architecture"},{"heading":"3. Runtime Bridge Protocol","anchorId":"3-runtime-bridge-protocol"},{"heading":"Events","anchorId":"events"},{"heading":"Runtime Disconnected","anchorId":"runtime-disconnected"}],"status":"missing","rationale":"Transport hints присутствуют, но delivery guarantee, ordering, cursor, replay, retention, ack и backpressure не определены.","priority":"P1"},{"id":27,"title":"ASP-over-AHP Binding","description":"описать профиль, где AHP несёт session/UI state, а ASP-объекты остаются authority для grants/actions/receipts.","category":"Events / sessions / AHP","side":"left","anchors":[{"heading":"Agent Client Protocol","anchorId":"agent-client-protocol"},{"heading":"3. Runtime Bridge Protocol","anchorId":"3-runtime-bridge-protocol"},{"heading":"Sessions and Actions","anchorId":"sessions-and-actions"},{"heading":"Receipts","anchorId":"receipts"}],"status":"missing","rationale":"Разделение transport и ASP semantics уже намечено для ACP/runtime bridge, но AHP binding нигде не определён.","priority":"P2"},{"id":28,"title":"Session Ownership Model","description":"уточнить, кто может стартовать, наблюдать, отменять и возобновлять session: user, app, runtime или agent.","category":"Events / sessions / AHP","side":"right","anchors":[{"heading":"3. Runtime Bridge Protocol","anchorId":"3-runtime-bridge-protocol"},{"heading":"Session Start","anchorId":"session-start"},{"heading":"Runtime Disconnected","anchorId":"runtime-disconnected"},{"heading":"User Session Expired","anchorId":"user-session-expired"}],"status":"partial","rationale":"App или runtime MAY start session, а cancel/resume упомянуты, но права start/observe/cancel/resume по ролям не формализованы.","priority":"P1"},{"id":29,"title":"Human Elicitation Events","description":"добавить не только approve/deny, но и clarify, choose option, edit proposal, redline diff, step-up auth.","category":"Events / sessions / AHP","side":"left","anchors":[{"heading":"3. Runtime Bridge Protocol","anchorId":"3-runtime-bridge-protocol"},{"heading":"Approval Semantics","anchorId":"approval-semantics"},{"heading":"Proposal Flow","anchorId":"proposal-flow"},{"heading":"Error Model","anchorId":"error-model"}],"status":"partial","rationale":"Есть approval required/resolved, но clarify, options, edit/redline и step-up auth message types отсутствуют.","priority":"P2"},{"id":30,"title":"Runtime Receipt vs App Receipt","description":"разделить receipt от runtime о запросе/approval и receipt от app о фактической мутации ресурса.","category":"Receipts / audit / provenance","side":"right","anchors":[{"heading":"Receipt","anchorId":"receipt"},{"heading":"Runtime Receipt","anchorId":"runtime-receipt"},{"heading":"App Receipt","anchorId":"app-receipt"},{"heading":"Receipt Requirements","anchorId":"receipt-requirements"}],"status":"present","rationale":"Два типа receipts уже явно разделены по observed intent/policy и фактически committed/denied app mutation и связаны хешем.","priority":"P3"},{"id":31,"title":"Approval Receipt","description":"сделать approval/denial отдельным receipt, который можно связать с последующим write.","category":"Receipts / audit / provenance","side":"left","status":"partial","anchors":[{"heading":"Approval Semantics","anchorId":"approval-semantics"},{"heading":"Receipt Requirements","anchorId":"receipt-requirements"},{"heading":"Runtime Receipt","anchorId":"runtime-receipt"},{"heading":"App Receipt","anchorId":"app-receipt"}],"rationale":"Approval уже связан с action receipt, но отдельного receipt type для approve/deny нет.","priority":"P1"},{"id":32,"title":"Receipt Hash Chain","description":"добавить `parent_receipt_hash`, `trace_id`, `surface_hash`, `grant_hash`, `policy_decision_hash`.","category":"Receipts / audit / provenance","side":"right","status":"partial","anchors":[{"heading":"Receipt Requirements","anchorId":"receipt-requirements"},{"heading":"Runtime Receipt","anchorId":"runtime-receipt"},{"heading":"App Receipt","anchorId":"app-receipt"},{"heading":"Receipt Forgery","anchorId":"receipt-forgery"}],"rationale":"Есть связь app receipt с runtime receipt и hash входов/выходов, но нет общей цепочки и требуемых hash/trace полей.","priority":"P1"},{"id":33,"title":"Receipt Signing Profile","description":"оставить MVP unsigned, но заранее определить будущий профиль canonicalization + signatures.","category":"Receipts / audit / provenance","side":"left","status":"partial","anchors":[{"heading":"Receipts","anchorId":"receipts"},{"heading":"App Receipt","anchorId":"app-receipt"},{"heading":"Receipt Forgery","anchorId":"receipt-forgery"},{"heading":"Open Questions","anchorId":"open-questions"}],"rationale":"Подпись и canonicalization отложены на future draft; профиль и алгоритмы не определены.","priority":"P2"},{"id":34,"title":"Denied Action Receipts","description":"логировать не только успешные writes, но и важные deny/fail decisions.","category":"Receipts / audit / provenance","side":"right","status":"present","anchors":[{"heading":"Receipts Are First-Class","anchorId":"receipts-are-first-class"},{"heading":"Receipt Requirements","anchorId":"receipt-requirements"},{"heading":"Runtime Receipt","anchorId":"runtime-receipt"},{"heading":"App Receipt","anchorId":"app-receipt"}],"rationale":"Требование уже закреплено как design principle, app semantics и conformance requirement.","priority":"P2"},{"id":35,"title":"Policy Decision Object","description":"стандартизировать объяснимый объект `policy.decision` с reason code, matched rules и safe-to-show текстом.","category":"Receipts / audit / provenance","side":"left","status":"partial","anchors":[{"heading":"Approval Semantics","anchorId":"approval-semantics"},{"heading":"Runtime Receipt","anchorId":"runtime-receipt"},{"heading":"App Receipt","anchorId":"app-receipt"},{"heading":"Error Model","anchorId":"error-model"}],"rationale":"Policy decisions упомянуты, но нет типизированного policy.decision с codes, matched rules и safe text.","priority":"P1"},{"id":36,"title":"Data Exposure Contract","description":"для каждого resource/action описывать, какие классы данных агент увидит и какие redaction/retention правила применяются.","category":"Privacy / data exposure","side":"right","status":"partial","anchors":[{"heading":"Resources","anchorId":"resources"},{"heading":"Actions","anchorId":"actions"},{"heading":"Privacy Considerations","anchorId":"privacy-considerations"}],"rationale":"Для resources есть redaction и retention hooks, но нет классов данных и per-action exposure contract.","priority":"P0"},{"id":37,"title":"Agent Training Use Policy","description":"явно указывать, можно ли agent/provider использовать данные для обучения или только для transient processing.","category":"Privacy / data exposure","side":"left","status":"missing","anchors":[{"heading":"Privacy Considerations","anchorId":"privacy-considerations"}],"rationale":"Training, model improvement и transient-only processing в RFC не рассматриваются.","priority":"P2"},{"id":38,"title":"Remote Agent Restrictions","description":"различать local, enterprise-managed и remote user-selected agents с разными data exposure defaults.","category":"Privacy / data exposure","side":"right","status":"partial","anchors":[{"heading":"User-Owned Agent","anchorId":"user-owned-agent"},{"heading":"Runtime","anchorId":"runtime"},{"heading":"Malicious or Compromised Application","anchorId":"malicious-or-compromised-application"},{"heading":"Privacy Considerations","anchorId":"privacy-considerations"}],"rationale":"Deployment locations перечислены, но для local, managed и remote agents не заданы разные exposure defaults.","priority":"P2"},{"id":39,"title":"Pseudonymous Receipts","description":"разрешить receipts со стабильными псевдонимами пользователя вместо раскрытия реального user id.","category":"Privacy / data exposure","side":"left","status":"present","anchors":[{"heading":"Receipt Requirements","anchorId":"receipt-requirements"},{"heading":"Privacy Considerations","anchorId":"privacy-considerations"}],"rationale":"Stable pseudonymous user references уже явно разрешены в receipts и privacy requirements.","priority":"P2"},{"id":40,"title":"Secrets Boundary","description":"определить, что secrets, tokens, cookies и private credentials не попадают в agent-visible context без отдельного privileged grant.","category":"Privacy / data exposure","side":"right","status":"present","anchors":[{"heading":"Agent Does Not Receive Raw Authority","anchorId":"agent-does-not-receive-raw-authority"},{"heading":"Grant Verification","anchorId":"grant-verification"},{"heading":"Raw Token Leakage","anchorId":"raw-token-leakage"},{"heading":"Privacy Considerations","anchorId":"privacy-considerations"}],"rationale":"Secrets и credentials остаются вне agent-visible context; `credential.release` допускает только новый attenuated non-Surface credential с обязательным rejection на Agent Surface endpoints.","priority":"P0"},{"id":41,"title":"Runtime Identity Classes","description":"описать `registered_device`, `spiffe`, `oidc_workload`, `hardware_attested`, `enterprise_managed`.","category":"Runtime / Agent Passport / identity","side":"left","status":"missing","anchors":[{"heading":"Runtime","anchorId":"runtime"},{"heading":"Grant Object","anchorId":"grant-object"},{"heading":"Error Model","anchorId":"error-model"},{"heading":"Open Questions","anchorId":"open-questions"}],"rationale":"Runtime описан концептуально, но registered_device, SPIFFE, OIDC workload и другие identity classes отсутствуют.","priority":"P2"},{"id":42,"title":"Minimal Agent Passport Profile","description":"определить минимальный набор passport fields, достаточный для grant issuance.","category":"Runtime / Agent Passport / identity","side":"right","status":"missing","anchors":[{"heading":"Agent Passport","anchorId":"agent-passport"},{"heading":"Grant Object","anchorId":"grant-object"},{"heading":"Application Runtime Profile","anchorId":"application-runtime-profile"},{"heading":"Open Questions","anchorId":"open-questions"}],"rationale":"Набор обязательных passport fields не определён и прямо оставлен open question.","priority":"P0"},{"id":43,"title":"Passport Revocation Handling","description":"уточнить, что происходит с grants и active sessions при истечении или отзыве паспорта.","category":"Runtime / Agent Passport / identity","side":"left","status":"present","anchors":[{"heading":"Agent Passport Revoked or Expired","anchorId":"agent-passport-revoked-or-expired"},{"heading":"Grant Revoked","anchorId":"grant-revoked"},{"heading":"Grant Verification","anchorId":"grant-verification"}],"rationale":"RFC уже задаёт поведение для новых запусков, active sessions и связанных grants.","priority":"P1"},{"id":44,"title":"Capability Matching Output","description":"стандартизировать результат matching: compatible agents, missing capabilities, risks, required scopes, required approvals.","category":"Runtime / Agent Passport / identity","side":"right","status":"partial","anchors":[{"heading":"Capability Matching","anchorId":"capability-matching"}],"rationale":"Все требуемые смысловые outputs перечислены, но нет нормативного wire object или schema.","priority":"P2"},{"id":45,"title":"Runtime Attestation Optional Profile","description":"добавить future profile для подтверждения integrity runtime, но не требовать его в MVP.","category":"Runtime / Agent Passport / identity","side":"left","status":"partial","anchors":[{"heading":"Malicious or Compromised Runtime","anchorId":"malicious-or-compromised-runtime"},{"heading":"Error Model","anchorId":"error-model"},{"heading":"Open Questions","anchorId":"open-questions"}],"rationale":"Attestation предусмотрена как возможность и open question, но optional profile и MVP boundary не описаны.","priority":"P2"},{"id":46,"title":"Consent Preview","description":"runtime должен показывать пользователю понятное резюме grant: app, agent, scopes, resources, duration, writes, data exposure.","category":"UX / consent","side":"right","status":"partial","anchors":[{"heading":"Grant Lifecycle","anchorId":"grant-lifecycle"},{"heading":"Capability Matching","anchorId":"capability-matching"},{"heading":"Malicious or Compromised Application","anchorId":"malicious-or-compromised-application"},{"heading":"Example End-to-End Flow","anchorId":"example-end-to-end-flow"}],"rationale":"Есть хороший пример consent summary, но нет полного нормативного contract, особенно для data exposure.","priority":"P0"},{"id":47,"title":"Impact Simulation","description":"consent screen может показывать примеры allowed и denied действий для снижения consent fatigue.","category":"UX / consent","side":"left","status":"missing","anchors":[{"heading":"Capability Matching","anchorId":"capability-matching"},{"heading":"Example End-to-End Flow","anchorId":"example-end-to-end-flow"}],"rationale":"Consent flow не показывает simulated allowed/denied examples или прогноз impact.","priority":"P3"},{"id":48,"title":"Risk Explanation UI Hints","description":"manifest может включать human-readable risk summaries для actions.","category":"UX / consent","side":"right","status":"partial","anchors":[{"heading":"Actions","anchorId":"actions"},{"heading":"Risk Taxonomy","anchorId":"risk-taxonomy"},{"heading":"Capability Matching","anchorId":"capability-matching"}],"rationale":"Machine-readable risk labels и matching summary есть, human-readable manifest hints отсутствуют.","priority":"P2"},{"id":49,"title":"Default Proposal-First UX","description":"пользовательский flow должен сначала позволять agent propose, а не write.","category":"UX / consent","side":"left","status":"present","anchors":[{"heading":"Proposal Mode Is the Default","anchorId":"proposal-mode-is-the-default"},{"heading":"Proposal-Only Support","anchorId":"proposal-only-support"},{"heading":"Proposal Flow","anchorId":"proposal-flow"}],"rationale":"Proposal-first уже закреплён как design principle и RECOMMENDED integration flow.","priority":"P1"},{"id":50,"title":"Revocation UX Contract","description":"определить, где пользователь видит активные grants и как быстро может их отозвать.","category":"UX / consent","side":"right","status":"partial","anchors":[{"heading":"Endpoints","anchorId":"endpoints"},{"heading":"Revocation Semantics","anchorId":"revocation-semantics"},{"heading":"Grant Revoked","anchorId":"grant-revoked"},{"heading":"Malicious or Compromised Application","anchorId":"malicious-or-compromised-application"}],"rationale":"Protocol plumbing и post-revocation behavior есть, но active-grants UI и latency expectation не определены.","priority":"P1"},{"id":51,"title":"Budget Caveats","description":"добавить в grant constraints лимиты по cost, tokens, runtime seconds, tool calls, write actions и parallel sessions.","category":"Economics / limits / operations","side":"left","status":"partial","anchors":[{"heading":"Capability Lease","anchorId":"capability-lease"},{"heading":"Grant Object","anchorId":"grant-object"},{"heading":"Grant Verification","anchorId":"grant-verification"},{"heading":"Malicious or Compromised Agent","anchorId":"malicious-or-compromised-agent"}],"rationale":"Action и cost budgets есть; token, runtime, tool-call, write и parallel-session limits отсутствуют.","priority":"P1"},{"id":52,"title":"Budget Events","description":"стандартизировать `budget.warning`, `budget.exceeded`, `session.paused_budget`.","category":"Economics / limits / operations","side":"right","status":"missing","anchors":[{"heading":"Events","anchorId":"events"},{"heading":"Grant Revoked","anchorId":"grant-revoked"}],"rationale":"Event mechanism существует, но budget.warning, budget.exceeded и session.paused_budget не определены.","priority":"P2"},{"id":53,"title":"Rate Limits and Quotas","description":"surface должен объявлять ограничения на actions/events, чтобы runtime мог планировать нагрузку.","category":"Economics / limits / operations","side":"left","status":"missing","anchors":[{"heading":"Required Top-Level Fields","anchorId":"required-top-level-fields"},{"heading":"Actions","anchorId":"actions"},{"heading":"Events","anchorId":"events"}],"rationale":"Manifest не имеет rate-limit или quota declarations для actions и event delivery.","priority":"P2"},{"id":54,"title":"Runaway Loop Protection","description":"runtime должен иметь обязательные guards на повторяющиеся действия, retries и event-triggered loops.","category":"Economics / limits / operations","side":"right","status":"partial","anchors":[{"heading":"Every Write Is Idempotent","anchorId":"every-write-is-idempotent"},{"heading":"Grant Verification","anchorId":"grant-verification"},{"heading":"Malicious or Compromised Agent","anchorId":"malicious-or-compromised-agent"},{"heading":"Replay and Duplicate Actions","anchorId":"replay-and-duplicate-actions"}],"rationale":"Idempotency и общие limits снижают ущерб, но обязательных repeat/retry/event-loop guards нет.","priority":"P0"},{"id":55,"title":"Observability Fields","description":"добавить trace/span/session ids, чтобы ASP действия связывались с app logs, runtime logs и receipts.","category":"Economics / limits / operations","side":"left","status":"partial","anchors":[{"heading":"Sessions and Actions","anchorId":"sessions-and-actions"},{"heading":"Action Request","anchorId":"action-request"},{"heading":"Receipt Requirements","anchorId":"receipt-requirements"},{"heading":"Agent Adapter","anchorId":"agent-adapter"}],"rationale":"Session correlation присутствует, но trace_id, span_id и сквозная observability semantics отсутствуют.","priority":"P2"},{"id":56,"title":"Conformance Profiles","description":"разделить conformance на Surface Publisher, Grant Issuer, Action Executor, Receipt Producer, Runtime Mediator и Agent Adapter.","category":"Conformance / tooling / adoption","side":"right","status":"partial","anchors":[{"heading":"Conformance","anchorId":"conformance"},{"heading":"Grant-Enforcing Application","anchorId":"grant-enforcing-application"},{"heading":"Application Runtime Profile","anchorId":"application-runtime-profile"},{"heading":"Agent Adapter","anchorId":"agent-adapter"}],"rationale":"Role profiles уже есть, но Grant Issuer и Action Executor объединены, а именование ролей не унифицировано.","priority":"P2"},{"id":57,"title":"ASP Manifest Linter","description":"сделать tooling, который проверяет missing schemas, missing risk labels, missing idempotency и inconsistent scopes.","category":"Conformance / tooling / adoption","side":"left","status":"missing","anchors":[{"heading":"Required Top-Level Fields","anchorId":"required-top-level-fields"},{"heading":"Resources","anchorId":"resources"},{"heading":"Actions","anchorId":"actions"},{"heading":"Surface-Only Application","anchorId":"surface-only-application"}],"rationale":"Проверяемые требования существуют, но linter, ruleset и diagnostics contract отсутствуют.","priority":"P3"},{"id":58,"title":"Mock App / Mock Runtime","description":"дать reference fixtures для тестирования приложений и runtimes без реального агента.","category":"Conformance / tooling / adoption","side":"right","status":"missing","anchors":[{"heading":"Conceptual Architecture","anchorId":"conceptual-architecture"},{"heading":"Application MVP Mapping","anchorId":"application-mvp-mapping"},{"heading":"Example End-to-End Flow","anchorId":"example-end-to-end-flow"}],"rationale":"Есть architecture и implementation roadmap, но reference fixtures или mock implementations не заявлены.","priority":"P3"},{"id":59,"title":"Replay Tool","description":"добавить формат, позволяющий воспроизвести session/events/receipts для debugging и audit.","category":"Conformance / tooling / adoption","side":"left","status":"missing","anchors":[{"heading":"Events","anchorId":"events"},{"heading":"Sessions and Actions","anchorId":"sessions-and-actions"},{"heading":"Receipts","anchorId":"receipts"},{"heading":"Application MVP Mapping","anchorId":"application-mvp-mapping"}],"rationale":"Session/event/receipt primitives есть, но portable replay bundle format и tool отсутствуют.","priority":"P3"},{"id":60,"title":"Interop Test Suite","description":"подготовить набор обязательных тестов для grant verification, idempotency conflicts, revocation, receipts и denied actions.","category":"Conformance / tooling / adoption","side":"right","status":"missing","anchors":[{"heading":"Idempotency","anchorId":"idempotency"},{"heading":"Grant Verification","anchorId":"grant-verification"},{"heading":"Revocation Semantics","anchorId":"revocation-semantics"},{"heading":"Conformance","anchorId":"conformance"}],"rationale":"Нормативные области для тестов определены, но обязательных test cases и interop suite нет.","priority":"P2"}];
+  const reviews = [{"id":1,"title":"Reference Monitor Invariants","description":"явно зафиксировать, что все app-действия агента должны проходить через runtime, а агент не получает прямую authority по умолчанию.","category":"Security / authority boundary","side":"left","anchors":[{"heading":"Abstract","anchorId":"abstract"},{"heading":"App Exposes, Runtime Mediates, Agent Executes","anchorId":"app-exposes-runtime-mediates-agent-executes"},{"heading":"Agent Does Not Receive Raw Authority","anchorId":"agent-does-not-receive-raw-authority"},{"heading":"Application Runtime Profile","anchorId":"application-runtime-profile"}],"status":"present","rationale":"RFC теперь определяет runtime как reference monitor: каждое agent-initiated действие к Agent Surface проходит через runtime, а app-side verification остаётся обязательной.","priority":"P0"},{"id":2,"title":"Grant Credential Binding","description":"описать, чем именно runtime доказывает app, что grant принадлежит конкретному runtime/agent/passport tuple.","category":"Security / authority boundary","side":"right","anchors":[{"heading":"Agent Grant","anchorId":"agent-grant-2"},{"heading":"Grant Object","anchorId":"grant-object"},{"heading":"Grant Credentials and Proof","anchorId":"grant-credentials-and-proof"},{"heading":"Grant Verification","anchorId":"grant-verification"}],"status":"present","rationale":"RFC требует app-verifiable binding grant credential к grant, audience, runtime, agent и passport hash; introspection и session profiles не могут подменяться runtime assertion.","priority":"P0"},{"id":3,"title":"Sender-Constrained Grants","description":"поддержать DPoP, mTLS, workload identity или аналог, чтобы украденный bearer-token не давал полномочий сам по себе.","category":"Security / authority boundary","side":"left","anchors":[{"heading":"Grant Credential","anchorId":"grant-credential"},{"heading":"Grant Credentials and Proof","anchorId":"grant-credentials-and-proof"},{"heading":"Action Request","anchorId":"action-request"},{"heading":"Stolen Grant Credential","anchorId":"stolen-grant-credential"},{"heading":"Proof-Bound Grant-Enforcing Application","anchorId":"proof-bound-grant-enforcing-application"}],"status":"present","rationale":"Proof-Bound Credential и Proof-Bound Grant-Enforcing profiles требуют per-request possession proof; DPoP, mTLS и server-session проверки имеют отдельную корректную replay semantics.","priority":"P0"},{"id":4,"title":"Credential Release Policy","description":"сделать выдачу raw app token агенту отдельной privileged capability, запрещённой по умолчанию.","category":"Security / authority boundary","side":"right","anchors":[{"heading":"Agent Does Not Receive Raw Authority","anchorId":"agent-does-not-receive-raw-authority"},{"heading":"Grant Verification","anchorId":"grant-verification"},{"heading":"Raw Token Leakage","anchorId":"raw-token-leakage"},{"heading":"Agent Adapter","anchorId":"agent-adapter"}],"status":"present","rationale":"Raw credential release — default-deny capability `credential.release`; выдаётся только новый attenuated credential для non-Agent-Surface audience, который app обязана отклонять на Surface endpoints.","priority":"P0"},{"id":5,"title":"Subdelegation Rules","description":"явно описать, может ли агент вызывать субагентов, remote models, MCP servers или другие runtimes.","category":"Security / authority boundary","side":"left","anchors":[{"heading":"Runtime","anchorId":"runtime"},{"heading":"Subdelegation","anchorId":"subdelegation"},{"heading":"Model Context Protocol","anchorId":"model-context-protocol"},{"heading":"4. Agent Adapter Protocol","anchorId":"4-agent-adapter-protocol"},{"heading":"Malicious or Compromised Agent","anchorId":"malicious-or-compromised-agent"}],"status":"present","rationale":"Компоненты без отдельного grant проходят parent runtime; отдельно granted child runtime использует собственный binding и direct app route, с parent linkage, attenuation и cascade revocation.","priority":"P0"},{"id":6,"title":"App-Side Enforcement Requirements","description":"закрепить, что app обязана проверять grant на каждое действие, а не доверять runtime assertion.","category":"Security / authority boundary","side":"right","anchors":[{"heading":"App-Side Enforcement Is Mandatory","anchorId":"app-side-enforcement-is-mandatory"},{"heading":"Model A: App-Issued Grant","anchorId":"model-a-app-issued-grant"},{"heading":"Grant Verification","anchorId":"grant-verification"},{"heading":"Malicious or Compromised Runtime","anchorId":"malicious-or-compromised-runtime"}],"status":"present","rationale":"Спецификация уже требует app-verifiable authorization для каждого действия и запрещает доверять одному runtime assertion.","priority":"P3"},{"id":7,"title":"OAuth RAR Profile","description":"описать Agent Grant как профиль OAuth Rich Authorization Requests через `authorization_details`.","category":"Grant / OAuth / authorization model","side":"left","anchors":[{"heading":"OAuth","anchorId":"oauth"},{"heading":"OAuth Grant Lifecycle Profile","anchorId":"oauth-grant-lifecycle-profile"},{"heading":"Rich Authorization Request Profile","anchorId":"rich-authorization-request-profile"},{"heading":"Agent Grant","anchorId":"agent-grant-2"},{"heading":"Grant Object","anchorId":"grant-object"},{"heading":"Grant Issuance Models","anchorId":"grant-issuance-models"}],"status":"present","rationale":"RFC задаёт collision-resistant Agent Grant authorization-details type, обязательные поля, consent/subset semantics, ошибки RFC 9396 и возврат authoritative granted object.","priority":"P2"},{"id":8,"title":"OAuth Token Exchange Profile","description":"добавить путь, где user/app session обменивается на constrained agent grant token.","category":"Grant / OAuth / authorization model","side":"right","anchors":[{"heading":"OAuth","anchorId":"oauth"},{"heading":"OAuth Token Exchange Profile","anchorId":"oauth-token-exchange-profile"},{"heading":"Grant Issuance Models","anchorId":"grant-issuance-models"},{"heading":"Model A: App-Issued Grant","anchorId":"model-a-app-issued-grant"},{"heading":"Grant Credentials and Proof","anchorId":"grant-credentials-and-proof"}],"status":"present","rationale":"RFC профилирует RFC 8693 request/response, runtime/actor authentication, resource restriction, attenuation, proof binding и explicit derivation/revocation linkage.","priority":"P2"},{"id":9,"title":"Grant Proof vs Grant ID","description":"явно сказать, что `grant_id` — это идентификатор, а не authority без credential/proof.","category":"Grant / OAuth / authorization model","side":"left","anchors":[{"heading":"Grant Credential","anchorId":"grant-credential"},{"heading":"Grant Identifier Is Not Authority","anchorId":"grant-identifier-is-not-authority"},{"heading":"Grant Credentials and Proof","anchorId":"grant-credentials-and-proof"},{"heading":"Action Request","anchorId":"action-request"}],"status":"present","rationale":"Текст прямо и нормативно определяет grant_id как correlation identifier, а не authority.","priority":"P3"},{"id":10,"title":"Grant Hash","description":"добавить канонический `grant_hash`, чтобы receipts и audit ссылались на конкретное содержимое grant.","category":"Grant / OAuth / authorization model","side":"right","anchors":[{"heading":"Grant Hash","anchorId":"grant-hash"},{"heading":"Canonical Object Hash Profile","anchorId":"canonical-object-hash-profile"},{"heading":"Action Request","anchorId":"action-request"},{"heading":"Receipt Hash Chain","anchorId":"receipt-hash-chain"}],"status":"present","rationale":"RFC определяет canonical grant_hash над authoritative Grant Object, связывает его с action context и receipts и требует отклонять несовпадение с текущим grant state.","priority":"P1"},{"id":11,"title":"Grant Introspection Contract","description":"определить минимальный ответ introspection endpoint: active, scopes, constraints, runtime, agent, passport hash, expiry.","category":"Grant / OAuth / authorization model","side":"left","anchors":[{"heading":"OAuth","anchorId":"oauth"},{"heading":"Grant Introspection Profile","anchorId":"grant-introspection-profile"},{"heading":"Endpoints","anchorId":"endpoints"},{"heading":"Grant Credentials and Proof","anchorId":"grant-credentials-and-proof"},{"heading":"Grant Verification","anchorId":"grant-verification"}],"status":"present","rationale":"RFC задаёт authenticated RFC 7662 request, privacy-preserving inactive response и минимальный active contract со scope, tuple, constraints, surface, expiry и credential binding.","priority":"P1"},{"id":12,"title":"Grant Revocation Events","description":"стандартизировать событие `grant.revoked` и поведение runtime/app при его получении.","category":"Grant / OAuth / authorization model","side":"right","anchors":[{"heading":"Event","anchorId":"event"},{"heading":"Events","anchorId":"events"},{"heading":"Revocation Semantics","anchorId":"revocation-semantics"},{"heading":"OAuth Grant Revocation Profile","anchorId":"oauth-grant-revocation-profile"},{"heading":"Grant Revoked","anchorId":"grant-revoked"}],"status":"present","rationale":"RFC определяет RFC 7009 grant transition, cascade revocation, authenticated `grant.revoked` envelope, reason codes, idempotent runtime processing и границу с общей event delivery model.","priority":"P1"},{"id":13,"title":"Wire-Level Endpoints","description":"добавить в manifest явные URLs для action requests, grant request/introspection/revocation, events и receipts.","category":"Agent Surface Manifest","side":"left","anchors":[{"heading":"Agent Surface Manifest","anchorId":"agent-surface-manifest-2"},{"heading":"Endpoints","anchorId":"endpoints"},{"heading":"Example Manifest","anchorId":"example-manifest"},{"heading":"Discovery","anchorId":"discovery"}],"status":"present","rationale":"Manifest уже объявляет grant request/introspection/revocation, actions, events и receipts URLs.","priority":"P3"},{"id":14,"title":"Surface Hash","description":"добавить `surface_hash`, чтобы runtime и receipts ссылались не только на версию, но и на точный surface contract.","category":"Agent Surface Manifest","side":"right","anchors":[{"heading":"Surface Hash","anchorId":"surface-hash"},{"heading":"Canonical Object Hash Profile","anchorId":"canonical-object-hash-profile"},{"heading":"Grant Object","anchorId":"grant-object"},{"heading":"Surface Downgrade","anchorId":"surface-downgrade"}],"status":"present","rationale":"RFC определяет canonical surface_hash над точным manifest object, связывает его с grant и receipts, требует отклонять подмену/downgrade и явно отделяет внешнее содержимое schema URLs.","priority":"P1"},{"id":15,"title":"Surface Version Compatibility Rules","description":"формализовать, какие изменения surface breaking, а какие non-breaking.","category":"Agent Surface Manifest","side":"left","anchors":[{"heading":"Surface Version Changed","anchorId":"surface-version-changed"},{"heading":"Versioning and Compatibility","anchorId":"versioning-and-compatibility"}],"status":"present","rationale":"Breaking и non-breaking изменения уже классифицированы, включая schema, actions, risks, receipts и endpoint semantics.","priority":"P3"},{"id":16,"title":"Agent Surface Is Not Full API","description":"подчеркнуть, что surface — curated affordance layer, а не зеркало всего public/private API приложения.","category":"Agent Surface Manifest","side":"right","anchors":[{"heading":"Non-Goals","anchorId":"non-goals"},{"heading":"Agent Surface","anchorId":"agent-surface"},{"heading":"Model Context Protocol","anchorId":"model-context-protocol"},{"heading":"Application MVP Mapping","anchorId":"application-mvp-mapping"}],"status":"partial","rationale":"Surface отделён от API endpoint list и не заменяет existing APIs, но curated/selective exposure и запрет зеркалирования API не сформулированы явно.","priority":"P2"},{"id":17,"title":"OpenAPI / AsyncAPI Extensions","description":"разрешить генерировать Agent Surface из существующих API specs через `x-agent-surface` аннотации.","category":"Agent Surface Manifest","side":"left","anchors":[{"heading":"Agent Surface Manifest","anchorId":"agent-surface-manifest-2"},{"heading":"Resources","anchorId":"resources"},{"heading":"Actions","anchorId":"actions"},{"heading":"Events","anchorId":"events"}],"status":"missing","rationale":"JSON Schema URLs поддерживаются, но import/generation и x-agent-surface annotations для OpenAPI/AsyncAPI отсутствуют.","priority":"P3"},{"id":18,"title":"Proposal-Only Surface Mode","description":"дать app способ объявить, что агенты могут только предлагать изменения, но не делать writes напрямую.","category":"Agent Surface Manifest","side":"right","anchors":[{"heading":"Proposal Mode Is the Default","anchorId":"proposal-mode-is-the-default"},{"heading":"Proposal-Only Support","anchorId":"proposal-only-support"},{"heading":"Proposal Flow","anchorId":"proposal-flow"},{"heading":"Surface-Only Application","anchorId":"surface-only-application"}],"status":"partial","rationale":"Proposal-only actions полностью описаны, но нет формального top-level surface mode, запрещающего все direct writes.","priority":"P1"},{"id":19,"title":"Action Execution Modes","description":"добавить стандартные modes: `read`, `dry_run`, `propose`, `reserve`, `commit`, `compensate`, `revert`.","category":"Action semantics","side":"left","anchors":[{"heading":"Actions","anchorId":"actions"},{"heading":"Proposal-Only Support","anchorId":"proposal-only-support"},{"heading":"Risk Taxonomy","anchorId":"risk-taxonomy"},{"heading":"Proposal Flow","anchorId":"proposal-flow"}],"status":"partial","rationale":"Есть direct, write и proposal_only, но единая stateful модель read/dry_run/reserve/commit/compensate/revert отсутствует.","priority":"P1"},{"id":20,"title":"Effect Model","description":"дополнить risk taxonomy описанием эффекта: public/private, reversible/irreversible, internal/external, financial/security/deployment/etc.","category":"Action semantics","side":"right","anchors":[{"heading":"Actions","anchorId":"actions"},{"heading":"Risk Taxonomy","anchorId":"risk-taxonomy"},{"heading":"Approval Semantics","anchorId":"approval-semantics"},{"heading":"Security Considerations","anchorId":"security-considerations"}],"status":"partial","rationale":"Risk labels покрывают часть эффектов, но независимые dimensions visibility, reversibility, boundary и effect domain не моделируются.","priority":"P1"},{"id":21,"title":"Idempotency Normalization","description":"определить, как нормализуется input для проверки повторного idempotency key.","category":"Action semantics","side":"left","anchors":[{"heading":"Every Write Is Idempotent","anchorId":"every-write-is-idempotent"},{"heading":"Idempotency","anchorId":"idempotency"},{"heading":"Replay and Duplicate Actions","anchorId":"replay-and-duplicate-actions"}],"status":"partial","rationale":"RFC задаёт canonical hash точного wire input для receipt binding, но semantic normalization, defaults, set ordering и schema equivalence для idempotency остаются action-specific.","priority":"P1"},{"id":22,"title":"Preconditions and Effects Schemas","description":"дать actions схемы для preconditions и expected effects, чтобы runtime мог показать impact до commit.","category":"Action semantics","side":"right","anchors":[{"heading":"Actions","anchorId":"actions"},{"heading":"Action Request","anchorId":"action-request"},{"heading":"Action Response","anchorId":"action-response"},{"heading":"Proposal Flow","anchorId":"proposal-flow"}],"status":"missing","rationale":"Action model содержит input/output schemas, но не preconditions_schema, expected_effects_schema или impact preview.","priority":"P1"},{"id":23,"title":"Resource Lease / Reservation","description":"добавить lease model для задач, tickets, branch names и других ресурсов, чтобы несколько агентов не делали одно и то же.","category":"Action semantics","side":"left","anchors":[{"heading":"Capability Lease","anchorId":"capability-lease"},{"heading":"Resources","anchorId":"resources"},{"heading":"Actions","anchorId":"actions"},{"heading":"Sessions and Actions","anchorId":"sessions-and-actions"}],"status":"missing","rationale":"Capability Lease относится к authorization grant; protocol-level reservation конкретных ресурсов и conflict semantics отсутствуют.","priority":"P2"},{"id":24,"title":"Compensation Semantics","description":"описать, какие действия можно откатить и какой action является компенсацией.","category":"Action semantics","side":"right","anchors":[{"heading":"Actions","anchorId":"actions"},{"heading":"Risk Taxonomy","anchorId":"risk-taxonomy"},{"heading":"Proposal Flow","anchorId":"proposal-flow"},{"heading":"Receipts","anchorId":"receipts"}],"status":"missing","rationale":"Reversibility частично отражена риском destructive, но compensation/revert action linkage и гарантии отката не определены.","priority":"P1"},{"id":25,"title":"CloudEvents Binding","description":"сделать app events совместимыми с CloudEvents или определить эквивалентный envelope.","category":"Events / sessions / AHP","side":"left","anchors":[{"heading":"Event","anchorId":"event"},{"heading":"3. Runtime Bridge Protocol","anchorId":"3-runtime-bridge-protocol"},{"heading":"Events","anchorId":"events"},{"heading":"Sessions and Actions","anchorId":"sessions-and-actions"}],"status":"missing","rationale":"ASP определяет typed events со schema и scope, но CloudEvents envelope или эквивалентный canonical envelope отсутствует.","priority":"P2"},{"id":26,"title":"Event Delivery Semantics","description":"описать at-least-once delivery, ordering, replay cursor, retention, ack и backpressure.","category":"Events / sessions / AHP","side":"right","anchors":[{"heading":"Conceptual Architecture","anchorId":"conceptual-architecture"},{"heading":"3. Runtime Bridge Protocol","anchorId":"3-runtime-bridge-protocol"},{"heading":"Events","anchorId":"events"},{"heading":"Runtime Disconnected","anchorId":"runtime-disconnected"}],"status":"missing","rationale":"Transport hints присутствуют, но delivery guarantee, ordering, cursor, replay, retention, ack и backpressure не определены.","priority":"P1"},{"id":27,"title":"ASP-over-AHP Binding","description":"описать профиль, где AHP несёт session/UI state, а ASP-объекты остаются authority для grants/actions/receipts.","category":"Events / sessions / AHP","side":"left","anchors":[{"heading":"Agent Client Protocol","anchorId":"agent-client-protocol"},{"heading":"3. Runtime Bridge Protocol","anchorId":"3-runtime-bridge-protocol"},{"heading":"Sessions and Actions","anchorId":"sessions-and-actions"},{"heading":"Receipts","anchorId":"receipts"}],"status":"missing","rationale":"Разделение transport и ASP semantics уже намечено для ACP/runtime bridge, но AHP binding нигде не определён.","priority":"P2"},{"id":28,"title":"Session Ownership Model","description":"уточнить, кто может стартовать, наблюдать, отменять и возобновлять session: user, app, runtime или agent.","category":"Events / sessions / AHP","side":"right","anchors":[{"heading":"3. Runtime Bridge Protocol","anchorId":"3-runtime-bridge-protocol"},{"heading":"Session Start","anchorId":"session-start"},{"heading":"Runtime Disconnected","anchorId":"runtime-disconnected"},{"heading":"User Session Expired","anchorId":"user-session-expired"}],"status":"partial","rationale":"App или runtime MAY start session, а cancel/resume упомянуты, но права start/observe/cancel/resume по ролям не формализованы.","priority":"P1"},{"id":29,"title":"Human Elicitation Events","description":"добавить не только approve/deny, но и clarify, choose option, edit proposal, redline diff, step-up auth.","category":"Events / sessions / AHP","side":"left","anchors":[{"heading":"3. Runtime Bridge Protocol","anchorId":"3-runtime-bridge-protocol"},{"heading":"Approval Semantics","anchorId":"approval-semantics"},{"heading":"Proposal Flow","anchorId":"proposal-flow"},{"heading":"Error Model","anchorId":"error-model"}],"status":"partial","rationale":"Есть approval required/resolved, но clarify, options, edit/redline и step-up auth message types отсутствуют.","priority":"P2"},{"id":30,"title":"Runtime Receipt vs App Receipt","description":"разделить receipt от runtime о запросе/approval и receipt от app о фактической мутации ресурса.","category":"Receipts / audit / provenance","side":"right","anchors":[{"heading":"Receipt","anchorId":"receipt"},{"heading":"Runtime Receipt","anchorId":"runtime-receipt"},{"heading":"App Receipt","anchorId":"app-receipt"},{"heading":"Receipt Requirements","anchorId":"receipt-requirements"}],"status":"present","rationale":"Два типа receipts уже явно разделены по observed intent/policy и фактически committed/denied app mutation и связаны хешем.","priority":"P3"},{"id":31,"title":"Approval Receipt","description":"сделать approval/denial отдельным receipt, который можно связать с последующим write.","category":"Receipts / audit / provenance","side":"left","status":"partial","anchors":[{"heading":"Approval Semantics","anchorId":"approval-semantics"},{"heading":"Receipt Requirements","anchorId":"receipt-requirements"},{"heading":"Runtime Receipt","anchorId":"runtime-receipt"},{"heading":"App Receipt","anchorId":"app-receipt"}],"rationale":"Approval уже связан с action receipt, но отдельного receipt type для approve/deny нет.","priority":"P1"},{"id":32,"title":"Receipt Hash Chain","description":"добавить `parent_receipt_hash`, `trace_id`, `surface_hash`, `grant_hash`, `policy_decision_hash`.","category":"Receipts / audit / provenance","side":"right","status":"present","anchors":[{"heading":"Receipt Hash Chain","anchorId":"receipt-hash-chain"},{"heading":"Runtime Receipt","anchorId":"runtime-receipt"},{"heading":"App Receipt","anchorId":"app-receipt"},{"heading":"Receipt Forgery","anchorId":"receipt-forgery"}],"rationale":"Runtime/App receipts образуют проверяемую цепочку через receipt_hash и parent_receipt_hash и несут surface_hash, grant_hash, policy_decision_hash и trace context.","priority":"P1"},{"id":33,"title":"Receipt Signing Profile","description":"оставить MVP unsigned, но заранее определить будущий профиль canonicalization + signatures.","category":"Receipts / audit / provenance","side":"left","status":"present","anchors":[{"heading":"Receipt Signing Profile","anchorId":"receipt-signing-profile"},{"heading":"Canonical Object Hash Profile","anchorId":"canonical-object-hash-profile"},{"heading":"App Receipt","anchorId":"app-receipt"},{"heading":"Receipt Forgery","anchorId":"receipt-forgery"}],"rationale":"RFC задаёт concrete JCS canonicalization и detached JWS profile, signing input, algorithm/key verification и downgrade behavior; unsigned receipts остаются допустимы в MVP.","priority":"P2"},{"id":34,"title":"Denied Action Receipts","description":"логировать не только успешные writes, но и важные deny/fail decisions.","category":"Receipts / audit / provenance","side":"right","status":"present","anchors":[{"heading":"Receipts Are First-Class","anchorId":"receipts-are-first-class"},{"heading":"Receipt Requirements","anchorId":"receipt-requirements"},{"heading":"Runtime Receipt","anchorId":"runtime-receipt"},{"heading":"App Receipt","anchorId":"app-receipt"}],"rationale":"Требование уже закреплено как design principle, app semantics и conformance requirement.","priority":"P2"},{"id":35,"title":"Policy Decision Object","description":"стандартизировать объяснимый объект `policy.decision` с reason code, matched rules и safe-to-show текстом.","category":"Receipts / audit / provenance","side":"left","status":"present","anchors":[{"heading":"Policy Decision Object","anchorId":"policy-decision-object"},{"heading":"Runtime Receipt","anchorId":"runtime-receipt"},{"heading":"App Receipt","anchorId":"app-receipt"},{"heading":"Error Model","anchorId":"error-model"}],"rationale":"RFC задаёт типизированный policy.decision с outcome, reason_code, matched_rules, safe-to-show explanation, policy version и проверяемым policy_decision_hash.","priority":"P1"},{"id":36,"title":"Data Exposure Contract","description":"для каждого resource/action описывать, какие классы данных агент увидит и какие redaction/retention правила применяются.","category":"Privacy / data exposure","side":"right","status":"partial","anchors":[{"heading":"Resources","anchorId":"resources"},{"heading":"Actions","anchorId":"actions"},{"heading":"Privacy Considerations","anchorId":"privacy-considerations"}],"rationale":"Для resources есть redaction и retention hooks, но нет классов данных и per-action exposure contract.","priority":"P0"},{"id":37,"title":"Agent Training Use Policy","description":"явно указывать, можно ли agent/provider использовать данные для обучения или только для transient processing.","category":"Privacy / data exposure","side":"left","status":"missing","anchors":[{"heading":"Privacy Considerations","anchorId":"privacy-considerations"}],"rationale":"Training, model improvement и transient-only processing в RFC не рассматриваются.","priority":"P2"},{"id":38,"title":"Remote Agent Restrictions","description":"различать local, enterprise-managed и remote user-selected agents с разными data exposure defaults.","category":"Privacy / data exposure","side":"right","status":"partial","anchors":[{"heading":"User-Owned Agent","anchorId":"user-owned-agent"},{"heading":"Runtime","anchorId":"runtime"},{"heading":"Malicious or Compromised Application","anchorId":"malicious-or-compromised-application"},{"heading":"Privacy Considerations","anchorId":"privacy-considerations"}],"rationale":"Deployment locations перечислены, но для local, managed и remote agents не заданы разные exposure defaults.","priority":"P2"},{"id":39,"title":"Pseudonymous Receipts","description":"разрешить receipts со стабильными псевдонимами пользователя вместо раскрытия реального user id.","category":"Privacy / data exposure","side":"left","status":"present","anchors":[{"heading":"Receipt Requirements","anchorId":"receipt-requirements"},{"heading":"Privacy Considerations","anchorId":"privacy-considerations"}],"rationale":"Stable pseudonymous user references уже явно разрешены в receipts и privacy requirements.","priority":"P2"},{"id":40,"title":"Secrets Boundary","description":"определить, что secrets, tokens, cookies и private credentials не попадают в agent-visible context без отдельного privileged grant.","category":"Privacy / data exposure","side":"right","status":"present","anchors":[{"heading":"Agent Does Not Receive Raw Authority","anchorId":"agent-does-not-receive-raw-authority"},{"heading":"Grant Verification","anchorId":"grant-verification"},{"heading":"Raw Token Leakage","anchorId":"raw-token-leakage"},{"heading":"Privacy Considerations","anchorId":"privacy-considerations"}],"rationale":"Secrets и credentials остаются вне agent-visible context; `credential.release` допускает только новый attenuated non-Surface credential с обязательным rejection на Agent Surface endpoints.","priority":"P0"},{"id":41,"title":"Runtime Identity Classes","description":"описать `registered_device`, `spiffe`, `oidc_workload`, `hardware_attested`, `enterprise_managed`.","category":"Runtime / Agent Passport / identity","side":"left","status":"missing","anchors":[{"heading":"Runtime","anchorId":"runtime"},{"heading":"Grant Object","anchorId":"grant-object"},{"heading":"Error Model","anchorId":"error-model"},{"heading":"Open Questions","anchorId":"open-questions"}],"rationale":"Runtime описан концептуально, но registered_device, SPIFFE, OIDC workload и другие identity classes отсутствуют.","priority":"P2"},{"id":42,"title":"Minimal Agent Passport Profile","description":"определить минимальный набор passport fields, достаточный для grant issuance.","category":"Runtime / Agent Passport / identity","side":"right","status":"missing","anchors":[{"heading":"Agent Passport","anchorId":"agent-passport"},{"heading":"Grant Object","anchorId":"grant-object"},{"heading":"Application Runtime Profile","anchorId":"application-runtime-profile"},{"heading":"Open Questions","anchorId":"open-questions"}],"rationale":"Набор обязательных passport fields не определён и прямо оставлен open question.","priority":"P0"},{"id":43,"title":"Passport Revocation Handling","description":"уточнить, что происходит с grants и active sessions при истечении или отзыве паспорта.","category":"Runtime / Agent Passport / identity","side":"left","status":"present","anchors":[{"heading":"Agent Passport Revoked or Expired","anchorId":"agent-passport-revoked-or-expired"},{"heading":"Grant Revoked","anchorId":"grant-revoked"},{"heading":"Grant Verification","anchorId":"grant-verification"}],"rationale":"RFC уже задаёт поведение для новых запусков, active sessions и связанных grants.","priority":"P1"},{"id":44,"title":"Capability Matching Output","description":"стандартизировать результат matching: compatible agents, missing capabilities, risks, required scopes, required approvals.","category":"Runtime / Agent Passport / identity","side":"right","status":"partial","anchors":[{"heading":"Capability Matching","anchorId":"capability-matching"}],"rationale":"Все требуемые смысловые outputs перечислены, но нет нормативного wire object или schema.","priority":"P2"},{"id":45,"title":"Runtime Attestation Optional Profile","description":"добавить future profile для подтверждения integrity runtime, но не требовать его в MVP.","category":"Runtime / Agent Passport / identity","side":"left","status":"partial","anchors":[{"heading":"Malicious or Compromised Runtime","anchorId":"malicious-or-compromised-runtime"},{"heading":"Error Model","anchorId":"error-model"},{"heading":"Open Questions","anchorId":"open-questions"}],"rationale":"Attestation предусмотрена как возможность и open question, но optional profile и MVP boundary не описаны.","priority":"P2"},{"id":46,"title":"Consent Preview","description":"runtime должен показывать пользователю понятное резюме grant: app, agent, scopes, resources, duration, writes, data exposure.","category":"UX / consent","side":"right","status":"partial","anchors":[{"heading":"Grant Lifecycle","anchorId":"grant-lifecycle"},{"heading":"Capability Matching","anchorId":"capability-matching"},{"heading":"Malicious or Compromised Application","anchorId":"malicious-or-compromised-application"},{"heading":"Example End-to-End Flow","anchorId":"example-end-to-end-flow"}],"rationale":"Есть хороший пример consent summary, но нет полного нормативного contract, особенно для data exposure.","priority":"P0"},{"id":47,"title":"Impact Simulation","description":"consent screen может показывать примеры allowed и denied действий для снижения consent fatigue.","category":"UX / consent","side":"left","status":"missing","anchors":[{"heading":"Capability Matching","anchorId":"capability-matching"},{"heading":"Example End-to-End Flow","anchorId":"example-end-to-end-flow"}],"rationale":"Consent flow не показывает simulated allowed/denied examples или прогноз impact.","priority":"P3"},{"id":48,"title":"Risk Explanation UI Hints","description":"manifest может включать human-readable risk summaries для actions.","category":"UX / consent","side":"right","status":"partial","anchors":[{"heading":"Actions","anchorId":"actions"},{"heading":"Risk Taxonomy","anchorId":"risk-taxonomy"},{"heading":"Capability Matching","anchorId":"capability-matching"}],"rationale":"Machine-readable risk labels и matching summary есть, human-readable manifest hints отсутствуют.","priority":"P2"},{"id":49,"title":"Default Proposal-First UX","description":"пользовательский flow должен сначала позволять agent propose, а не write.","category":"UX / consent","side":"left","status":"present","anchors":[{"heading":"Proposal Mode Is the Default","anchorId":"proposal-mode-is-the-default"},{"heading":"Proposal-Only Support","anchorId":"proposal-only-support"},{"heading":"Proposal Flow","anchorId":"proposal-flow"}],"rationale":"Proposal-first уже закреплён как design principle и RECOMMENDED integration flow.","priority":"P1"},{"id":50,"title":"Revocation UX Contract","description":"определить, где пользователь видит активные grants и как быстро может их отозвать.","category":"UX / consent","side":"right","status":"partial","anchors":[{"heading":"Endpoints","anchorId":"endpoints"},{"heading":"Revocation Semantics","anchorId":"revocation-semantics"},{"heading":"Grant Revoked","anchorId":"grant-revoked"},{"heading":"Malicious or Compromised Application","anchorId":"malicious-or-compromised-application"}],"rationale":"Protocol plumbing и post-revocation behavior есть, но active-grants UI и latency expectation не определены.","priority":"P1"},{"id":51,"title":"Budget Caveats","description":"добавить в grant constraints лимиты по cost, tokens, runtime seconds, tool calls, write actions и parallel sessions.","category":"Economics / limits / operations","side":"left","status":"partial","anchors":[{"heading":"Capability Lease","anchorId":"capability-lease"},{"heading":"Grant Object","anchorId":"grant-object"},{"heading":"Grant Verification","anchorId":"grant-verification"},{"heading":"Malicious or Compromised Agent","anchorId":"malicious-or-compromised-agent"}],"rationale":"Action и cost budgets есть; token, runtime, tool-call, write и parallel-session limits отсутствуют.","priority":"P1"},{"id":52,"title":"Budget Events","description":"стандартизировать `budget.warning`, `budget.exceeded`, `session.paused_budget`.","category":"Economics / limits / operations","side":"right","status":"missing","anchors":[{"heading":"Events","anchorId":"events"},{"heading":"Grant Revoked","anchorId":"grant-revoked"}],"rationale":"Event mechanism существует, но budget.warning, budget.exceeded и session.paused_budget не определены.","priority":"P2"},{"id":53,"title":"Rate Limits and Quotas","description":"surface должен объявлять ограничения на actions/events, чтобы runtime мог планировать нагрузку.","category":"Economics / limits / operations","side":"left","status":"missing","anchors":[{"heading":"Required Top-Level Fields","anchorId":"required-top-level-fields"},{"heading":"Actions","anchorId":"actions"},{"heading":"Events","anchorId":"events"}],"rationale":"Manifest не имеет rate-limit или quota declarations для actions и event delivery.","priority":"P2"},{"id":54,"title":"Runaway Loop Protection","description":"runtime должен иметь обязательные guards на повторяющиеся действия, retries и event-triggered loops.","category":"Economics / limits / operations","side":"right","status":"partial","anchors":[{"heading":"Every Write Is Idempotent","anchorId":"every-write-is-idempotent"},{"heading":"Grant Verification","anchorId":"grant-verification"},{"heading":"Malicious or Compromised Agent","anchorId":"malicious-or-compromised-agent"},{"heading":"Replay and Duplicate Actions","anchorId":"replay-and-duplicate-actions"}],"rationale":"Idempotency и общие limits снижают ущерб, но обязательных repeat/retry/event-loop guards нет.","priority":"P0"},{"id":55,"title":"Observability Fields","description":"добавить trace/span/session ids, чтобы ASP действия связывались с app logs, runtime logs и receipts.","category":"Economics / limits / operations","side":"left","status":"present","anchors":[{"heading":"Observability Context","anchorId":"observability-context"},{"heading":"Sessions and Actions","anchorId":"sessions-and-actions"},{"heading":"Action Request","anchorId":"action-request"},{"heading":"Receipt Requirements","anchorId":"receipt-requirements"}],"rationale":"RFC задаёт W3C-compatible creation и propagation semantics для trace_id, span_id и session_id через sessions, actions, receipts и adapter/log context и отделяет correlation от authority.","priority":"P2"},{"id":56,"title":"Conformance Profiles","description":"разделить conformance на Surface Publisher, Grant Issuer, Action Executor, Receipt Producer, Runtime Mediator и Agent Adapter.","category":"Conformance / tooling / adoption","side":"right","status":"partial","anchors":[{"heading":"Conformance","anchorId":"conformance"},{"heading":"Grant-Enforcing Application","anchorId":"grant-enforcing-application"},{"heading":"Application Runtime Profile","anchorId":"application-runtime-profile"},{"heading":"Agent Adapter","anchorId":"agent-adapter"}],"rationale":"Role profiles уже есть, но Grant Issuer и Action Executor объединены, а именование ролей не унифицировано.","priority":"P2"},{"id":57,"title":"ASP Manifest Linter","description":"сделать tooling, который проверяет missing schemas, missing risk labels, missing idempotency и inconsistent scopes.","category":"Conformance / tooling / adoption","side":"left","status":"missing","anchors":[{"heading":"Required Top-Level Fields","anchorId":"required-top-level-fields"},{"heading":"Resources","anchorId":"resources"},{"heading":"Actions","anchorId":"actions"},{"heading":"Surface-Only Application","anchorId":"surface-only-application"}],"rationale":"Проверяемые требования существуют, но linter, ruleset и diagnostics contract отсутствуют.","priority":"P3"},{"id":58,"title":"Mock App / Mock Runtime","description":"дать reference fixtures для тестирования приложений и runtimes без реального агента.","category":"Conformance / tooling / adoption","side":"right","status":"missing","anchors":[{"heading":"Conceptual Architecture","anchorId":"conceptual-architecture"},{"heading":"Application MVP Mapping","anchorId":"application-mvp-mapping"},{"heading":"Example End-to-End Flow","anchorId":"example-end-to-end-flow"}],"rationale":"Есть architecture и implementation roadmap, но reference fixtures или mock implementations не заявлены.","priority":"P3"},{"id":59,"title":"Replay Tool","description":"добавить формат, позволяющий воспроизвести session/events/receipts для debugging и audit.","category":"Conformance / tooling / adoption","side":"left","status":"missing","anchors":[{"heading":"Events","anchorId":"events"},{"heading":"Sessions and Actions","anchorId":"sessions-and-actions"},{"heading":"Receipts","anchorId":"receipts"},{"heading":"Application MVP Mapping","anchorId":"application-mvp-mapping"}],"rationale":"Session/event/receipt primitives есть, но portable replay bundle format и tool отсутствуют.","priority":"P3"},{"id":60,"title":"Interop Test Suite","description":"подготовить набор обязательных тестов для grant verification, idempotency conflicts, revocation, receipts и denied actions.","category":"Conformance / tooling / adoption","side":"right","status":"missing","anchors":[{"heading":"Idempotency","anchorId":"idempotency"},{"heading":"Grant Verification","anchorId":"grant-verification"},{"heading":"Revocation Semantics","anchorId":"revocation-semantics"},{"heading":"Conformance","anchorId":"conformance"}],"rationale":"Нормативные области для тестов определены, но обязательных test cases и interop suite нет.","priority":"P2"}];
   const stage = root.querySelector("[data-review-stage]");
   const documentColumn = root.querySelector("[data-rfc-document]");
   const svg = root.querySelector("[data-review-threads]");
diff --git a/review/review-data.json b/review/review-data.json
index 458b13e..575a15d 100644
--- a/review/review-data.json
+++ b/review/review-data.json
@@ -280,24 +280,24 @@
       "side": "right",
       "anchors": [
         {
-          "heading": "Grant Object",
-          "anchorId": "grant-object"
+          "heading": "Grant Hash",
+          "anchorId": "grant-hash"
         },
         {
-          "heading": "Receipt Requirements",
-          "anchorId": "receipt-requirements"
+          "heading": "Canonical Object Hash Profile",
+          "anchorId": "canonical-object-hash-profile"
         },
         {
-          "heading": "App Receipt",
-          "anchorId": "app-receipt"
+          "heading": "Action Request",
+          "anchorId": "action-request"
         },
         {
-          "heading": "Receipt Forgery",
-          "anchorId": "receipt-forgery"
+          "heading": "Receipt Hash Chain",
+          "anchorId": "receipt-hash-chain"
         }
       ],
-      "status": "missing",
-      "rationale": "Receipts содержат grant_id, но canonical grant_hash и ссылка на точное содержимое grant отсутствуют.",
+      "status": "present",
+      "rationale": "RFC определяет canonical grant_hash над authoritative Grant Object, связывает его с action context и receipts и требует отклонять несовпадение с текущим grant state.",
       "priority": "P1"
     },
     {
@@ -400,24 +400,24 @@
       "side": "right",
       "anchors": [
         {
-          "heading": "Required Top-Level Fields",
-          "anchorId": "required-top-level-fields"
+          "heading": "Surface Hash",
+          "anchorId": "surface-hash"
         },
         {
-          "heading": "Grant Object",
-          "anchorId": "grant-object"
+          "heading": "Canonical Object Hash Profile",
+          "anchorId": "canonical-object-hash-profile"
         },
         {
-          "heading": "Receipt Requirements",
-          "anchorId": "receipt-requirements"
+          "heading": "Grant Object",
+          "anchorId": "grant-object"
         },
         {
           "heading": "Surface Downgrade",
           "anchorId": "surface-downgrade"
         }
       ],
-      "status": "missing",
-      "rationale": "Связь выполняется только через surface_version; canonical surface_hash в manifest, grant и receipts отсутствует.",
+      "status": "present",
+      "rationale": "RFC определяет canonical surface_hash над точным manifest object, связывает его с grant и receipts, требует отклонять подмену/downgrade и явно отделяет внешнее содержимое schema URLs.",
       "priority": "P1"
     },
     {
@@ -601,7 +601,7 @@
         }
       ],
       "status": "partial",
-      "rationale": "Требование normalization есть, но canonical algorithm/profile оставлен приложению или будущему draft.",
+      "rationale": "RFC задаёт canonical hash точного wire input для receipt binding, но semantic normalization, defaults, set ordering и schema equivalence для idempotency остаются action-specific.",
       "priority": "P1"
     },
     {
@@ -890,11 +890,11 @@
       "description": "добавить `parent_receipt_hash`, `trace_id`, `surface_hash`, `grant_hash`, `policy_decision_hash`.",
       "category": "Receipts / audit / provenance",
       "side": "right",
-      "status": "partial",
+      "status": "present",
       "anchors": [
         {
-          "heading": "Receipt Requirements",
-          "anchorId": "receipt-requirements"
+          "heading": "Receipt Hash Chain",
+          "anchorId": "receipt-hash-chain"
         },
         {
           "heading": "Runtime Receipt",
@@ -909,7 +909,7 @@
           "anchorId": "receipt-forgery"
         }
       ],
-      "rationale": "Есть связь app receipt с runtime receipt и hash входов/выходов, но нет общей цепочки и требуемых hash/trace полей.",
+      "rationale": "Runtime/App receipts образуют проверяемую цепочку через receipt_hash и parent_receipt_hash и несут surface_hash, grant_hash, policy_decision_hash и trace context.",
       "priority": "P1"
     },
     {
@@ -918,11 +918,15 @@
       "description": "оставить MVP unsigned, но заранее определить будущий профиль canonicalization + signatures.",
       "category": "Receipts / audit / provenance",
       "side": "left",
-      "status": "partial",
+      "status": "present",
       "anchors": [
         {
-          "heading": "Receipts",
-          "anchorId": "receipts"
+          "heading": "Receipt Signing Profile",
+          "anchorId": "receipt-signing-profile"
+        },
+        {
+          "heading": "Canonical Object Hash Profile",
+          "anchorId": "canonical-object-hash-profile"
         },
         {
           "heading": "App Receipt",
@@ -931,13 +935,9 @@
         {
           "heading": "Receipt Forgery",
           "anchorId": "receipt-forgery"
-        },
-        {
-          "heading": "Open Questions",
-          "anchorId": "open-questions"
         }
       ],
-      "rationale": "Подпись и canonicalization отложены на future draft; профиль и алгоритмы не определены.",
+      "rationale": "RFC задаёт concrete JCS canonicalization и detached JWS profile, signing input, algorithm/key verification и downgrade behavior; unsigned receipts остаются допустимы в MVP.",
       "priority": "P2"
     },
     {
@@ -974,11 +974,11 @@
       "description": "стандартизировать объяснимый объект `policy.decision` с reason code, matched rules и safe-to-show текстом.",
       "category": "Receipts / audit / provenance",
       "side": "left",
-      "status": "partial",
+      "status": "present",
       "anchors": [
         {
-          "heading": "Approval Semantics",
-          "anchorId": "approval-semantics"
+          "heading": "Policy Decision Object",
+          "anchorId": "policy-decision-object"
         },
         {
           "heading": "Runtime Receipt",
@@ -993,7 +993,7 @@
           "anchorId": "error-model"
         }
       ],
-      "rationale": "Policy decisions упомянуты, но нет типизированного policy.decision с codes, matched rules и safe text.",
+      "rationale": "RFC задаёт типизированный policy.decision с outcome, reason_code, matched_rules, safe-to-show explanation, policy version и проверяемым policy_decision_hash.",
       "priority": "P1"
     },
     {
@@ -1462,8 +1462,12 @@
       "description": "добавить trace/span/session ids, чтобы ASP действия связывались с app logs, runtime logs и receipts.",
       "category": "Economics / limits / operations",
       "side": "left",
-      "status": "partial",
+      "status": "present",
       "anchors": [
+        {
+          "heading": "Observability Context",
+          "anchorId": "observability-context"
+        },
         {
           "heading": "Sessions and Actions",
           "anchorId": "sessions-and-actions"
@@ -1475,13 +1479,9 @@
         {
           "heading": "Receipt Requirements",
           "anchorId": "receipt-requirements"
-        },
-        {
-          "heading": "Agent Adapter",
-          "anchorId": "agent-adapter"
         }
       ],
-      "rationale": "Session correlation присутствует, но trace_id, span_id и сквозная observability semantics отсутствуют.",
+      "rationale": "RFC задаёт W3C-compatible creation и propagation semantics для trace_id, span_id и session_id через sessions, actions, receipts и adapter/log context и отделяет correlation от authority.",
       "priority": "P2"
     },
     {