R3: per-call escalation context — content-addressed proposal (params + recommended display sections), with hash-bound large payloads

[dickhardt]

Summary

R3 r3_conditional already says the resource challenges a per-call operation "including the specific parameters from the agent's API request in the resource token," and the AS "evaluates those concrete parameters." But it doesn't define how to carry the parameters, how the user sees the specific call (the R3 display is per-document / per-class, not per-call), or what to do with large payloads. This proposes a concrete shape, reusing R3's content-addressing.

Proposal: a per-call, content-addressed proposal document

For an escalate / r3_conditional operation, the resource builds a per-call proposal document — a per-instance R3 document with a fresh r3_uri / r3_s256 (same content-addressing as the class doc; see #31 for the hashing fix) — holding:

• display — per-call Markdown for the PS to render to the user, with recommended sections (convention, not MUSTs, mirroring the justification "TODO: define recommended sections"): ## Action, ## To / ## Recipient, ## Details, ## Content (excerpt), ## Irreversible.
• the specific parameters — machine-readable, for the resource to bind and the AS to (optionally) evaluate. For large or sensitive payloads, store a hash + short excerpt instead of the bytes.

Flow

1. Agent proposes the op (with parameters) at the authorization endpoint.
2. Resource stores the proposal and mints a resource_token referencing it (r3_uri / r3_s256). The token stays small — just the reference.
3. PS fetches the proposal (AS/PS-signature-gated), renders display, user approves → auth_token echoes r3_uri / r3_s256.
4. Agent retries the actual call → resource recovers the proposal from its own store and enforces that the agent's actual parameters match what was approved (and verifies hash(payload) for any re-presented large payload). "Approved: email mom" cannot become "email the CEO."

Why this shape

• Tokens stay small — parameters are content-addressed, not inlined.
• Large payloads never traverse the PS — only a hash + excerpt do; the bytes go straight to the upstream at call time. Also a privacy lever (choose what the PS sees).
• Binds approval to the exact proposed call — the resource enforces an exact match.

Open question

Whether the AS/PS should machine-evaluate the parameters (e.g., auto-deny payment > $X) or treat the proposal as display-for-human-consent only (v1). The parameters are present in the proposal either way, so machine policy can be added later without a format change.