Changed payload invalidates approval
Any material change to the payload, connector, amount, recipient, policy, cost or risk creates a new action version. Prior approval cannot authorize the changed action.
Governed execution · Architecture-defined
Approval is bound to the exact action.
Zurvina's architecture separates preparation from consequential execution. Identity, entitlement, evidence, policy, risk, human authorization, payload integrity, provider verification and audit remain explicit.
Architecture explanation only. This page does not imply that every target-state control is production-proven, and it cannot initiate, approve or execute an action.
Canonical action state machine
Exact states from draft to verified completion.
Approval is not a reusable blanket permission. Rejection, change request and expiry are explicit alternatives before locking, while failed execution can enter retry review or a governed rollback path where the provider action is actually reversible.
- Architecture-defined
DRAFT
Prepare the proposed action, accountable actor, supporting evidence, cost and exact intended payload.
- Architecture-defined
EVIDENCE_READY
Required evidence and provenance are attached before consequential work can advance.
- Architecture-defined
ENTITLEMENT_CHECKED
Validate tenant membership, plan entitlement, feature state, usage boundary and resource scope.
- Architecture-defined
POLICY_CHECKED
Evaluate identity, permission, policy, budget, duplication and risk controls for the exact action.
- Architecture-defined
AWAITING_APPROVAL
Route P2–P4 or otherwise configured consequential work to the designated human approver set.
- Architecture-defined
APPROVED
Record the authorized decision for this action version only; rejection, change request and expiry remain explicit alternate states.
- Architecture-defined
PAYLOAD_LOCKED
Bind the approval to the exact tenant, connector, recipient, amount or cost envelope, policy version, expiry and payload hash.
- Architecture-defined
EXECUTION_QUEUED
Queue only the approved version for the governed execution gateway with an idempotency key.
- Architecture-defined
EXECUTING
Invoke the registered tenant-bound connector through the governed execution path; agents do not bypass this boundary.
- Architecture-defined
PROVIDER_VERIFIED
Verify provider or system outcome, identifiers and response evidence rather than treating a request as proof of completion.
- Architecture-defined
COMPLETED
Record the verified result, usage and audit evidence after the external or system outcome is confirmed.
Failure path: FAILED → RETRY_REVIEW → ROLLBACK_REQUESTED → ROLLED_BACK.
P0–P4 risk model
Risk determines the required human control.
P0 is read/prepare work with no external effect. P1 is low-risk internal work. P2 external communication requires human approval. P3 high-impact work requires a named approver and separation of duties. P4 irreversible or regulated work uses the strongest approval controls, including dual approval where policy requires it.
| Tier | Class | Required control | Execution boundary |
|---|---|---|---|
| P0 | Research | May prepare research within authorized access; no external action is taken. | Policy-bounded preparation |
| P1 | Low-risk | Pre-approved preparation only, bounded by configured policy and permissions. | Policy-bounded preparation |
| P2 | External | Human approval is required before external communication or provider action. | Authorized human approval |
| P3 | High-impact | An explicitly authorized approver must review before any high-impact action. | Authorized human approval |
| P4 | Regulated / Irreversible | Strong or dual approval is required where policy applies; never automatic. | Strong or dual approval where policy applies |
Execution integrity
Approval, retry, verification and recovery are separate controls.
No self-approval
An agent cannot approve its own work, and a proposer cannot satisfy a dual-approval requirement. Approval authority stays separate from preparation.
Idempotency limits duplicate execution
A stable operation key and transactional lock are intended to keep retries from duplicating email, payment, records, publication or deployment. Ambiguous outcomes stop for verification.
Completion requires verification
AI assertions do not prove completion. Provider or system verification is required before the action may be recorded as completed.
Rollback follows provider reality
Reversible actions may enter a separately governed rollback path. Irreversible actions cannot be described as rolled back and require stronger prevention before execution.
Early access
Ready to build your AI workforce?
Explore an approval-governed operating model with the Zurvina team. Demo access remains controlled and no purchase occurs from this page.