Minor Safety Policy Prompt Template

This prompt template is for trust and safety engineers, product policy leads, and AI safety architects who need to embed a concrete, testable minor safety policy directly into a system prompt. The job-to-be-done is not drafting a legal document but creating an operational policy layer that defines age-appropriate content boundaries, triggers mandatory reporting escalation, and specifies guardian notification rules. You should use this when your AI product serves or may encounter users under 18, and you need a structured, enforceable set of instructions that survives multi-turn conversations and adversarial probing. The required context includes your jurisdiction's mandatory reporting thresholds, your product's specific age-gating mechanisms, and the escalation path for a human review queue.

This template is appropriate when you control the system prompt and can enforce its instructions through your application architecture. It assumes you have a method for detecting or receiving a user's age status, which you will inject into the prompt via the [USER_AGE_STATUS] placeholder. The prompt is designed to be used as a dedicated policy block within a larger system prompt, separated by XML tags or similar delimiters to maintain instruction hierarchy. You should adapt the [DISALLOWED_CONTENT_CATEGORIES] and [MANDATORY_REPORTING_TRIGGERS] to match your specific platform policies and legal requirements. The output is not a final answer to a user but a set of behavioral constraints that govern the model's subsequent responses and tool calls.

Do not use this prompt template as a substitute for legal review or as a standalone compliance mechanism. It is an operational policy template that must be reviewed by legal counsel and adapted to your jurisdiction. This prompt is insufficient if your product requires age verification at the account level, if you cannot reliably pass age status into the model context, or if your application allows users to bypass system instructions through the user interface. In those cases, you need product-level controls such as hard-coded age gates, authenticated user attributes, and UI restrictions before this prompt layer becomes effective. After adapting this template, your next step is to build a test suite of adversarial inputs and multi-turn scenarios to validate that the policy holds under pressure.

This template encodes heightened protections for interactions involving or concerning minors. It is designed to be placed in the system prompt layer of your AI application and must be customized with your organization's specific definitions, reporting obligations, and escalation procedures. The policy covers age-detection scenarios, content boundary enforcement, guardian notification triggers, and mandatory report criteria. Before deployment, every square-bracket placeholder must be replaced with concrete, testable rules that your trust and safety team has reviewed.

markdownCopy
## MINOR SAFETY POLICY (v[POLICY_VERSION])

### 1. Scope and Activation
This policy activates when:
- The user self-identifies as under the age of [AGE_OF_MAJORITY]
- The conversation content indicates the user is likely a minor based on [AGE_DETECTION_INDICATORS]
- The user discusses or requests content involving individuals under [AGE_OF_MAJORITY]
- The system processes data known to belong to a minor user account

### 2. Content Boundaries
When this policy is active, the following are strictly prohibited:
- [LIST_DISALLOWED_CONTENT_CATEGORIES]
- Solicitation of personal information beyond [ALLOWED_PII_FIELDS]
- Content that encourages or depicts [LIST_RESTRICTED_ACTIVITIES]
- Generation of content rated above [MAXIMUM_CONTENT_RATING]

### 3. Response Protocol
For any request that falls within prohibited categories:
1. Do not fulfill the request, even partially.
2. Do not explain how the request could be fulfilled.
3. Respond with: "[SAFE_REFUSAL_MESSAGE]"
4. If the request involves [MANDATORY_REPORT_TRIGGERS], immediately set a flag: `[ESCALATION_FLAG]` and append `[GUARDIAN_NOTIFICATION_NOTICE]` to the response.

### 4. Ambiguity Handling
If you are uncertain whether the user is a minor or whether content involves a minor:
- Default to the safer interpretation.
- Do not ask the user to confirm their age if the request itself is suspicious.
- Log the interaction with reason: `[AMBIGUITY_LOG_CODE]`.

### 5. Escalation and Reporting
- Trigger: [ESCALATION_TRIGGER_LIST]
- Action: Invoke tool `[ESCALATION_TOOL_NAME]` with payload `[ESCALATION_PAYLOAD_SCHEMA]`.
- Human Review Queue: Route to `[REVIEW_QUEUE_NAME]` with priority `[PRIORITY_LEVEL]`.

### 6. Override Conditions
This policy may only be overridden by:
- Verified parental consent token: `[CONSENT_TOKEN_FORMAT]`
- Internal admin override with reason code from: [ADMIN_OVERRIDE_REASON_CODES]

Adapt this template by working with your legal and trust and safety teams to define each placeholder precisely. Vague policies are unenforceable. For example, instead of [LIST_DISALLOWED_CONTENT_CATEGORIES], specify exact categories like sexual content involving minors, solicitation of real-world contact, or graphic violence directed at children. Each category should have corresponding eval test cases. The escalation tool name and payload schema must match an actual implemented function in your application layer; a prompt that references a non-existent tool creates a silent failure mode. After customization, run this policy through the adversarial input refusal test cases and multi-turn refusal consistency checks described in the sibling playbooks to verify it holds under pressure.

The Minor Safety Policy Prompt is not a standalone safety layer; it is a policy injection point that must be embedded within a larger system prompt architecture. The prompt template should be placed in the system instructions after the assistant's core role definition but before any tool-use authorization blocks. This ensures that age-appropriate content boundaries and escalation triggers take precedence over task completion instructions. In a typical implementation, the application layer must supply the [DETECTED_AGE_INDICATOR] and [CONVERSATION_CONTEXT] variables before the prompt is assembled and sent to the model. These variables should never be derived solely from user self-reporting; the application must combine multiple signals such as account registration data, parental consent flags, and behavioral heuristics before populating the age indicator field.

The implementation harness must include a pre-generation validation step that checks whether the [DETECTED_AGE_INDICATOR] is present and falls within a defined underage threshold. If the age indicator is missing or ambiguous, the system should default to the most restrictive policy tier rather than bypassing safety rules. After the model generates a response, a post-generation validator must scan the output for mandatory escalation phrases defined in the prompt, such as guardian notification language or report criteria triggers. If the model's response contains content that should have been refused but was not, the validator must block the output and either retry with a stronger policy instruction or escalate directly to a human review queue. Retry logic should be bounded: after two failed attempts, the system must escalate rather than loop indefinitely.

Logging and observability are critical for this prompt because under-enforcement failures carry regulatory and reputational risk. Every invocation must log the supplied age indicator, the conversation context summary, the model's raw output, and the post-generation validation result. These logs must be retained in a format that supports audit review, and personally identifiable information in the conversation context should be redacted before logging unless retention is required for compliance reasons. For high-risk deployments, implement a human-in-the-loop review step for any output that triggers the escalation criteria defined in the prompt. The review interface should surface the original user input, the detected age indicator, the model's proposed response, and the specific policy rule that was triggered. Do not deploy this prompt without first running the adversarial test cases from the companion Adversarial Input Refusal Test Prompt Template and measuring both under-refusal and over-refusal rates against a labeled evaluation dataset.