[CT-801] Specify bounded action authorization receipts

[flyingrobots]

ADR-THINK-001 · Delivery plan · Complete issue catalog

Milestone: ADR-THINK-001 P8 — Action bridge and production cutover

Feature: F8.1 — Bounded action authorization

Outcome

No ClaimOccurrence, answer, recommendation, or model output can directly authorize an external effect; a separate receipt grants one bounded operation at one evidence frontier.

User stories

• As a Think user, I want an inspectable boundary between interpreting my words and acting on them, so that a plausible reading cannot silently become an external command.
• As a action executor, I want a closed authorization contract with exact operation and parameters, so that I can reject any request that exceeds the granted effect.

Deliverables

• ActionAuthorizationReceipt schema, canonical encoding, identity, expiry, and validation law.
• Operation, bounded parameter, claim/relation evidence, authority resolution, policy, frontier, and revocation-condition fields.
• Use and risk policies requiring independent Edict or Boundary authorization.
• Conformance fixtures separating evidence, reading, answer, recommendation, authorization, and execution.

Acceptance criteria

• A ClaimOccurrence or AnswerWitness alone never satisfies the action boundary.
• Every receipt binds exactly one operation type, bounded parameters, authority resolution, policy digest, evidence frontier, expiry, and revocation conditions.
• The authorizer cannot mint a receipt for evidence or authority unavailable at its frontier.
• Receipt validation is deterministic and independent of natural-language reinterpretation at execution time.

Test plan

Contract and unit

• Receipt tests cover identity, operation variants, parameter bounds, evidence, authority, frontier, expiry, revocation, and signatures.

Integration and acceptance

• A witnessed Think answer requests and receives a bounded authorization without directly executing the operation.

Failure and recovery

• Naked claim, naked answer, missing policy, wrong frontier, expired receipt, unbounded parameter, and unauthorized authorizer fail.

Resource and performance

• Authorization evidence lookup and validation remain bounded by receipt references rather than Mind history.

Security, privacy, and erasure

• Forged, replayed, cross-principal, cross-view, and erased-evidence authorization attempts fail closed.

Build-time resources

Resource	Exclusivity mode	Scope
action-authorization-schema	exclusive	Receipt contract and validation law.
action-risk-policy	exclusive	Operation/use/risk authorization requirements.
authorization-signing-keyring	exclusive	Authorized receipt issuers and scopes.
action-operation-fixtures	partitioned	Disjoint operation and parameter families.
answer-and-authority-history	shared	Read-only evidence at the requested frontier.

• exclusive: Only one active slice may mutate or lease the named resource.
• partitioned: Concurrent writes are lawful only in disjoint partitions named by each slice.
• shared: Concurrent read-only use is lawful; this slice does not mutate the resource.

Dependencies

• Blocked by #94 — CT-706

ADR traceability

• Implementation gates: None directly
• Constitutional invariants: I3, I9, I10
• ADR acceptance criteria: AC33, AC34

Non-goals

• Do not let natural-language captures authorize effects directly.
• Do not define every future Edict operation in this issue.