System Instruction Immutable Core Extraction Prompt

This prompt is for platform engineering and AI safety teams who version system instructions as production code and need to identify the subset of rules that must survive all user interactions, tool errors, and session state changes. The job-to-be-done is extracting an 'immutable core'—the non-negotiable behavioral contract, safety constraints, and role boundaries that no downstream input should override. Use this when you are hardening a system prompt for a long-running agent, a multi-tenant application, or any product where instruction drift or user-injection attacks could cause compliance or brand risk. The ideal user is a prompt architect or AI safety engineer who already has a working system prompt and needs to separate its transient, context-dependent parts from its permanent, policy-level parts.

Do not use this prompt when you are writing a system prompt from scratch, when the application has no multi-turn state, or when all instructions are equally safe to override. It is also the wrong tool for general prompt optimization or style adjustments. This extraction is a structural engineering step, not a copy-editing pass. You must provide a complete system instruction block as input. The prompt works best when the input already has some internal organization—role definitions, policy statements, tool-use rules—that the model can analyze for immutability markers. If your system prompt is a single paragraph of vague guidance, extraction will produce weak results. Before running this prompt, ensure you have a version-controlled copy of the current system prompt and a clear understanding of which regulatory, safety, or product constraints are truly non-negotiable.

The output is not a finished system prompt. It is a structured specification of immutable rules, each tagged with an immutability marker, a recovery instruction for when the rule is violated, and a priority level. You will use this output to refactor your system prompt into layers: an immutable core that sits above all other instructions, and mutable layers for developer directives, user context, and tool outputs. After extraction, you should validate the core against your known non-negotiable constraints, test it against adversarial inputs, and wire it into your instruction hierarchy with explicit precedence rules. The next step is to pair this extracted core with a conflict resolution prompt and an override-detection harness before shipping to production.

This template is designed for platform teams that version prompts as production code and need to identify which system instructions are non-negotiable—the rules that must persist regardless of user override attempts, tool output contamination, or multi-turn drift. The prompt asks the model to analyze a given system instruction set and extract only the rules that should be treated as immutable, producing a structured output that includes immutability markers, recovery triggers, and override-attempt detection criteria. Use this when you are hardening a system prompt for production deployment and need to separate the foundational constraints from negotiable guidance.

codeCopy
You are an instruction hierarchy auditor. Your task is to analyze the provided system instructions and extract only the immutable core—the rules, constraints, and behavioral boundaries that must survive all user interactions, tool outputs, session state changes, and adversarial inputs.

## INPUT
[SYSTEM_INSTRUCTIONS]

## EXTRACTION CRITERIA
Apply these criteria to identify immutable instructions:

1. **Safety and Refusal Rules**: Instructions that define what the system must never do, regardless of user requests or tool outputs.
2. **Role Boundaries**: Instructions that define the system's identity, capabilities, and limitations that users cannot redefine.
3. **Policy Constraints**: Instructions that encode compliance, regulatory, or organizational policies that sit above user and developer directives.
4. **Precedence Declarations**: Instructions that explicitly state which layer wins in conflicts.
5. **Output Format Contracts**: Instructions that define required output structure when downstream parsers or APIs depend on it.
6. **Tool Access and Permission Scopes**: Instructions that limit which tools can be called and under what conditions.

Exclude instructions that are:
- Stylistic preferences or tone guidance that can be safely overridden
- Examples or demonstrations that are illustrative rather than binding
- Contextual suggestions that depend on specific use cases
- Temporary or session-specific directives

## OUTPUT SCHEMA
Return a JSON object with this structure:

