01
Action request
Name the request, actor, agent, provider, exact action, target, parameters, authority context, policy version, and intended result.
ARBITER Gate · Developer Surface
Build controlled actions—not blanket agent access.
ARBITER Gate v1 places a recognizable authority contract between AI intent and meaningful action. Providers, models, and adapters may change; the exact-action, policy, approval-evidence, scoped-authority, execution, receipt, and revocation boundary remains inspectable.
ARBITER-GATE/V1
One control loop across tools and providers.
The versioned contract adds exact action-digest binding, current-state revalidation, and Outcome Receipt v1 around the request, deterministic policy, approval evidence, scoped grant, constrained action, expiry, revocation, and replay lifecycle. Production SDK/package distribution remains a separately governed release decision.
02
Action digest
Normalize the executable binding so a materially different request cannot inherit an earlier approval or grant.
03
Policy decision
Evaluate deterministic rules and current risk/integrity state into allow, deny, hold, or require-approval.
04
Human checkpoint
When policy requires it, bind the named approver to the exact action digest, policy version, and expiry. Approval is evidence; it does not create standing authority.
05
Scoped authority
Issue narrow, short-lived, revocable authority only after required approval and current state match instead of standing credentials or blanket tool access.
06
Execution revalidation
Immediately before side effects, recheck the exact action binding, current policy and authority state, scope, expiry, revocation, replay state, and receipt path.
07
Constrained execution + receipt
Execute only through the admitted adapter, then record provider, agent, executor, policy trace, approval evidence, authority lifecycle, and observed outcome.
Decision contract
Authorization is four-state—not a model confidence score.
GATE DECISION
ALLOW
Current policy and valid authority permit the exact action.
GATE DECISION
DENY
The action is forbidden.
GATE DECISION
HOLD
Required truth is stale, missing, contradictory, or not authoritative enough.
GATE DECISION
REQUIRE APPROVAL
Policy requires an authorized human decision. A matching approval is necessary evidence, not standing execution authority.
Inspect the behavior before integrating it.
Use the email, shell, file, remote-support, and network-change gates to inspect allow, deny, hold, approval evidence, one-use authority, constrained execution, receipts, and expiry. Public examples remain synthetic and do not contact production providers or customer systems.
Admit one action path at a time.
A production integration starts with one exact action, one target, explicit identities, deterministic policy, a human checkpoint where required, a scoped grant, one constrained executor/adapter, rollback, and evidence that failure modes close safely. Context, model capability, authentication, or approval alone never silently widens execution authority.