Developer Directive vs User Preference Resolution Prompt

This prompt is for product teams building configurable AI features where a developer or administrator sets system-wide defaults, but end users can override those preferences. The core job is to produce a deterministic resolution framework that decides which preference wins when a user's request contradicts a developer's directive. Use this when you need an explicit, auditable tie-breaking logic that prevents silent overrides, respects user opt-out boundaries, and preserves developer guardrails. The ideal reader is an engineering lead or AI product manager who must ship a preference system that behaves predictably under ambiguity and adversarial input.

Do not use this prompt when preferences are purely cosmetic and carry no safety, compliance, or business-logic weight. If the conflict is between a system-level safety policy and a user request, use the Safety Constraint Supremacy Prompt Template instead—this prompt assumes both developer directives and user preferences are legitimate, non-safety configurations. The prompt requires you to supply the specific developer directive, the conflicting user preference, the product context, and any explicit opt-out boundaries. Without these inputs, the model will invent a generic resolution that may not match your product's actual rules.

Before wiring this into production, define the output schema you expect: a structured resolution object that includes the winning preference, the rule that decided it, a user-facing explanation, and a flag for cases that require human review. Test against preference inversion cases where the user's stated preference is accidentally discarded, and silent override cases where the developer directive is ignored without logging. If the resolution affects billing, data access, or regulated features, route ambiguous conflicts to a human review queue. This prompt is a component in a larger instruction hierarchy—pair it with the Instruction Priority Declaration Prompt Template to establish the full precedence stack.

This prompt template provides a structured framework for resolving conflicts between developer directives and user preferences in configurable AI applications. It is designed to be copied directly into your prompt management system, with square-bracket placeholders that you replace with your specific rules, preferences, and constraints. The template establishes a clear precedence hierarchy, defines when user preferences can override developer defaults, and specifies boundaries that users cannot cross.

textCopy
SYSTEM INSTRUCTION: You are a configuration resolution engine. Your task is to resolve conflicts between developer-set defaults and user-specified preferences according to the following precedence rules.

PRECEDENCE RULES (highest to lowest):
1. SAFETY CONSTRAINTS: [SAFETY_RULES] — These cannot be overridden by any preference.
2. REGULATORY REQUIREMENTS: [COMPLIANCE_RULES] — These cannot be overridden by any preference.
3. DEVELOPER GUARDRAILS: [GUARDRAIL_RULES] — Users may opt out only where explicitly permitted below.
4. USER PREFERENCES: [USER_PREFERENCE_SCOPE] — Applied when no higher-priority rule conflicts.
5. SYSTEM DEFAULTS: [DEFAULT_BEHAVIOR] — Applied when no user preference is specified.

OPT-OUT BOUNDARIES:
- Users MAY override: [OVERRIDEABLE_DEFAULTS_LIST]
- Users MAY NOT override: [NON_OVERRIDEABLE_DEFAULTS_LIST]
- Users require explicit confirmation to override: [CONFIRMATION_REQUIRED_LIST]

CONFLICT RESOLUTION PROCEDURE:
1. Identify all active directives from developer defaults and user preferences.
2. Check each directive against the precedence hierarchy from top to bottom.
3. If a user preference conflicts with a higher-priority rule, reject the preference and explain why.
4. If two directives at the same level conflict, apply tie-breaking rule: [TIE_BREAKING_RULE].
5. If ambiguity remains after tie-breaking, apply default: [AMBIGUITY_DEFAULT].

OUTPUT FORMAT:
Return a JSON object with the following structure:
{
  "resolved_configuration": { /* final merged configuration */ },
  "overrides_applied": [ /* list of user preferences that were applied */ ],
  "overrides_rejected": [
    {
      "preference": "user's requested preference",
      "reason": "which higher-priority rule blocked it",
      "rule_reference": "specific rule identifier"
    }
  ],
  "warnings": [ /* any cautionary notes about the resolution */ ],
  "requires_human_review": boolean
}

INPUT:
Developer Defaults: [DEVELOPER_DEFAULTS]
User Preferences: [USER_PREFERENCES]
Context: [CONTEXT]

To adapt this template, replace each square-bracket placeholder with your specific rules and values. The [SAFETY_RULES] and [COMPLIANCE_RULES] placeholders should contain non-negotiable constraints that no user preference can override. The [OVERRIDEABLE_DEFAULTS_LIST] and [NON_OVERRIDEABLE_DEFAULTS_LIST] define the boundary between user freedom and developer control. For high-risk applications, ensure that [CONFIRMATION_REQUIRED_LIST] captures preferences that need explicit user acknowledgment before application. The [TIE_BREAKING_RULE] should specify a deterministic method such as 'prefer the more restrictive option' or 'defer to the most recently specified preference.' Always test the resolved output against your evaluation criteria before deploying to production, and log all override rejections for audit and debugging purposes.

This prompt is designed to sit between a developer-defined configuration layer and a user-facing preference interface. In practice, it should be invoked whenever a user preference change request conflicts with a developer-set default or constraint. The application should call this prompt before writing the resolved preference to the user's profile or session state, not after. The prompt expects three structured inputs: the developer directive (a non-overridable rule or default), the user's stated preference, and the resolution context (e.g., feature area, risk level, regulatory flags). The output is a structured resolution object that downstream code can act on without further interpretation.

Wire this prompt into a resolution service that is called synchronously during preference update flows. The service should validate the model's output against a strict JSON schema before accepting it. Key validation checks include: the resolution_decision field must be one of APPLY_USER_PREFERENCE, APPLY_DEVELOPER_DIRECTIVE, or APPLY_COMPROMISE; the override_justification field must be non-empty when the developer directive wins; and the user_communication field must contain a plain-language explanation suitable for display. If validation fails, retry once with the same inputs and a stronger constraint instruction appended. If the retry also fails, fall back to APPLY_DEVELOPER_DIRECTIVE and log the failure for review. For high-risk domains such as healthcare or finance, route any APPLY_COMPROMISE decision to a human review queue before applying it to the user's account.

Log every resolution event with the full input payload, the model's raw output, the validation result, and the final applied decision. This audit trail is essential for debugging silent overrides and for demonstrating compliance with regulatory requirements around user consent and developer control. Avoid caching resolution results across different users or contexts—preference conflicts are often context-specific, and a cached resolution from one feature area may not apply to another. When deploying changes to the developer directives, run a regression suite of known conflict scenarios to verify that the resolution behavior remains consistent and that no new silent override patterns emerge.