Action Gateway
Gateway boundary for verified action execution.
Action Gateway
The Action Gateway is Splendor's side-effect boundary. It accepts action requests, checks identity and verifier evidence, executes adapters only when allowed, and records traceable outcomes.
Action request
An action request includes:
action_idtenant_idagent_idrun_id- requested action name and parameters
- adapter identifier, if applicable
- required permissions
- quota usage estimate
- preconditions and postconditions
- optional approval or safety evidence
- timestamp and trace linkage
Approval evidence, work-order fields, or SDK metadata never bypass the gateway. They are inputs to verifier decisions.
Outcome statuses
| Status | Meaning |
|---|---|
Executed | Verification passed and the adapter completed. |
Denied | Verification denied the action; adapter did not execute. |
NeedsApproval | A scoped approval is required; adapter did not execute. |
NeedsIntervention | Runtime or verifier uncertainty failed closed; adapter did not execute before intervention. |
Failed | Adapter execution was attempted after verification but failed. |
Required verifier categories
- tenant and agent scope;
- allowed action and adapter;
- required permissions;
- quotas and budget;
- preconditions and postconditions;
- data, filesystem, and network scope where applicable;
- approval and governance state where applicable;
- safety evidence for high-level physical actions;
- policy TTL or revocation where applicable.
If a required verifier cannot safely decide, the gateway fails closed.
Adapter boundary
Adapters are the only boundary that executes verified side effects. Examples include filesystem, HTTP, artifact, governance, and simulated physical adapters. Official SDK and client examples must not call adapters directly for privileged operations.
Physical action boundary
High-level physical actions can be modeled and verified. Low-level actuator, firmware bypass, raw motor, emergency-stop bypass, or hard real-time control actions are not valid direct Splendor actions.
Trace behavior
The gateway records verification start, verification completion, action outcome, post-verification where applicable, and outcome recording. Denials and failures must be inspectable in replay.
Replay does not call the gateway or adapters again; it explains recorded gateway decisions from trace and state evidence.