Command Authorization & Tokens

Every command carries a scoped, short-lived, single-writer token; actuators reject anything unsigned or out of scope.

L4 · Orchestration — its place in the stack (left, click any layer) and its internal components (right). Telemetry rises; control descends.

No token, no actuation

Each command to the breeder or burner must carry a cryptographically-signed authorization token that names the actuator scope, the authority level it satisfies, and an expiry. Actuator-facing adapters on L1 reject any command whose token is missing, expired, out of scope, or replayed. Authorization is a hard gate in the pipeline, independent of the ML stack.

Scoping

json

{
  "token_id": "tok_44c1",
  "scope": ["breeder.coil.PF3.setpoint"],
  "authority": "L2",
  "issued_for": "shot_00421:step_field_ramp",
  "not_after": "2030-04-12T09:20:00Z",
  "single_writer": true
}

Single-writer per actuator

At any moment exactly one procedure holds the write token for a given actuator. This eliminates the class of bugs where two components command the same breeder coil or the same burner plug magnet concurrently. Token handoff between phases is an audited event; a preempted procedure surrenders its tokens as part of its safe stop (see scheduler).

Binding to checks

A token references the rules and envelope versions it was minted against; a command minted against a stale envelope is rejected.
Human approval (routing) is what elevates a token to a higher authority level.
Tokens are single-use per idempotency key, so a replayed command cannot re-actuate.

Emergency authority

Safety actions (P0: quench abort, disruption mitigation) use pre-authorized, always-valid emergency tokens so a protective action is never blocked waiting for authorization. These tokens are scoped strictly to abort and safe-state actions, never to energizing actions, and their every use is loudly audited.