Documentation home

Approval Lifecycle

Approval flows route medium-risk actions to human authority while preserving deterministic worker behavior.

States

StateMeaningExecution rule
pendingAwaiting operator review.Do not execute.
approvedHuman authority granted execution.Execute once on approved retry.
rejectedHuman authority refused execution.Never execute.
expiredReview window closed.Do not execute; create a fresh action only if business policy allows.

Operator data boundary

Public pages and live feeds should not expose raw approval IDs, operator names, internal tenant IDs, or policy IDs. They can show that approval was required and later approved or denied, but sensitive operational identifiers belong in protected operator tooling.

Flow

client.guard()
  -> policy engine evaluates rules
      -> ALLOW: execute block
      -> DENY: raise ActionDenied
      -> APPROVAL_REQUIRED: raise ApprovalPending
          -> human reviews
              -> approved: same key executes on retry
              -> rejected: same key raises ActionDenied
              -> expired: same key raises ActionExpired

Notification channel

Approval requests can notify designated reviewers through protected operator channels. Public surfaces should only show that approval was required or resolved; raw approval IDs, reviewer identities, tenant IDs, and internal notes stay in protected tooling.

Implementation notes

Keep the HaltState call as close as possible to the side effect. The agent may plan and draft freely, but the wrapper around the actual action should be the place where authority is checked. That wrapper should send only the context required for policy evaluation: safe identifiers, normalized amounts, action names, risk flags, schedule windows, and redaction status. Raw customer payloads and secrets should stay in the business system or protected operator tooling.

Operational evidence

For each action, preserve the decision, the worker outcome, the idempotency key, safe resource references, latency, proof status, and redaction status. This evidence supports incident response and control narratives because it shows what the system did at runtime rather than only describing what the policy document intended. HaltState supports alignment work; it is not a substitute for legal advice or a compliance certification.