Crisis Helpline Referral Prompt Template

This prompt is designed for safety-critical AI systems that must detect when a user is in crisis and respond with appropriate helpline referrals rather than generic refusals, unhelpful disclaimers, or continuing the conversation as if nothing was detected. Use this prompt when your application handles user-generated text where crisis signals such as self-harm, suicidal ideation, abuse disclosure, or severe mental health distress may appear. The prompt produces a structured crisis classification, relevant helpline information matched to the user's stated or inferred location, and warm handoff language that de-escalates and connects the user to human support.

This is not a general safety refusal prompt. It is specifically for crisis referral workflows where the correct response is compassionate connection to professional help, not a policy-driven refusal. The prompt assumes you have already determined that a crisis signal may be present and need a reliable, structured referral output. It does not replace human escalation protocols, emergency services, or clinical triage. Every output must be reviewed by a human before deployment in a live user-facing system. Do not use this prompt for general content moderation, policy violation classification, or refusal correctness testing—those workflows have separate playbooks with different output contracts and evaluation criteria.

Before implementing this prompt, confirm that your application has a clear escalation path to human reviewers, that your helpline database is current and jurisdictionally accurate, and that your logging captures the full prompt input and output for audit. The prompt is a structured referral generator, not a crisis detection classifier. If you need to first determine whether a crisis signal exists, pair this with a classification routing prompt upstream. Never deploy this prompt without a human-in-the-loop review step, and never treat its output as a substitute for contacting emergency services when immediate danger is indicated.

This prompt template is designed for safety-critical systems that must detect crisis signals in user messages and respond with appropriate helpline referrals instead of generic refusals or unhelpful responses. The template uses square-bracket placeholders that you must replace with your application's specific data before sending to the model. Each placeholder represents a critical input that shapes the model's crisis detection sensitivity, referral accuracy, and response tone. The template is structured to produce a consistent output schema that downstream systems can parse reliably.

textCopy
You are a crisis detection and referral assistant operating within a safety-critical system. Your role is to analyze user messages for signals of immediate crisis, self-harm, harm to others, or severe mental health distress. You must classify the crisis level, provide appropriate helpline information, and generate warm handoff language that encourages the user to seek help.

## INPUT
User Message: [USER_MESSAGE]
Conversation History (last 5 turns): [CONVERSATION_HISTORY]
User Location (country/region): [USER_LOCATION]
User Language Preference: [USER_LANGUAGE]

## CRISIS DETECTION POLICY
[CUSTOM_CRISIS_POLICY]

## AVAILABLE HELPLINE RESOURCES
[HELPLINE_DATABASE]

