Multi-Stakeholder Consensus Check Prompt

This prompt is designed for collaborative decision-making workflows where an action cannot proceed until multiple designated reviewers have weighed in. The job-to-be-done is to programmatically evaluate a collection of approval responses—each from a different stakeholder—and determine whether a genuine consensus exists. It is not a simple vote counter; it must detect subtle disagreements, blocking concerns, and suppressed objections that a naive tally would miss. The ideal user is a platform engineer or product manager embedding this logic into an enterprise approval system, a compliance officer automating governance gates, or an AI reliability engineer building a human-in-the-loop orchestration layer.

Use this prompt when you have already collected structured feedback from all required reviewers and need a final status determination before executing a high-risk action. The required context includes the original action proposal, the list of required approvers with their roles, and each reviewer's structured response (approve, reject, abstain, or approve with conditions). You should not use this prompt for single-approver workflows, for initial routing decisions about who should approve, or for evaluating the quality of an individual reviewer's feedback. It is also inappropriate for low-stakes decisions where a simple majority vote suffices; the prompt's value lies in catching the edge cases where consensus is ambiguous or fractured.

Before wiring this into production, define what consensus means for your organization: full unanimity, majority with no blocking vetoes, or approval with recorded dissents. The prompt template expects you to supply this definition as a [CONSENSUS_RULES] constraint. Always pair the output with a validation step that checks for false consensus—cases where all reviewers technically approved but one included conditional language that should halt execution. The next section provides the copy-ready template you can adapt to your specific approval schema and organizational policy.

This prompt template is designed to be the core reasoning engine for a multi-stakeholder consensus check. It takes a set of structured approval responses from different reviewers, evaluates them against a defined policy, and determines whether a decision can be made autonomously or if a human escalation is necessary. The template is built to be wired directly into an application's approval workflow, receiving inputs from a database or upstream service and returning a structured, machine-readable consensus status.

textCopy
You are an AI system responsible for evaluating consensus in a multi-stakeholder approval workflow. Your task is to analyze the approval responses from multiple reviewers for a specific action and determine the consensus status. You must strictly adhere to the provided policy, identify dissenting views, and recommend the next step.

## ACTION CONTEXT
[ACTION_DESCRIPTION]
[ACTION_METADATA]

## APPROVAL POLICY
[APPROVAL_POLICY_RULES]

## REVIEWER RESPONSES
[REVIEWER_RESPONSES]

## OUTPUT SCHEMA
You must output a single JSON object with the following structure:
{
  "consensus_status": "reached" | "blocked" | "insufficient_quorum" | "escalation_required",
  "summary": "A concise, one-sentence summary of the overall decision state.",
  "dissenting_views": [
    {
      "reviewer": "[REVIEWER_ID]",
      "concern": "A specific, quoted or paraphrased summary of the blocking concern.",
      "policy_clause_violated": "[POLICY_CLAUSE_REFERENCE]"
    }
  ],
  "next_step": "proceed" | "escalate_to_human" | "request_clarification" | "reopen_for_review",
  "escalation_rationale": "If next_step is escalate_to_human, provide a clear explanation of why automated resolution is not possible. Otherwise, set to null."
}

## CONSTRAINTS
- Consensus is reached only if all required approvers have responded with 'approved' and no blocking concerns are raised.
- A single 'rejected' or 'blocked' response from a required approver must result in a 'blocked' status.
- If a required approver has not responded, the status must be 'insufficient_quorum'.
- If two or more required approvers have conflicting non-blocking conditions, the status is 'escalation_required'.
- Do not fabricate agreement. If a reviewer's response is ambiguous, treat it as a lack of consensus and flag it for human review.

To adapt this template for your specific workflow, replace the square-bracket placeholders with data from your application. [ACTION_DESCRIPTION] and [ACTION_METADATA] should be populated with the details of the proposed action, such as 'Delete production database table X' and its risk score. [APPROVAL_POLICY_RULES] is the most critical variable; it must contain the specific, deterministic rules for your organization, such as 'Requires unanimous approval from Security Lead and Engineering Director for any production data mutation.' The [REVIEWER_RESPONSES] should be a structured list of objects, each containing a reviewer ID, their role, their decision (approved/rejected/abstain), and any comments. Before deploying, test this prompt with a golden dataset of known consensus and deadlock scenarios to ensure the output JSON strictly conforms to the schema and the logic matches your policy.

This prompt is designed to be called after all required stakeholder responses have been collected, not as a real-time streaming function. The application layer should gather each reviewer's decision, their stated rationale, and any conditions or objections into a structured input payload before invoking the model. This separation ensures the model operates on a complete snapshot of the decision state, reducing the risk of premature consensus declarations or missed objections that arrive late.

The implementation should wrap the model call in a validation harness that checks the output schema before the result is acted upon. The consensus status field must be one of a controlled enum: CONSENSUS_REACHED, CONSENSUS_WITH_CONDITIONS, BLOCKED, or ESCALATION_REQUIRED. If the model returns an unrecognized status or fails to include a dissenting_views array when the status is not CONSENSUS_REACHED, the harness should reject the output and retry with a stricter prompt that includes the validation error. For high-stakes decisions, such as production deployments or financial approvals, the system should route any BLOCKED or ESCALATION_REQUIRED result to a human review queue with the full consensus payload attached, rather than automatically acting on the escalation path.

Logging is critical for auditability. Every invocation should record the input stakeholder responses, the raw model output, the validation result, and the final consensus determination. This trace allows teams to debug false consensus cases—where the model declared agreement but a human reviewer later identifies a suppressed objection—by replaying the exact input through updated prompt versions. When deploying, start with a model that has strong instruction-following and structured output capabilities, and avoid using this prompt with models that have known weaknesses in detecting negation or subtle disagreement in long contexts. The next step is to pair this prompt with the Approval Evidence Package Assembly Prompt to ensure reviewers have complete context before they cast their vote.