Authorization and outcome are separate authorities.

RuleOak's architecture connects them without pretending they are the same thing.

Agent / workflow / MCP client
          ↓
 action adapter + normalization
          ↓
Authority Envelope → Policy → Approval/Revocation
          ↓
   one-use ExecutionLease
          ↓
 cooperating executor / MCP route
          ↓
       EffectReceipt
          ↓
 observation / Effect Profile
          ↓
      retry disposition
          ↓
 Flight Recorder / evidence

Action normalization

Transport/framework-specific calls are converted into a stable operation/resource identity. Authorization should bind to that identity, not an opaque prompt or display label.

Authority and policy

Authority Envelopes, delegation, policy, approval and revocation answer whether the exact normalized action may execute. Approval does not create unlimited reusable authority.

One-use execution

An ExecutionLease is short-lived and one-use. A cooperating executor consumes it before causing the guarded side effect, reducing replay and stale-authority mistakes.

Effect evidence

An EffectReceipt records what RuleOak observed. A reviewed Effect Profile defines how the real external postcondition can be checked. Without trusted semantics, the outcome remains unresolved.

Reliability surfaces

Inspector discovers capabilities; Capability Watch records normalized drift; CrashLab exercises failure/retry/staleness scenarios. None of those surfaces grants runtime authority merely by discovering metadata.

Integration boundary

The strongest deployment is one where the application/transport cannot accidentally retain an unguarded path for the same consequential action. RuleOak cannot govern side channels that bypass it.