```json
{
  "immutable_core": {
    "version": "string identifier for this extraction",
    "extracted_at": "ISO timestamp",
    "rules": [
      {
        "rule_id": "unique identifier",
        "rule_text": "exact immutable instruction text",
        "category": "safety | role_boundary | policy | precedence | output_format | tool_scope",
        "priority": "critical | high | medium",
        "override_attempt_detection": "description of what user or tool behavior would indicate an override attempt",
        "recovery_action": "what the system should do if this rule is violated or overridden"
      }
    ],
    "conflict_resolution_order": ["ordered list of categories by precedence"],
    "immutability_markers": ["phrases or patterns that signal this rule cannot be overridden"]
  },
  "excluded_instructions": [
    {
      "instruction_text": "text that was excluded",
      "exclusion_reason": "why this instruction is not immutable"
    }
  ],
  "coverage_gaps": [
    "areas where the system instructions lack immutable coverage that should be added"
  ]
}

CONSTRAINTS

• Do not modify or rephrase the original instruction text in rule_text. Preserve it exactly.
• If an instruction is partially immutable, extract only the immutable portion and note the exclusion.
• Flag any instructions that appear to conflict with each other in coverage_gaps.
• If no instructions meet the extraction criteria for a category, return an empty array for that category's rules.
• Do not invent rules that are not present in the input.

RISK_LEVEL

[RISK_LEVEL]

If RISK_LEVEL is "high", apply stricter extraction: treat all role boundary and policy instructions as critical priority by default, and flag any instruction that could be interpreted as negotiable for human review.

After copying this template, replace [SYSTEM_INSTRUCTIONS] with the full text of your system prompt or instruction set. Set [RISK_LEVEL] to "high" for regulated domains, customer-facing systems, or any application where instruction override could cause harm. For internal tools or low-risk workflows, use "medium" or "low" to allow the model more discretion in classifying immutability. The output JSON should be validated against the schema before being used to harden your production prompt. Run this extraction on every system prompt version before deployment, and store the resulting immutable core alongside your prompt version history for auditability.

This prompt is designed to be invoked as a pre-processing gate before any system instruction is deployed or versioned. It should not run in the hot path of user-facing requests. Instead, call it inside a CI/CD pipeline, a prompt management UI, or an admin API endpoint whenever a new system instruction candidate is submitted. The prompt expects a complete system instruction block as [SYSTEM_INSTRUCTION] and returns a structured JSON extraction that separates the immutable core from mutable policy, persona, or formatting layers. The output is not the final system prompt; it is the extracted invariant that downstream assembly steps will wrap with environment-specific context.

Wiring the prompt into an application requires a thin service layer that handles model invocation, response parsing, and validation. Use a model with strong instruction-following and JSON mode (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature=0 and enable structured output mode if available. After receiving the JSON response, validate it against a strict schema: the immutable_core field must be a non-empty string, extraction_criteria must be a non-empty array of strings, and override_recovery_instructions must be present. If validation fails, retry once with the validation errors appended to the prompt as [PREVIOUS_ERRORS]. If the second attempt fails, log the failure and block the deployment. Never silently accept a malformed extraction.

Logging and audit requirements are critical because this extraction defines what rules survive all user interactions. Store the extracted immutable core alongside the original system instruction, the model version used, the extraction timestamp, and the full JSON response. This creates an audit trail that connects every deployed system prompt version to its extracted core. For regulated environments, require human approval on the diff between the original instruction and the extracted core before the core is committed to the prompt registry. The approval step should flag any instruction that was classified as mutable but the reviewer considers essential, or vice versa.

Failure modes to monitor include: the model extracting too little (an empty or trivial core that drops essential safety rules), extracting too much (treating stylistic preferences as immutable), or misclassifying override recovery instructions. Implement a post-extraction diff check that warns if the immutable core is less than 20% or more than 80% of the original instruction length. These thresholds are heuristics, not hard rules, but they catch common extraction errors. Also monitor for extraction drift: if the same instruction produces a materially different core after a model version upgrade, flag it for human review before the new core replaces the old one.

Integration with prompt assembly is the next step after extraction succeeds. The immutable core becomes the innermost, highest-priority layer in your instruction hierarchy. Downstream assembly prompts wrap it with role-specific formatting, tool-use permissions, session state handling, and user-facing tone guidelines. The core itself should never be edited by assembly logic. When a new system instruction is submitted, re-run this extraction prompt, validate the output, and only then update the core in the prompt registry. This ensures that every deployed system prompt inherits a verified, extraction-tested immutable foundation.