Scripts vs Services
HaltState supports both scheduled scripts and long-running services, but their retry and reporting patterns differ.
Scheduled scripts
A script should derive stable idempotency keys from the scheduled business unit, call the guard path, execute only when allowed, report success or error, and exit cleanly when approval is pending or denied. The next run can retry the same key and continue safely.
Long-running services
A service should keep the guard call near the tool boundary, use short timeouts, fail closed for high-risk actions, and keep local state transitions explicit. Services commonly need a post-action report path because execution can fail after a policy allow.
Worker-ledger pattern
The refund agent uses a server-side ledger because business actions need durable transitions. A row starts as NEW, moves through GUARDING, then becomes ALLOWED, APPROVAL_REQUIRED, DENIED, EXECUTED, or ERROR. That is safer than a browser-side simulation because the authority and execution record stay server-side.
Implementation notes
Keep the HaltState call as close as possible to the side effect. The agent may plan and draft freely, but the wrapper around the actual action should be the place where authority is checked. That wrapper should send only the context required for policy evaluation: safe identifiers, normalized amounts, action names, risk flags, schedule windows, and redaction status. Raw customer payloads and secrets should stay in the business system or protected operator tooling.
Operational evidence
For each action, preserve the decision, the worker outcome, the idempotency key, safe resource references, latency, proof status, and redaction status. This evidence supports incident response and control narratives because it shows what the system did at runtime rather than only describing what the policy document intended. HaltState supports alignment work; it is not a substitute for legal advice or a compliance certification.