Veto Authority Routing Prompt for High-Risk Changes

This prompt is designed for risk management and compliance teams implementing veto powers in automated approval workflows. Its specific job is to identify all parties who hold the unilateral authority to block a proposed high-risk change, regardless of any other approvals that may have been granted. Use it when a standard approval chain is insufficient and you need to surface the blocking authority that supersedes all other sign-offs. The ideal user is a platform engineer or compliance officer encoding organizational policy into an AI-driven workflow, where the cost of an unauthorized action is severe.

To use this prompt effectively, you must provide three concrete inputs: a detailed description of the proposed action, its computed risk profile (including risk tier, data sensitivity, and blast radius), and the relevant organizational policy document that defines veto powers. The prompt assumes that veto policies are explicitly documented and that the action context is sufficient to evaluate risk triggers. It is not a general-purpose approval routing tool. Do not use it for low-risk, standard changes where a simple sequential approval suffices, as it will over-engineer the routing and potentially introduce unnecessary blocking points. A concrete implementation would involve feeding a structured [ACTION] object, a [RISK_PROFILE] with scored fields, and a [POLICY_DOCUMENT] text into the template to produce a machine-readable list of veto holders.

The output is a structured list of veto holders, their scope of authority, the specific conditions under which a veto can be exercised, and the formal process for invoking it. Before deploying this prompt, you must implement validation checks for the output, such as verifying that every identified veto holder is explicitly mentioned in the source policy document and that no conflicting veto scopes are generated. In high-risk production environments, the final routing list should always be surfaced to a human for a final sanity check before being encoded into an execution harness. The next step after reading this section is to review the prompt template and adapt the placeholders to match your internal risk taxonomy and policy document structure.

This prompt template is designed to be pasted directly into your AI system. It instructs the model to act as a policy-aware router, analyzing a proposed high-risk change against your organization's defined veto rules. The core job is to output a structured list of who can say no, what they can block, and the precise conditions that grant them that authority. Before using this, ensure you have mapped your organization's veto policies into the [VETO_POLICIES] placeholder; the model cannot infer authority it hasn't been given.

textCopy
System: You are a Veto Authority Router. Your task is to analyze a proposed change against a set of organizational veto policies. You must identify every role that holds veto power over this specific change, define the exact scope of their authority, and state the conditions under which a veto can be exercised. Do not invent authority. If the policies do not grant a clear veto right, state that no veto applies. Your output must be a single, valid JSON object.

Inputs:
- Proposed Change: [PROPOSED_CHANGE_DESCRIPTION]
- Change Context: [CHANGE_CONTEXT]
- Veto Policies: [VETO_POLICIES]
- Organizational Roles: [ORG_ROLES_DIRECTORY]

Output Schema: A JSON object with a single key "veto_authorities" containing an array of objects. Each object must have the following fields:
- "role": (string) The title of the role with veto authority.
- "scope": (string) A precise description of what part of the change this role can veto.
- "condition": (string) The specific policy condition that activates their veto power.
- "veto_process": (string) How the veto is exercised (e.g., 'Formal rejection in change management tool', 'Direct message to incident commander').
- "is_veto_applicable": (boolean) A true/false assessment of whether the condition is met for this change.

Constraints:
- Base your analysis strictly on the provided [VETO_POLICIES] text.
- If a role exists in [ORG_ROLES_DIRECTORY] but is not granted veto power in the policies, do not include them.
- If no veto applies, return an empty array for "veto_authorities".
- Flag any ambiguity in the policies that prevents a clear determination in a final "policy_ambiguities" array of strings.

User: Analyze the proposed change.

To adapt this template, you must first codify your veto rules into the [VETO_POLICIES] block. This is the most critical step. A vague policy like 'Security can veto risky changes' is insufficient; a useful policy states 'The CISO or their delegate can veto any change that introduces a new data egress path to an untrusted network, as defined in policy SEC-104.' The [ORG_ROLES_DIRECTORY] should be a simple mapping of roles to individuals or teams to ground the output. After the model returns the JSON, you must validate it: check that every is_veto_applicable: true entry has a matching, explicit condition in your source policy text. A human reviewer should always confirm the final routing before a veto is enacted or a change is allowed to proceed without one, as a missed veto authority represents a critical control failure.

This prompt is designed to be called as a synchronous gate within a change management or CI/CD pipeline. The application should construct the prompt by injecting the proposed change details, the organizational policy context, and the structured output schema. Because the output determines whether a high-risk action proceeds, the harness must treat the model's response as a structured recommendation, not an executable decision. The application layer retains final authority to block or escalate.

Integration flow: The application assembles the [CHANGE_DETAILS] and [POLICY_CONTEXT] from internal systems (ticketing, IaC plans, deployment manifests). It then calls the model with a strict JSON schema for the output, including fields for veto_holders, veto_scope, and veto_process. On response, the harness must validate the JSON structure, confirm all required fields are present, and check that the identified veto holders map to real, active roles in the identity provider or directory service. If a veto holder is unrecognized or the schema is malformed, the harness should retry once with a repair prompt before escalating to a human operator.

Critical safety checks: Before surfacing the veto routing to any user, the harness must verify that the model did not hallucinate roles or skip a required veto step defined in the policy document. Implement a policy coverage check that compares the extracted veto holders against a known list of required stakeholders for the change's risk tier. If coverage is incomplete, flag the output for human review. Log every invocation—including the prompt, the raw response, validation errors, and the final routing decision—to an append-only audit store. This log becomes the evidence trail for compliance reviews. Never allow the model's output to directly trigger a pipeline stage without this validation layer and a human-in-the-loop confirmation for any change classified as high-risk.