Tool-result codes
When enforcement does not call the original tool, ActionRail returns a redacted tool-result message containing a bracketed code.
| Code | Trigger | Retry guidance |
|---|---|---|
ACTIONRAIL_BLOCKED | Final decision is block. | Do not retry the same call unchanged. Correct the proposal or underlying trusted fact. |
ACTIONRAIL_HELD | A hold remains unresolved, times out, expires, or has no remote review queue. | Do not retry unchanged. Follow the application’s review/exception flow. |
ACTIONRAIL_REJECTED | A human rejected the held action. | Do not retry unchanged. |
ACTIONRAIL_REVIEW_UNAVAILABLE | Review could not open or remained unreachable at deadline. | Retry only after review service recovery and after re-evaluating the action. |
ACTIONRAIL_CONFIG_STALE | Remote enforcement authority exceeded its staleness limit. | Retry only after control-plane configuration validation recovers. |
Example:
⛔ [ACTIONRAIL_BLOCKED] ActionRail blocked this tool call before execution.
Verification failed for argument 'order_id'. Do not retry the same call unchanged.
The human-readable text can evolve. Application logic should detect the stable code token rather than parse the full sentence.
No allow code
An allowed action returns the original tool’s result. ActionRail does not replace a successful result with ACTIONRAIL_ALLOWED.
Use the local decision callback or Activity when the application needs an explicit audit/metric for allows.
Monitor mode
Monitor mode may report a hypothetical block or hold, but it still executes the original tool and returns that tool’s result. Model-facing failure codes therefore represent enforced outcomes, not monitored observations.
Keep recovery outside the model
Do not let a model decide that a safety code can be ignored. The host application should own retry timing, escalation, and operator messaging for infrastructure codes such as ACTIONRAIL_REVIEW_UNAVAILABLE and ACTIONRAIL_CONFIG_STALE.
For diagnostic steps, see Troubleshooting.