[EPIC] Action escrow — proof-gated autonomous side effects #337

New issue

Open

opened 2026-09-08 02:03:34 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-08 02:03:34 +00:00

Owner

Parent architecture: #624
Builds on: #150 typed capabilities/ExecutionPlan, #625 transactional commitment, #626 effect journal, #628 user policy.

Goal

Introduce a first-class state between do it now and remind me later: stage an authorized action until its proof conditions become true.

Example:

Merge this PR when CI is green, review is approved,
it is still based on current master, and no critical security issue appeared.

The action is durable and inspectable but cannot execute until Zara proves the declared predicate set under current evidence.

Escrow contract

Research a typed principal-scoped ActionEscrow including:

intended capability/action and typed arguments;
source transaction/policy;
immutable authorization scope plus any required reauthorization policy;
closed proof-condition expression referencing reviewed facts/providers;
evidence freshness requirements;
deadline/expiry;
cancellation/revocation;
idempotency key;
target device/provider constraints;
state: staged / blocked / ready / executing / verified / failed / cancelled / expired.

Proof semantics

Conditions must be evaluated from typed trusted evidence such as CI status, review state, provider observations, time, device presence or explicit user confirmation. Free-form model assertions never satisfy a proof condition by themselves.

Re-evaluate relevant conditions immediately before execution to avoid stale time-of-check/time-of-use decisions.

Autonomy boundary

Escrow may preserve an existing authorization decision only according to explicit policy. A staged action cannot survive capability revocation, principal deletion, provider identity change or policy changes that invalidate its authority.

Execution

Ready actions execute through normal RuntimeHost/capability contracts and produce ordinary causal-effect records under #626. Provider acknowledgement is not automatically verified success.

UX

Support what are you waiting on?, why hasn't this run?, cancel that, change the condition, run it now where authorization allows, and clear notification when proof becomes true or execution fails.

Tests

Cover condition transitions, stale evidence, revoked permission, changed PR/resource identity, duplicate watcher events, restart persistence, timeout, concurrent state changes, two principals, device disconnect, execution failure and exactly-once/idempotency behavior.

Acceptance

A user can stage a consequential action with machine-checkable conditions and Zara executes it only when fresh typed evidence proves every required condition and authority is still valid.

Parent architecture: #624 Builds on: #150 typed capabilities/ExecutionPlan, #625 transactional commitment, #626 effect journal, #628 user policy. ## Goal Introduce a first-class state between `do it now` and `remind me later`: **stage an authorized action until its proof conditions become true**. Example: ```text Merge this PR when CI is green, review is approved, it is still based on current master, and no critical security issue appeared. ``` The action is durable and inspectable but cannot execute until Zara proves the declared predicate set under current evidence. ## Escrow contract Research a typed principal-scoped `ActionEscrow` including: - intended capability/action and typed arguments; - source transaction/policy; - immutable authorization scope plus any required reauthorization policy; - closed proof-condition expression referencing reviewed facts/providers; - evidence freshness requirements; - deadline/expiry; - cancellation/revocation; - idempotency key; - target device/provider constraints; - state: staged / blocked / ready / executing / verified / failed / cancelled / expired. ## Proof semantics Conditions must be evaluated from typed trusted evidence such as CI status, review state, provider observations, time, device presence or explicit user confirmation. Free-form model assertions never satisfy a proof condition by themselves. Re-evaluate relevant conditions immediately before execution to avoid stale time-of-check/time-of-use decisions. ## Autonomy boundary Escrow may preserve an existing authorization decision only according to explicit policy. A staged action cannot survive capability revocation, principal deletion, provider identity change or policy changes that invalidate its authority. ## Execution Ready actions execute through normal `RuntimeHost`/capability contracts and produce ordinary causal-effect records under #626. Provider acknowledgement is not automatically verified success. ## UX Support `what are you waiting on?`, `why hasn't this run?`, `cancel that`, `change the condition`, `run it now` where authorization allows, and clear notification when proof becomes true or execution fails. ## Tests Cover condition transitions, stale evidence, revoked permission, changed PR/resource identity, duplicate watcher events, restart persistence, timeout, concurrent state changes, two principals, device disconnect, execution failure and exactly-once/idempotency behavior. ## Acceptance A user can stage a consequential action with machine-checkable conditions and Zara executes it only when fresh typed evidence proves every required condition and authority is still valid.