Override Justification Multi-Stakeholder Synthesis Prompt

This prompt is designed for program managers, governance leads, and audit engineers who need to consolidate multiple override justifications into a single, coherent, and auditable record. The core job-to-be-done is resolving conflicting viewpoints, noting dissenting opinions, and producing a unified justification that accurately represents the collective reasoning of all reviewers. It is ideal when a single override decision has been reviewed by multiple stakeholders—such as a compliance officer, a product manager, and a risk analyst—and you need a definitive, searchable artifact for an audit trail. The prompt requires as input a set of individual justification statements, each attributed to a specific reviewer role, along with the original AI decision and the final override outcome.

Use this prompt when individual justifications contain overlapping, complementary, or contradictory reasoning that must be reconciled into a single narrative. It is appropriate for high-stakes domains like finance, healthcare, and legal compliance where override decisions are subject to internal or external audit. The prompt expects structured inputs: a list of reviewer justifications with role identifiers, the original AI decision context, and any relevant policy references. It should not be used when there is only a single reviewer, when justifications are purely binary (approved/denied) with no substantive reasoning, or when the goal is to simply concatenate statements without synthesis. In those cases, a simpler logging or categorization prompt is more appropriate.

Do not use this prompt to make a new override decision or to evaluate the correctness of the override itself. Its sole purpose is synthesis and conflict representation. The output must preserve individual contributions transparently, flag irreconcilable disagreements for human escalation, and never fabricate consensus where none exists. Before integrating this into a production harness, ensure you have a clear schema for the input justifications and a defined escalation path for the human review of the synthesized output. The next step is to review the prompt template and adapt the placeholders to match your audit record schema and reviewer identity format.

This template is the core engine for consolidating override justifications from multiple reviewers into one coherent, auditable record. It is designed to be copied directly into your prompt management system, IDE, or orchestration layer. The prompt instructs the model to act as a neutral synthesis engine: it must resolve conflicts where consensus exists, preserve dissenting views where it does not, and flag irreconcilable disagreements for human escalation. Use this template when you have at least two distinct override justifications for the same decision event and need a single source of truth for audit trails, compliance reviews, or pattern analysis.

codeCopy
You are an override justification synthesis engine. Your task is to consolidate multiple human override justifications for a single AI decision into one coherent, auditable record. You must resolve conflicts where reviewers agree, preserve dissenting views where they do not, and flag irreconcilable disagreements for escalation.

## INPUT

**Original AI Decision:** [ORIGINAL_AI_DECISION]

**Override Event Context:** [OVERRIDE_EVENT_CONTEXT]

**Reviewer Justifications:**
[REVIEWER_JUSTIFICATIONS]

**Organizational Policy References:** [POLICY_REFERENCES]

## OUTPUT_SCHEMA

Return a valid JSON object with the following structure:
{
  "synthesis_id": "string, unique identifier for this synthesis record",
  "override_event_id": "string, reference to the original override event",
  "synthesized_justification": "string, the consolidated justification narrative",
  "consensus_points": [
    {
      "point": "string, a specific point of agreement across reviewers",
      "supporting_reviewers": ["string, reviewer identifiers who agreed"]
    }
  ],
  "dissenting_views": [
    {
      "view": "string, the dissenting perspective",
      "reviewer": "string, reviewer identifier",
      "reason": "string, why this view differs from the consensus"
    }
  ],
  "irreconcilable_disagreements": [
    {
      "issue": "string, the point of irreconcilable disagreement",
      "positions": [
        {
          "reviewer": "string",
          "position": "string"
        }
      ],
      "recommended_escalation": "string, suggested path for resolution"
    }
  ],
  "policy_alignment": {
    "aligned": "boolean",
    "policy_references": ["string, specific policy sections cited"],
    "gaps_identified": ["string, any policy gaps or ambiguities exposed"]
  },
  "completeness_notes": ["string, any missing information or context that would improve the synthesis"],
  "synthesis_confidence": "string, one of: high, medium, low"
}

## CONSTRAINTS

- Do not fabricate agreement where reviewers disagree.
- Preserve the exact language of dissenting views when quoting them.
- Flag irreconcilable disagreements explicitly; do not force a false consensus.
- Cite specific policy references when evaluating alignment.
- If reviewer justifications are contradictory and cannot be resolved, set synthesis_confidence to "low" and explain why in completeness_notes.
- Do not introduce new justifications not present in the source material.
- If any reviewer justification is missing required fields (reason, risk context, reviewer identity), note this in completeness_notes.

