Safety-Critical Action Pre-Approval Prompt

This prompt is designed for engineering teams building AI systems that can initiate actions with physical safety implications—think robotics, industrial control, autonomous vehicles, or medical device actuation. The job-to-be-done is not just to approve or deny an action, but to produce a structured, auditable safety gate decision that classifies hazard severity, specifies required confirmations, and defines blocking conditions before any actuator moves or physical state changes. The ideal user is a platform engineer or AI safety engineer integrating this prompt into a control loop where the model acts as a mandatory checkpoint between intent and execution.

You should use this prompt when the cost of a wrong action is measured in physical harm, equipment damage, or environmental release, not just a bad text output. The prompt requires several concrete inputs to function: a detailed description of the proposed action, the current system state from sensors, the relevant safety policy or operational envelope, and a defined hazard classification schema. It is not suitable for low-risk software-only actions, content generation, or any workflow where a hallucinated approval would only cause a retryable error. Do not use this prompt as a standalone safeguard; it must be part of a defense-in-depth architecture where the model's output is one signal among hardware interlocks, deterministic bounds checks, and independent safety controllers.

The primary constraint is that this prompt must never be the sole gate for high-severity actions. The output should always require human approval for any action classified above 'low' severity, and the system should be architected so that a missing or malformed model response defaults to 'blocked.' Before integrating this prompt, ensure you have a reliable channel for human review, a logging system that captures every gate decision with a unique ID, and a way to test the prompt against a golden dataset of known safe and unsafe actions. The next step is to copy the template, fill in your specific hazard taxonomy and safety policy, and run it against your eval suite before connecting it to any actuator.

This prompt template is designed to be dropped into an application's pre-execution pipeline. It forces the model to act as a deterministic safety gate, not a conversational advisor. The template requires structured inputs describing the proposed action, the system state, and the operational context. It then produces a strict JSON decision object that your application can parse to either block, escalate, or allow the action. The prompt is intentionally rigid—it should not be modified to be more conversational or helpful, as that undermines its function as a safety barrier.

textCopy
SYSTEM: You are a safety-critical action gate. Your only function is to evaluate proposed actions for physical safety risk and output a structured decision. You never execute actions. You never provide advice outside the decision schema. You treat any action that could cause injury, equipment damage, environmental harm, or uncontrolled energy release as safety-critical.

INPUT:
- Proposed Action: [ACTION_DESCRIPTION]
- System State: [SYSTEM_STATE]
- Affected Components: [AFFECTED_COMPONENTS]
- Environmental Conditions: [ENVIRONMENTAL_CONDITIONS]
- Operator Context: [OPERATOR_CONTEXT]
- Safety Policies: [SAFETY_POLICIES]

OUTPUT_SCHEMA:
{
  "decision": "BLOCK" | "ESCALATE" | "ALLOW",
  "hazard_classification": "NONE" | "LOW" | "MEDIUM" | "HIGH" | "CRITICAL",
  "required_confirmations": [
    {
      "confirmation_type": "string",
      "description": "string",
      "required_from": ["string"]
    }
  ],
  "blocking_conditions": ["string"],
  "safety_reasoning": "string",
  "applicable_policy_refs": ["string"]
}

RULES:
1. If hazard_classification is MEDIUM or above, decision must be BLOCK or ESCALATE. Never ALLOW.
2. If any blocking_condition is present, decision must be BLOCK.
3. If the action involves kinetic motion, thermal processes, high voltage, pressurized systems, chemical release, or heavy load movement, hazard_classification must be at least MEDIUM.
4. If operator context indicates insufficient training, missing certifications, or fatigue, escalate.
5. If environmental conditions include wet surfaces, poor visibility, confined spaces, or unstable structures, increase hazard_classification by one level.
6. Every required_confirmation must specify a concrete, verifiable check, not a vague acknowledgment.
7. Safety reasoning must cite specific physical risks, not generic caution.
8. If any required input is missing or ambiguous, decision must be ESCALATE with blocking_conditions explaining what is missing.

CONSTRAINTS:
- Output only valid JSON. No markdown, no commentary.
- Never assume a hazard is absent because it is not mentioned.
- When in doubt, escalate.

To adapt this template, replace each square-bracket placeholder with data from your control plane. [ACTION_DESCRIPTION] should be a machine-generated summary of the exact command or sequence the system intends to execute. [SYSTEM_STATE] must include current sensor readings, lockout/tagout status, and any active maintenance modes. [SAFETY_POLICIES] should be injected from your policy store as structured text, not summarized. After adapting, run the prompt through your eval suite using both safe and unsafe action examples. Any prompt modification that reduces the rate of BLOCK decisions on known-unsafe actions is a regression and must be rejected. Wire the output into your execution controller so that a BLOCK decision physically prevents actuation, not just logs a warning.

The Safety-Critical Action Pre-Approval Prompt is not a standalone chat interaction—it is a synchronous gate that must sit between the AI's action proposal and any actuator, API call, or physical command. The application should call this prompt every time the system considers an action that could cause physical harm, property damage, or safety incidents. The prompt receives a structured description of the proposed action, its context, and the available safety controls, and it returns a decision object that the application must enforce programmatically. Do not treat the model's output as advisory; the application layer must hard-block any action where decision is not approved or where required_confirmations are unsatisfied.

Integration pattern: Wrap the prompt call in a deterministic safety harness. Before calling the model, validate that the input contains all required fields: [ACTION_DESCRIPTION], [AFFECTED_SYSTEMS], [POTENTIAL_HAZARDS], [SAFEGUARDS_IN_PLACE], and [OPERATOR_CONTEXT]. After receiving the model's JSON response, validate the schema strictly—reject any output missing decision, severity_classification, required_confirmations, or blocking_conditions. If validation fails, retry once with a repair prompt that includes the validation error. If the second attempt also fails, default to blocked and escalate to a human reviewer. For actions classified as medium or higher severity, the system must require explicit human confirmation through a review queue before execution proceeds. Log every gate decision, including the full prompt input, model output, validation result, and human confirmation status, to an append-only audit store.

Model choice and latency: Use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature=0 to maximize consistency on safety decisions. The prompt should run synchronously in the critical path; if the model call times out or returns an error, the system must fail closed—block the action and alert an operator. Do not cache safety gate decisions across different action instances, as context changes can alter the hazard profile. For high-frequency action streams, consider batching non-safety-critical pre-checks before invoking this gate, but never skip the gate for any action that meets your defined safety-critical criteria.

Next steps: After integrating the harness, run a battery of eval cases covering each severity level, edge cases like ambiguous hazard descriptions, and adversarial inputs that attempt to downplay risk. Measure false-positive blocking rates (safe actions incorrectly blocked) and false-negative pass-through rates (unsafe actions incorrectly approved). Tune the [CONSTRAINTS] and [RISK_LEVEL] placeholders based on eval results. If false negatives exceed zero, add a secondary human review layer or tighten the blocking conditions in the prompt template. Never remove the human-in-the-loop requirement for high and critical severity classifications.