Approval Evidence Package Assembly Prompt

This prompt is designed for a single, high-stakes job: assembling a complete, structured evidence package for a human reviewer who must approve or deny a pending action. The ideal user is a governance, compliance, or audit engineer embedding this prompt into an AI workflow where the cost of an uninformed approval is severe. The prompt ingests a proposed action, its full audit trail, and all relevant organizational policies, then outputs a single, review-ready document. It is not for generating the approval decision itself, but for ensuring the human decision-maker has every required piece of context in one place, with gaps explicitly flagged.

Use this prompt when the approval decision is irreversible, regulated, or high-risk—such as a production database deletion, a financial transfer above a threshold, or a security group change. It is appropriate when the evidence needed for a decision is scattered across systems (ticketing, logging, HR directories, policy docs) and must be unified. The prompt's core value is its completeness check: it cross-references the action against a provided [EVIDENCE_REQUIREMENTS] schema and lists any missing items, such as a lack of a rollback plan or an absent peer review. Do not use this prompt for low-risk, auto-approved actions where the overhead of assembly outweighs the risk. It is also a poor fit for real-time, latency-sensitive user-facing chats; this is a backend, batch-oriented governance tool.

Before using this prompt, you must have a well-defined [EVIDENCE_REQUIREMENTS] schema that acts as the completeness checklist. This schema is the contract that defines what 'complete' means for your organization. The prompt will strictly adhere to this schema, so an incomplete or poorly designed schema will lead to a false sense of security. The output is a structured JSON package, not a conversational summary, making it suitable for direct ingestion by a downstream approval dashboard or a human review queue. The next step after assembly is to route this package to the correct human reviewer, a task handled by a separate routing prompt. Avoid the temptation to have this prompt also make the approval decision; its job is to inform, not to judge.

The following prompt template is designed to be copied directly into your AI harness. It takes a pending action, its operational context, and relevant policy documents, and produces a structured evidence package ready for a human reviewer. The template uses square-bracket placeholders for all dynamic inputs, ensuring you can adapt it to your specific governance workflows without modifying the core instruction logic.

textCopy
You are an audit evidence assembly specialist. Your task is to compile a complete, structured evidence package for a pending action that requires human approval. The package must be self-contained, allowing a reviewer to make an informed decision without consulting external systems.

## Inputs
- Pending Action: [PENDING_ACTION_DETAILS]
- Requester Identity: [REQUESTER_IDENTITY]
- Action Context: [ACTION_CONTEXT]
- Relevant Policies: [POLICY_DOCUMENTS]
- Risk Assessment: [RISK_ASSESSMENT]
- Previous Related Approvals: [PREVIOUS_APPROVALS]
- System State Snapshot: [SYSTEM_STATE]

## Output Schema
Produce a JSON object conforming to this structure:
{
  "package_id": "string, a unique identifier for this evidence package",
  "generated_at": "string, ISO 8601 timestamp",
  "action_summary": {
    "description": "string, plain-language summary of the action",
    "requester": "string, who is requesting this action",
    "request_timestamp": "string, when the action was requested",
    "action_type": "string, category of the action (e.g., 'data_deletion', 'config_change', 'access_grant')",
    "target_resources": ["list of strings, affected resources or systems"]
  },
  "risk_profile": {
    "risk_score": "number, 0-100",
    "risk_level": "string, one of 'low', 'medium', 'high', 'critical'",
    "key_risk_factors": ["list of strings, specific risks identified"],
    "mitigating_controls": ["list of strings, controls already in place"]
  },
  "policy_alignment": [
    {
      "policy_ref": "string, reference to the specific policy clause",
      "requirement": "string, what the policy requires",
      "status": "string, one of 'compliant', 'non_compliant', 'requires_interpretation'",
      "evidence": "string, how the action meets or fails the requirement"
    }
  ],
  "approval_history": [
    {
      "approval_id": "string",
      "approver": "string",
      "decision": "string, 'approved', 'denied', 'conditional'",
      "timestamp": "string",
      "conditions": "string or null"
    }
  ],
  "completeness_check": {
    "all_required_fields_present": "boolean",
    "missing_evidence": ["list of strings, any gaps in the audit trail"],
    "data_freshness_warnings": ["list of strings, any stale or potentially outdated information"]
  },
  "reviewer_notes": "string, any additional context or caveats for the human reviewer"
}

## Constraints
- Do not fabricate information. If a field cannot be populated from the provided inputs, mark it explicitly as 'NOT_AVAILABLE' and list it in `completeness_check.missing_evidence`.
- For any policy status marked 'requires_interpretation', explain the ambiguity in `reviewer_notes`.
- If the risk score is above [HIGH_RISK_THRESHOLD], add a bold warning to `reviewer_notes`.
- Cite specific policy clauses by their reference ID whenever possible.
- If previous approvals exist for the same target resource, highlight any conflicting decisions.

To adapt this template, replace each square-bracket placeholder with data from your application context. The [PENDING_ACTION_DETAILS] should be a structured object, not free text, to ensure consistent parsing. Set [HIGH_RISK_THRESHOLD] to a value appropriate for your organization's risk tolerance, typically 70 or 80. Before deploying, run this prompt against a golden dataset of known actions and verify that the completeness_check correctly identifies intentionally omitted evidence. For regulated environments, always route the final package through a human review step before the approval decision is made.

This prompt is designed to be called immediately before a human reviewer opens an approval ticket. The application should gather all raw context—the pending action, requester details, change description, risk assessment output, relevant policy clauses, and prior approval logs—and inject them into the prompt's placeholders. The model's job is not to approve or deny; it is to assemble a complete, structured evidence package that reduces the reviewer's cognitive load and ensures no audit trail element is missing.

Wire the prompt into a pre-review hook within your approval orchestration service. When an action enters a pending_review state, call the model with the assembled context. Parse the output against a strict JSON schema that includes required fields: package_id, action_summary, requester, risk_assessment, policy_references, approval_history, missing_evidence_flags, and completeness_score. If the output fails schema validation, retry once with the validation error injected into the [CONSTRAINTS] block. If it fails again, flag the package for manual assembly and log the failure for prompt debugging. For high-risk domains, always route the final package to a human reviewer; never auto-approve based solely on a high completeness_score.

Implement a completeness gate before the package reaches the reviewer. If missing_evidence_flags is non-empty, the application should attempt to fetch the missing data from the system of record (e.g., audit logs, policy engine, change management database) and re-run the assembly prompt. If the data cannot be found, the package is still delivered to the reviewer but with a prominent warning banner. Log every assembly run, including the prompt version, model used, input context hashes, and the final completeness score, to create an audit trail of the evidence assembly process itself. Avoid using this prompt for real-time, low-latency approval flows where the assembly step would block critical operations; instead, pre-assemble packages asynchronously.