## RISK_LEVEL: [RISK_LEVEL]

## EXAMPLES
[EXAMPLES]

To adapt this template, replace each square-bracket placeholder with your application's data. [ORIGINAL_AI_DECISION] should contain the full context of what the AI system recommended or refused before the override. [OVERRIDE_EVENT_CONTEXT] should include metadata such as timestamp, decision type, affected resources, and urgency. [REVIEWER_JUSTIFICATIONS] expects a structured list of individual override records, each containing the reviewer's identity, their justification text, risk assessment, and any policy citations they referenced. [POLICY_REFERENCES] should be a collection of relevant organizational policy documents or excerpts that govern the decision domain. [RISK_LEVEL] accepts values like "low", "medium", "high", or "critical" and should influence how aggressively the model flags disagreements for escalation. [EXAMPLES] should contain one or two few-shot demonstrations of correctly synthesized outputs, including an example with a dissenting view and one with an irreconcilable disagreement, to calibrate the model's behavior.

Before deploying this prompt into a production harness, validate that the output JSON strictly conforms to the defined schema. Common failure modes include the model collapsing dissenting views into a false consensus, omitting reviewer identifiers from disagreement records, or fabricating policy references not present in the input. Implement a post-generation validation step that checks for required fields, verifies that every reviewer mentioned in the input appears somewhere in the output, and confirms that irreconcilable disagreements are not silently resolved. For high-risk override domains such as clinical, financial, or safety-critical decisions, always route the synthesized output to a human for final review before it is committed to the audit trail.

The Override Justification Multi-Stakeholder Synthesis Prompt is designed to be called after all required reviewers have submitted their individual override justifications. The application layer should collect these justifications into a structured array before invoking the model. Each entry in the array must include the reviewer's identity, role, timestamp, and their full justification text. The prompt expects this array as the [REVIEWER_JUSTIFICATIONS] input, along with the original AI decision context in [ORIGINAL_DECISION] and any relevant policy documents in [POLICY_CONTEXT]. Do not call this prompt until all required approvals are collected or a timeout is reached; partial inputs will produce incomplete syntheses that fail audit requirements.

The implementation harness must enforce several pre-flight validations before model invocation. First, confirm that [REVIEWER_JUSTIFICATIONS] contains at least two distinct reviewer entries—single-reviewer scenarios should bypass synthesis and log the sole justification directly. Second, validate that each justification entry has a non-empty reviewer_id, role, timestamp, and justification_text field. Third, check that [ORIGINAL_DECISION] includes the decision ID, the AI's recommendation, and the action that was overridden. If any validation fails, return a structured error to the caller rather than invoking the model with incomplete data. For high-risk domains, insert a synchronous human approval gate before the synthesis is written to the audit trail—the synthesized output should be presented to a designated approver with accept, revise, or reject options.

After receiving the model's synthesized output, parse the structured JSON response and validate it against the expected [OUTPUT_SCHEMA]. The harness must check that synthesized_justification is non-empty, conflicts_resolved is a boolean, dissenting_views is an array (even if empty), and irreconcilable_disagreements is an array with severity classifications where applicable. If the model output fails schema validation, retry once with the validation errors included in a repair prompt. If the retry also fails, log the raw output and escalate to a human reviewer with the failure context. All successful syntheses must be written to an append-only audit log that links the synthesis record to the original decision ID, individual reviewer justifications, and the final synthesized justification. This log should be immutable and queryable for downstream pattern analysis and compliance reviews.

For production deployments, choose a model with strong instruction-following and structured output capabilities. The prompt requires careful handling of conflicting viewpoints, so models with larger context windows are preferred when synthesizing justifications from many reviewers. Implement request-level logging that captures the prompt version, model identifier, input token count, output token count, latency, and any validation failures. Set a timeout appropriate for your model's typical response latency plus buffer for retries. If the synthesis prompt is part of a larger override workflow, ensure that downstream systems—such as audit trail generators or pattern detection pipelines—consume the validated synthesis output rather than raw model responses. Avoid using this prompt for real-time, latency-sensitive approval flows; it is designed for post-review synthesis where completeness and accuracy matter more than speed.