Authority and safety
The validation gate every action passes through, what a rejection carries, and how the runtime behaves when something fails.
The gate
Every proposed action passes through the same validation step. It is not middleware that can be removed, reordered or bypassed by configuration — the execution path has one shape, and validation sits between planning and any effect on the world.
Creator model or controller
Any Instance you already own — a character rig, a vehicle chassis, a boat hull, a conveyor line, a flock controller.
Actor adapter
Binds that model’s parts, attributes, seats and motors to a normalised observation and actuation surface. Embodiment lives here, not in the kernel.
Role and capability manifest
Declares what this actor may perceive, may attempt, and may spend. Anything absent from the manifest is not reachable at runtime.
Goal and planner
A normalised goal resolves into an ordered plan built only from declared actions, against the actor’s current observation.
Authority and safety validation
Every proposed action is checked against capability, constraint, ownership and world preconditions. Rejection is a normal outcome, not an error path.
Resource transaction
Currency, stock, fuel, cargo and charges move atomically. A partially applied plan is never observable.
Action execution
The approved action runs through the adapter’s actuation surface — the same interface for a humanoid step, a throttle input and a crane slew.
Server-authoritative commit
World state is written on the server. Clients receive the result. No client message can substitute for this step.
What is checked
- Capability — does the role grant this action at all?
- Constraint — do the role’s declared limits permit these parameters?
- Ownership — does this actor hold the resources and assignments the action assumes?
- Precondition — do the action’s declared world conditions hold in the frozen observation frame?
Rejections
Rejection is an ordinary outcome, not an error path. A verdict carries whether the action was allowed, a typed reason when it was not, and the observation fields the decision was made from.
-- Every proposed action passes the same gate before anything moves.
local verdict = Runtime.validate(actor, {
action = "hoist",
params = { height = 26 },
})
-- verdict.allowed -> boolean
-- verdict.reason -> "constraint.max_payload_tonnes" | "capability.missing" | ...
-- verdict.evidence -> the observation fields the decision was made from
if not verdict.allowed then
-- Rejection is an ordinary outcome. The actor re-plans; it does not retry blindly.
Runtime.replan(actor, { excluding = verdict.reason })
endThe evidence matters more than it first appears. Without it, debugging agent behaviour becomes archaeology; with it, a rejection tells you exactly which declared limit stopped which action and what the world looked like at the time.
The trust model
| Capability | Client | Server runtime | External model |
|---|---|---|---|
| Read world state | Replicated view only | Full authoritative state | Redacted observation, if enabled |
| Submit a goal | As a request, subject to validation | Directly | As a proposal |
| Select the next action | Never | Planner output | May rank or suggest |
| Skip authority validation | Never | Validation is not optional | Never |
| Move resources | Never | Atomic transaction | Never |
| Commit world state | Never | Sole writer | Never |
Note the row that has no exceptions: nothing except the server runtime can commit world state. Not a client, not an external model, and not an adapter acting on its own initiative.
Failure behaviour
Degradation stops the actor rather than loosening the rules. A manifest that fails to load refuses attachment instead of falling back to a permissive default. A planner that cannot produce a valid plan holds the last safe state and stops issuing actions. A provider timeout falls back to the deterministic local planner.