ARBITER DECISION
ALLOW
Current policy and valid authority permit the exact action.
ARBITER Gate Standard v1
Every consequential AI action needs an authority boundary.
An AI Action Gate is the checkpoint between AI intent and a real side effect. ARBITER Gate is INTIGNAI's provider-neutral implementation: exact action binding, deterministic policy, approval when required, narrow authority, execution-time revalidation, constrained execution, replay protection, and an Outcome Receipt.
The doctrine
Context is not permission.
Recommendation is not approval. Approval is evidence, not standing authority. Execution is permitted only when the exact action binding, current policy state, and scoped grant all match. Consequential execution produces an Outcome Receipt.
The category
AI Action Gate → ARBITER Gate.
Models and providers can change without becoming the source of business authority. The Gate remains the independent control boundary immediately before meaningful execution.
Four states
A model confidence score is not an authorization decision.
ARBITER DECISION
DENY
The action is forbidden under the evaluated state.
ARBITER DECISION
HOLD
Required truth is missing, stale, contradictory, or not trustworthy enough to authorize execution.
ARBITER DECISION
REQUIRE APPROVAL
Policy requires an authorized human decision. Matching approval is necessary evidence, but it does not create standing execution authority.
Conformance boundary
What an action Gate must enforce.
- → identify request, actor, agent, provider, action, target, parameters, authority context, and policy version
- → normalize the immutable execution binding into the exact action digest
- → evaluate deterministic policy and current risk/integrity state at the execution boundary
- → when required, bind human approval to the exact action digest, policy version, and expiry
- → issue only narrow, expiring, revocable authority after required approval and current state match
- → revalidate action, policy, scope, expiry, revocation, and replay state immediately before side effects
- → execute only through a constrained adapter and produce reviewable evidence of the decision and observed outcome
Exact action binding
Change the action; invalidate the approval.
ARBITER Gate v1 binds request ID, actor, agent, provider, action, target, parameters, authority context, and policy version into the action digest. A materially different binding gets a different digest and cannot inherit the old approval. Approval evidence and the scoped grant remain separate authority-lifecycle records.
Outcome Receipt v1
Proof should describe what happened—not what the model hoped happened.
A receipt separates provider identity, agent identity, executor identity, policy and risk state, approval evidence, authority lifecycle, and observed execution result. It is evidence, not a chain-of-thought transcript.
- → who requested the action
- → what exact action digest was evaluated
- → which policy, risk state, and rules applied
- → whether human approval was required and matched
- → which scoped grant was issued, consumed, expired, revoked, or rejected
- → which executor performed or blocked the side effect
- → what outcome was actually observed
Provider-neutral by design
Hosted models, local models, deterministic software, MCP clients, human-assisted agents, and future embodied systems can all sit above the same authority contract. Capability never silently becomes permission.
Open developer surfaceReference proof before production claims
The hosted examples are synthetic reference gates. Production identity, durable grants, atomic one-use consumption, credential custody, monitoring, rollback, receipt durability, and incident response are separately qualified during implementation.
See controlled actions