Safety Override Event Trace Analysis Prompt

This prompt is designed for platform engineers and trust and safety reviewers who need to audit a production trace where a safety filter was intentionally overridden. The core job-to-be-done is transforming a raw, multi-step trace—containing the original refusal, the authorization event, and the final output—into a single, structured, and human-readable audit record. This record is essential for post-incident review, access control validation, or preparing evidence for a compliance audit. The ideal user is someone who already has the full trace data available and needs to extract a verifiable, non-technical summary of the override event, not someone making a real-time blocking decision.

The prompt assumes you are working with a complete trace that includes at least three critical components: the model's initial safety refusal, a subsequent event where an authorized user or system explicitly overrode that refusal, and the final output generated after the override. It requires you to provide a justification for the override, the identity of the authorizer, and the full trace text as input. The output is a structured JSON object that captures all these elements, along with a timestamp and a unique event ID, creating a tamper-evident record. A key constraint is that this prompt is for analyzing authorized overrides only. It is not designed for, and should not be used for, analyzing unauthorized bypass attempts or malicious prompt injection, which require a different forensic analysis approach.

Before using this prompt, ensure the trace data is complete and that the override event is clearly identifiable. The primary failure mode is using this prompt on a trace where the override was not intentional or authorized, which will produce a misleading audit record that falsely implies a legitimate process was followed. The next step after generating this audit record is to route it to a human reviewer for final sign-off, especially in high-risk or regulated domains. Do not treat the structured output as a final compliance artifact without human verification. For analyzing unauthorized bypass attempts, use the 'Safety Filter Bypass Attempt Trace Review Prompt' instead.

This prompt template is designed to be copied directly into your AI harness, observability pipeline, or manual review tool. It instructs the model to parse a raw production trace where a safety filter was intentionally overridden and produce a structured JSON audit record. The template uses square-bracket placeholders for all dynamic inputs, making it straightforward to wire into an application that injects trace data, policy documents, and output schemas at runtime.

textCopy
Analyze the following production trace where a safety filter was intentionally overridden. Produce a structured audit record in JSON format.

[TRACE_DATA]

Required output fields:
- `override_authorized_by`: The user ID, role, or system that authorized the override. If missing, set to null and flag as incomplete.
- `justification_provided`: The exact justification text from the trace. If missing, set to null and flag as incomplete.
- `original_refusal_message`: The refusal message the safety filter generated before the override. If missing, set to null and flag as incomplete.
- `final_output_delivered`: The content that was ultimately returned to the user after the override. If missing, set to null and flag as incomplete.
- `policy_compliance_assessment`: One of 'compliant', 'non_compliant', or 'indeterminate'. Assess whether the override followed the documented override policy.
- `missing_fields`: An array of field names that were missing from the trace and could not be populated.
- `notes`: Any additional observations, risks, or recommendations for human review.

[OVERRIDE_POLICY]

[OUTPUT_SCHEMA]

[CONSTRAINTS]
- Do not invent information not present in the trace.
- If the justification references external factors not visible in the trace, note this in `notes`.
- Flag any override that lacks a clear authorization trail for immediate human review.
- If the final output contains content that would normally violate safety policy, explicitly call this out in `notes`.

To adapt this template, replace [TRACE_DATA] with the full production trace, including the user request, the safety filter activation event, the override authorization event, and the final model response. Replace [OVERRIDE_POLICY] with your organization's documented policy for safety overrides—this is critical because the model needs the policy text to assess compliance. Replace [OUTPUT_SCHEMA] with your exact JSON schema if you need additional fields or stricter typing. The [CONSTRAINTS] section is a starting point; add domain-specific rules such as regulatory requirements, data retention flags, or escalation criteria. In high-risk environments, always route the generated audit record to a human reviewer before closing the incident. For batch processing, consider adding a [RISK_LEVEL] placeholder that gates whether the trace goes to automated review or mandatory human escalation.

This prompt is designed to be called programmatically as part of a post-incident review pipeline, not as a one-off chat interaction. The implementation harness must treat every override event as a high-severity audit record. Wire the prompt into a workflow that triggers automatically when an override flag is set in your production trace store—typically via a webhook from your safety proxy, a scheduled job scanning override logs, or an on-demand review queue. The harness should fetch the full trace payload (user input, original refusal, override authorization metadata, and final output) and inject it into the prompt's [TRACE_JSON] placeholder. Never pass only the final output; the analysis depends on the complete decision chain.

Validation and retries: Parse the model's JSON output against a strict schema that requires the override_authorization object (with authorized_by, justification, and timestamp fields), the original_refusal block, the final_output summary, and the audit_verdict enum (COMPLIANT, NON_COMPLIANT, INSUFFICIENT_EVIDENCE). If parsing fails or required fields are missing, retry once with a repair prompt that includes the raw output and the schema. If the retry also fails, escalate to a human review queue with the raw trace and both model outputs attached. For NON_COMPLIANT or INSUFFICIENT_EVIDENCE verdicts, the harness must automatically create a ticket in your incident management system and notify the security or compliance team. Do not auto-resolve these cases.

Model choice and logging: Use a model with strong structured output capabilities and a low-latency profile for this task—GPT-4o or Claude 3.5 Sonnet are appropriate defaults. Enable structured output mode (JSON mode or tool calling with a defined schema) rather than relying on free-text parsing. Log every invocation: store the prompt version, model version, input trace hash, output JSON, parse success/failure, retry count, and final verdict in an append-only audit table. This log becomes your evidence trail for external auditors. Human review gate: For any trace where the override justification references an emergency or exceptional circumstance, flag the record for mandatory human review regardless of the model's verdict. The prompt is an accelerant for audit triage, not a replacement for accountability.