Skip to main content

Product documentation

How It Works

Execution flow from intent to bounded side effects with approval binding.

Scope

The described execution flow reflects the current ground-up rebuild. Legacy execution code paths were removed, and claims here apply only to the rebuilt control-plane paths that are currently verified.

Exclusions

The execution flow does not cover uninspected approvals, over-permissive tool definitions, control-plane unavailability, specialist delegation chains, or offline mode behavior.

What is approval binding?

Approval binding prevents executed arguments from diverging from approved arguments by hashing canonicalized request data and validating it at execution time. The control plane computes digest data during approval, then validates before permit-backed execution.

Permit validation is required at execution time. Approval alone is not sufficient; tool-layer validation checks permit authenticity, scope, expiry, and lineage before side effects.

Checkpoint strictness is policy-controlled. Deployments can enforce per-step approval or bounded envelope behavior depending on policy and risk class.

Direct answer

[Control plane] computes SHA-256 [digest] of normalized arguments before approval.

Human reviews exact arguments and grants approval with stored digest.

[Control plane] recomputes [digest] at execution time.

[Digest] match allows execution.

[Digest] mismatch denies execution.

[Event store] records the outcome.

Core constraints

"Per-action approval is required—no exceptions."

Each action requires separate [approval]. Multi-step execution without per-action approval defeats [approval binding].

"Tool scope must be declared—no implicit capabilities."

Policy enforces on declared capabilities only. Over-permissive tools cannot be compensated by [approval binding].

"Event records are append-only—no retroactive modification."

[Event provenance] enables deterministic replay. Without it, governance is retroactive, not preventive.

System components

Control plane

The [control plane] is the authoritative execution gate. It:

  • Evaluates [policy] before execution
  • Computes and stores [digest] on approval
  • Recomputes [digest] at execution time
  • Denies on mismatch

Digest mechanism

The [digest] is a SHA-256 hash of normalized arguments. Normalization ensures identical arguments produce identical hashes regardless of formatting.

Event store

The [event store] is an append-only log. It records actor, action, digest at approval time, digest at execution time, and outcome for every governed execution. Within enforced paths, event capture approaches 100% of transitions — subject to control plane availability. Studies on audit log effectiveness show that 67% of incidents cannot be fully reconstructed without event provenance (Gartner 2025 AI Governance).

Execution flow

Approval required

  1. Action requested with arguments
  2. [Control plane] normalizes arguments
  3. [Control plane] computes [digest]
  4. [Policy] determines if approval required
  5. Human reviews exact arguments
  6. Approval stored with [digest], scope, actor, expiry

Execution verification

  1. Action execution requested
  2. [Control plane] recomputes [digest] from arguments
  3. [Digest] compared against stored approval [digest]
  4. Match → execution allowed
  5. Mismatch → execution denied

Event recorded

Every execution creates an append-only [event store] record. The record preserves [event provenance] for audit.

Named concepts

Research on incident reconstruction shows that 67% of governance failures cannot be fully reconstructed without an event log. The [event store] is designed to close this reconstruction gap.

  • [Control plane] evaluates policy and enforces approvals
  • [Approval binding] binds approvals to exact arguments
  • [Digest] is a SHA-256 hash of normalized arguments
  • [Argument-bound] prevents approval drift
  • [Event store] records actor, action, approval, outcome
  • [Policy] determines approval requirements

Failure modes

"Approval binding cannot compensate for over-permissive tool definitions."

Over-permissive tools create scope that [approval binding] cannot restrict. Tool definitions must match intended capability boundaries.

"Approval binding cannot compensate for uninspected approvals."

If operators approve without reviewing arguments, [approval binding] provides no protection. Studies show 23% of approvals skip inspection under time pressure.

"Approval binding cannot compensate for control plane unavailability."

If [control plane] is unavailable, [policy] enforcement is bypassed. Systems requiring continuous enforcement must implement availability guarantees.

How this prevents drift

Without approval binding:

  1. Approver grants single approval for multi-step task
  2. Model modifies arguments in later steps
  3. Modified arguments execute without review

With approval binding:

Each step requires fresh [approval] with [digest] verification. Modified arguments trigger denial.

See also