Priority Inheritance Rule Definition Prompt

This prompt is for platform architects and AI engineers who need to define how instruction priority propagates through nested or chained system prompts, tool contracts, and policy documents. The core job-to-be-done is producing a machine-readable inheritance specification that prevents silent priority inversions when a parent system prompt delegates authority to a child agent, tool, or sub-prompt. Without explicit inheritance rules, lower-priority instructions in a child context can accidentally override higher-priority constraints from the parent, creating compliance gaps and unpredictable behavior in production.

Use this prompt when you are designing a multi-agent system, a tool-augmented assistant with delegated authority, or a prompt architecture where system instructions must cascade through multiple layers of execution. The ideal user has already defined a priority stack for individual components and now needs to formalize how those priorities compose across boundaries. Required context includes the parent instruction set with explicit priority levels, the child instruction set or tool contract, and any known exception cases where inheritance should break. Do not use this prompt for single-agent priority stacking, runtime directive collision logging, or policy override justification—those are separate workflows with their own dedicated prompts in this content group.

The output is a structured inheritance rule document, not a conversation or a policy memo. It must include parent-child relationship declarations, priority propagation rules, exception conditions, and validation criteria for detecting inheritance chain breaks. Before shipping this into production, you must validate the inheritance rules against known edge cases: nested delegation chains, circular references, tool outputs that carry their own priority claims, and user requests that attempt to exploit inheritance gaps. The prompt includes a validation harness for these checks, but you should also run regression tests against your specific instruction sets. If the inheritance rules will govern high-risk domains such as finance, healthcare, or safety-critical operations, require human review of the generated rules before deployment and log every inheritance decision at runtime for auditability.

This prompt template is designed to produce a structured set of priority inheritance rules from a description of your system's instruction hierarchy. It forces the model to reason about parent-child relationships, exception conditions, and how priority propagates when instructions are nested, chained, or composed. Use this when you need a formal, auditable inheritance specification before implementing instruction priority in your AI platform.

textCopy
You are a priority inheritance rule architect. Your task is to analyze a described instruction hierarchy and produce a formal set of inheritance rules.

## INPUT
Instruction Hierarchy Description:
[INPUT]

## CONSTRAINTS
- [CONSTRAINTS]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "inheritance_rules": [
    {
      "rule_id": "string",
      "parent_instruction": "string",
      "child_instruction": "string",
      "inheritance_type": "full | partial | conditional | none",
      "inherited_priority": "number",
      "conditions": ["string"],
      "exceptions": ["string"],
      "conflict_resolution": "string"
    }
  ],
  "inheritance_chain_validation": {
    "circular_dependencies": ["string"],
    "orphaned_instructions": ["string"],
    "priority_inversions": ["string"]
  },
  "metadata": {
    "total_rules": "number",
    "max_chain_depth": "number",
    "unresolved_ambiguities": ["string"]
  }
}

## INSTRUCTIONS
1. Parse the instruction hierarchy from [INPUT]. Identify all parent-child relationships.
2. For each relationship, determine the inheritance type:
   - **full**: Child inherits parent's priority without modification.
   - **partial**: Child inherits a modified priority based on conditions.
   - **conditional**: Inheritance activates only when specified conditions are met.
   - **none**: Explicit break in inheritance; child has independent priority.
3. Assign an `inherited_priority` value where lower numbers indicate higher precedence.
4. Document all conditions that modify inheritance and all exceptions that override it.
5. Specify how conflicts between inherited and local priority are resolved.
6. Run inheritance chain validation to detect circular dependencies, orphaned instructions, and priority inversions.
7. If [RISK_LEVEL] is "high", flag any rule that could cause silent policy violations for human review.
8. If [EXAMPLES] are provided, use them to calibrate your inheritance logic before processing [INPUT].

Adaptation guidance: Replace [INPUT] with your instruction hierarchy description, including all parent-child relationships and existing priority assignments. Use [CONSTRAINTS] to specify domain-specific rules such as regulatory requirements, tenant isolation boundaries, or deployment environment restrictions. If you have known examples of correct inheritance behavior, provide them in [EXAMPLES] to improve consistency. Set [RISK_LEVEL] to "high" when the inheritance rules govern safety policies, compliance boundaries, or user data access. After generating the rules, always run the inheritance chain validation checks before integrating the output into your production system. For high-risk domains, require human review of any rule flagged with unresolved ambiguities or priority inversions.

This prompt is designed to be called programmatically as part of a policy authoring or system prompt release pipeline. It is not a one-off chat interaction. The primary integration point is a structured API call where the input context—comprising a parent policy, child policies, and the inheritance constraints—is assembled by an upstream service. The output is a machine-readable inheritance rule document that must be validated before it can be committed to a policy registry or injected into a system prompt. Treat the prompt as a deterministic rule generator: given the same inputs and model version, it should produce structurally identical inheritance logic.

Wire the prompt into a CI/CD pipeline for policy changes. A typical harness involves: (1) a pre-processing step that fetches the current policy graph from a versioned store and formats it into the [POLICY_GRAPH] placeholder; (2) a model call with a low temperature (0.0–0.2) to maximize determinism; (3) a post-processing validator that parses the JSON output and checks for inheritance chain completeness, cycle detection, and exception consistency. If validation fails, retry once with the validation errors injected into the [CONSTRAINTS] field. After two failures, escalate for human review. Log every generation attempt, including the input graph hash, model version, output, and validator results, to an audit store for later diff analysis and regression testing.

For production use, pair this prompt with the sibling 'Instruction Priority Regression Test Prompt' to automatically generate test cases from the produced inheritance rules. Before any generated rule document is deployed, run it through a test harness that simulates nested instruction conflicts and verifies that the resolved priority matches the inheritance chain. If your system supports runtime policy binding, integrate the output of this prompt into a late-binding resolution engine that evaluates inheritance at inference time based on tenant or request context. Avoid using this prompt to generate inheritance rules for safety-critical policies without a mandatory human approval gate and a rollback mechanism in your policy registry.