## OUTPUT SCHEMA
You must respond with a valid JSON object matching this schema:
{
  "crisis_detected": boolean,
  "crisis_category": string | null, // One of: "self_harm", "suicidal_ideation", "harm_to_others", "severe_distress", "domestic_violence", "substance_crisis", "child_safety", "other", null
  "confidence_score": number, // 0.0 to 1.0
  "immediacy": string | null, // One of: "immediate_danger", "high_concern", "moderate_concern", "low_concern", null
  "primary_helpline": {
    "name": string | null,
    "phone": string | null,
    "text_line": string | null,
    "website": string | null,
    "hours": string | null,
    "language_support": string | null
  } | null,
  "alternative_helplines": [
    {
      "name": string,
      "phone": string | null,
      "text_line": string | null,
      "website": string | null,
      "relevance_reason": string
    }
  ],
  "referral_message": string | null, // Warm handoff message to show the user
  "escalation_required": boolean, // True if immediate human intervention is needed
  "evidence_quotes": [string], // Exact quotes from user message supporting the classification
  "uncertainty_notes": string | null // Any ambiguity or factors that complicate the assessment
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Analyze the user message for crisis signals using the provided crisis detection policy.
2. If no crisis signals are detected, set crisis_detected to false and all crisis-related fields to null. Do not fabricate concerns.
3. If crisis signals are detected, classify the category, immediacy, and confidence based on the evidence.
4. Select the most appropriate helpline from the provided helpline database based on the user's location, language, and crisis category.
5. Generate a warm, non-judgmental referral message that includes the helpline information and encourages help-seeking.
6. Include exact quotes from the user message that support your classification in the evidence_quotes field.
7. If the situation appears to involve immediate danger, set escalation_required to true.
8. If you are uncertain about any aspect of the classification, document this in uncertainty_notes.
9. Do not provide counseling, diagnosis, or therapeutic advice. Your role is detection and referral only.
10. If the user message is ambiguous, err on the side of providing helpline information with a low confidence score rather than dismissing potential crisis signals.

To adapt this template for your application, replace each square-bracket placeholder with real data at runtime. The [CUSTOM_CRISIS_POLICY] placeholder should contain your organization's specific definitions of crisis categories, detection thresholds, and escalation criteria. The [HELPLINE_DATABASE] should include structured records of available helplines with coverage areas, hours, languages, and contact methods. The [CONSTRAINTS] placeholder allows you to add domain-specific rules such as jurisdictional reporting requirements, age-tiered handling, or prohibited response patterns. The [EXAMPLES] placeholder should contain few-shot examples that demonstrate correct classification across your crisis categories, including edge cases where crisis signals are ambiguous or where the user is discussing crisis hypothetically. Always validate the output against the schema before surfacing the referral message to users, and ensure a human review path exists for high-confidence crisis detections.

The Crisis Helpline Referral prompt must never operate as a standalone, unmonitored text generator. It belongs inside a safety-critical harness that validates every output before it reaches a user, logs decisions for audit, and escalates ambiguous cases to human review. The harness is the difference between a prompt that sometimes works and a system that can be trusted in production. At minimum, the harness must enforce output schema compliance, verify that any returned helpline information matches an approved, up-to-date resource list, and block responses that contain contradictory signals (e.g., a crisis_detected: false classification alongside a helpline phone number).

Wire the prompt into your application as a gated inference step, not a direct user-facing response. After the model returns its structured output, run a validator that checks: (1) the crisis_detected field is a boolean, (2) if crisis_detected is true, the helpline_referral object contains a non-empty organization_name, phone_number, and warm_handoff_text, (3) every phone number and URL matches an allowlist of verified helpline resources, and (4) the confidence_score is above your configured threshold (start at 0.85 for automated responses, route anything below to review). If validation fails, retry once with the same prompt and a stronger [CONSTRAINTS] block that emphasizes the exact schema. If the retry also fails, escalate to a human moderator and log the raw input, model output, and validator errors as a single incident record. For model choice, prefer a model with strong instruction-following and low refusal drift on safety content—Claude 3.5 Sonnet or GPT-4o are reasonable defaults, but run your own calibration suite against your crisis taxonomy before locking in a model version.

Logging is non-negotiable. Every inference must produce an audit record containing: the [INPUT] text (redact PII before storage), the full structured output, the validator pass/fail result, the model ID and version, the timestamp, and whether the response was served automatically or escalated. These logs feed two critical downstream workflows: false-positive analysis (did the system flag a non-crisis message and offer a helpline?) and false-negative detection (did the system miss a genuine crisis signal?). Run a weekly eval job that samples logged decisions against a golden test set of crisis and non-crisis messages, and alert if precision or recall drops below your safety threshold. Do not rely on user reports alone—most users in crisis will not file feedback.

Human review integration should follow a warm escalation pattern. When the harness escalates a case (low confidence, validator failure, or ambiguous classification), place it in a prioritized review queue with a short SLA (under 2 minutes for crisis workflows). The reviewer sees the original user message, the model's output, and the specific reason for escalation. They can approve, override, or discard the response. Every human decision should be logged and fed back into your eval pipeline to measure judge alignment and detect systematic model weaknesses. Avoid the temptation to skip human review for 'probably fine' cases—the cost of a missed crisis signal is catastrophic, and the harness exists precisely to catch the edge cases where the model is uncertain.