Every restart of the settlement box has a risk level, a cooldown, and a row

The auditor's question is always the same shape: who touched the settlement server on Sunday at 02:14, was it approved, and what did it do.

Host-level operations don't go through a root shell. They go through a catalog: GET /api/v1/servers/{id}/available-commands lists predefined commands, each with a risk_level, a cooldown_seconds, an hourly and a daily cap, and whether it requires_confirmation. High-risk ones need a confirmation_token in the execute-command call. Underneath, the container keeps its own timeline: GET /api/v1/containers/{id}/status-logs records every transition: stopped to running, the second it happened, whether user or system triggered it, and how long the previous state lasted.

Change control usually means a ticketing tool and a promise that people used it. Here the gate is in the API and the timeline is in the container.

The change ticket is a command slug with a cooldown.