The short answer
An AI approval gate should bind a named reviewer’s decision to one proposal version, supporting evidence, policy context, scope, and expiry. Any material change invalidates the approval. Execution receives a separate identity and produces a provider or system receipt; closure reconciles the approved proposal with what actually happened. “Approved” is a transition, not a permanent attribute.
Key takeaways
Model approval as a state machine
Useful states include drafted, evidence incomplete, ready for review, approved, rejected, changes requested, expired, execution queued, executed with receipt, outcome unknown, reconciled, and canceled. Define which roles can cause each transition.
NIST’s voluntary AI RMF highlights differentiated human-AI roles, accountability, documentation, monitoring, and “go/no-go” decisions. It does not dictate this state model; the lifecycle is Aptoria’s operational analysis.
Bind the decision to the work reviewed
The reviewer should see source identity, model output, material assumptions, uncertainty or missing evidence, requested external effect, and policy rule. Avoid approval interfaces that show only a fluent summary.
| Lifecycle part | Record | Invalidation or failure |
|---|---|---|
| Proposal | Stable ID, version, source snapshot, requested effect | Any material content or destination change |
| Evidence | References, limitations, model/tool version where relevant | Source changes or required evidence disappears |
| Decision | Reviewer, scope, reason, time, expiry | Expired authority or unapproved scope |
| Execution | Action ID, exact approved version, tool/provider | Different payload or duplicate attempt |
| Receipt | External or governed-system outcome and timestamp | Timeout or conflicting status |
| Closeout | Approved-versus-actual comparison and downstream result | Unresolved difference stays open |
Make review possible, not ceremonial
Show the evidence needed to disagree. Route only decisions that fit the reviewer’s role and give them a reject or request-changes path. Track overrides, repeated missing evidence, and time in queue as workflow signals.
Do not infer that human review makes a workflow safe. Review quality depends on authority, information, time, competence, and whether the system honors the decision.
Operational checklist
Mark your progress, then save a working copy. Selections reset when you leave this page. A checked box is not an approval or evidence of completion.
0 of 7 marked
Edge cases
Sources and references
Follow each source to check the underlying claim. Access checks and professional review are different steps.