Production readiness checklist

Use this checklist before switching a production agent from observation to enforcement. The objective is not merely “the SDK is installed”; it is that every consequential path has an intentional decision and a tested failure mode.

1. Inventory the action surface

• Static discovery reports every tool exposed by the production graph.
• Tool names and argument schemas match the deployed agent version.
• Every tool capable of an external effect is classified as consequential.
• Direct application calls cannot bypass the wrapped tool entry point.
• Uncovered consequential tools are either configured or explicitly removed from the agent.
• Memory and read-only retrieval tools are not mistaken for protected write paths.

Run instrument() first if the deployed surface is not yet visible. Confirm with real representative invocations, because dynamic observation can reveal tools absent from a narrow test prompt set.

2. Review every rule

• Policy expressions use the supported numeric grammar and reference real arguments.
• Critical identifiers are grounded against an authoritative live Source.
• Ownership comparisons use trusted context, not a model-supplied customer or workspace argument.
• State and freshness conditions reflect current business invariants.
• Multiple checks are intentionally an AND.
• Field matching does not depend on an ambiguous first result.
• on_fail: hold has a legitimate human exception process.
• Every on_error: allow has explicit risk approval and a compensating control.
• Proposed-effect previews remain useful when values are redacted.

Treat a rule review as authorization/security review, not UI configuration cleanup.

3. Harden Sources

• Source names identify system and environment unambiguously.
• Credentials are environment references, never literal secrets in Console configuration.
• Each Source uses a dedicated least-privilege read identity.
• Postgres uses a restricted role, read-only transactions, bounded statement timeouts, and verified TLS where available.
• MySQL uses a restricted user, read-only transactions, bounded query I/O, and verified TLS where available.
• HTTP verification endpoints are genuinely side-effect free and use restricted tokens.
• MCP credentials can invoke only audited read tools; readOnlyHint is not the sole control.
• SQLite files and all Source endpoints are reachable from every agent replica.
• Queries and lookups are indexed and meet the tool-call latency budget.
• Source outage behavior has been tested, not only configured.

4. Establish trusted context

• Context originates after host authentication.
• Request-specific identity uses trusted_context() around each invocation.
• Shared compiled agents have concurrency-isolation tests.
• Context names match rule ctx targets exactly.
• No model output or unchecked user field is promoted into trusted context.
• Tenant/workspace identity is enforced again by the Source or its credential where possible.

5. Review privacy and credentials

• Agent keys are stored in the workload secret manager.
• Plaintext agent keys do not appear in logs, images, notebooks, rules, or frontend code.
• write.report_args is empty unless each exported value has data-owner approval.
• Application logging does not forward raw on_decision arguments or local reasons unintentionally.
• SDK state and Console data use appropriate filesystem, volume, backup, and encryption controls.
• Non-loopback control-plane and Source traffic uses TLS.
• Hosted scope resolution and agent-key authorization have separate tests.

6. Exercise the decision matrix

Test the original side effect, not just the returned string.

Scenario	Expected decision	Original tool called?
Valid value, policy, ownership, and state	Allow	Yes, once.
Wrong owner	Block	No.
Missing required record	Block	No.
Policy over limit	Hold	Only after valid approval.
Human rejection	Rejected	No.
Review timeout or expiry	Held	No.
Review service unavailable	Review unavailable	No.
Source exception with default configuration	Block	No.
Source exception with approved fail-open rule	Allow	Yes; alert emitted.
Console outage within staleness window	Last-known-good decision	According to active rules.
Console outage beyond staleness window	Configuration stale	No.
Invalid candidate configuration	Last-known-good remains active	According to previous rules.
Monitor-mode block	Observed block	Yes.

7. Prepare runtime operations

• get_runtime_health() is exported to diagnostics or monitoring.
• Alerts cover configuration reachability, expiry, Source failure, pending audit growth, and delivery errors.
• ACTIONRAIL_SDK_STATE_DIR points to writable persistent storage.
• Outbox capacity and disk are sized for the expected event rate and outage window.
• Graceful shutdown calls close_reporting() and checks its result.
• Workload termination grace exceeds the ActionRail shutdown deadline.
• Review timeouts fit request/thread capacity and operator response targets.
• The chosen max_config_staleness reflects the organization’s revocation and outage policy.
• Console backups and recovery have been tested when audit/configuration continuity is required.

8. Roll out deliberately

1. Run instrument() to verify discovery.
2. Enable rules in monitor mode.
3. Compare observed decisions with expected business outcomes.
4. Fix coverage, false blocks, ambiguous checks, and Source latency.
5. Exercise the failure matrix in a staging environment.
6. Switch a small production cohort to enforcement.
7. Monitor blocks, holds, Source health, pending reports, and operator load.
8. Expand only after the cohort is stable.

Monitor is not a safety boundary

Do not call a rollout “protected” while monitor mode is enabled. Monitor evaluates and reports but always permits the original tool to run.