Risk-Based Context Retention Prompt for Compliance

This prompt is a compliance-aware gating mechanism that sits between retrieval and final prompt assembly. It is designed for regulated domains—financial services, healthcare, legal, insurance, and audit-heavy enterprise workflows—where the decision to exclude a retrieved document, passage, or data item from downstream processing must be justified, traceable, and reversible. The job-to-be-done is not summarization or ranking. It is producing a defensible retention decision for each context item based on regulatory relevance, audit requirements, and task necessity. The ideal user is an AI engineer or compliance architect who already has a set of candidate context items from a retrieval system and a defined regulatory framework or internal policy. They need the AI to gate what enters the final prompt while leaving an audit trail that a compliance officer can inspect.

Use this prompt when you can articulate the regulatory or policy framework that governs retention. For example, in financial services, you might require that any document referencing a client's transaction history, KYC status, or flagged risk indicator must be retained. In healthcare, any context item containing a patient identifier, diagnosis code, or treatment plan may require retention. The prompt expects you to supply this framework as part of [REGULATORY_FRAMEWORK] or [RETENTION_POLICY]. It also expects a defined [TASK_DESCRIPTION] so the model can assess whether a context item is necessary for the downstream task—such as generating a compliance report, answering an auditor's question, or drafting a regulatory filing. Without these inputs, the model cannot make defensible retention decisions, and the output will be unreliable.

Do not use this prompt when the domain is unregulated, when context items are low-stakes, or when you can safely drop evidence without audit consequences. It is not a general-purpose context pruner, a summarizer, or a relevance ranker. If you need to reduce token costs for a customer support chatbot or trim search results for a product FAQ, use a lighter-weight context pruning or redundancy detection prompt instead. This prompt adds latency, token overhead, and a human review step by design. It is appropriate only when the cost of dropping evidence incorrectly—regulatory fines, audit failures, legal exposure—exceeds the cost of running the gating step. If you cannot define what makes a context item retention-worthy in regulatory terms, you are not ready to use this prompt. Start by documenting your retention policy with your compliance team before wiring this into a production pipeline.

This template is designed to be copied directly into your prompt management system, orchestration code, or evaluation harness. It accepts a list of context items—retrieved passages, document sections, or evidence snippets—and produces a retention decision for each item based on regulatory relevance, audit requirements, and task necessity. Every placeholder is enclosed in square brackets and must be replaced with concrete values before inference. The prompt is structured to force explicit risk justifications for any item marked for removal, and it gates high-risk drops behind a human approval flag rather than allowing the model to silently discard regulated evidence.

textCopy
You are a compliance-aware context retention assistant operating in a regulated domain. Your task is to review a set of context items and decide which must be retained, which can be safely dropped, and which require human review before removal.

## INPUT
Context items to evaluate:
[CONTEXT_ITEMS]

Each item includes a unique ID, source provenance, content, and any available metadata such as document type, date, or classification level.

## TASK REQUIREMENTS
[REQUIREMENTS]

## REGULATORY FRAMEWORK
[REGULATORY_FRAMEWORK]

## AUDIT AND RETENTION POLICY
[AUDIT_POLICY]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "retention_decisions": [
    {
      "item_id": "string",
      "decision": "retain" | "drop" | "human_review",
      "risk_level": "low" | "medium" | "high" | "critical",
      "justification": "string explaining the regulatory, audit, or task-based reason for the decision",
      "retained_content": "string (only if decision is retain or human_review, otherwise null)",
      "regulatory_citations": ["string references to applicable regulations or policy sections"],
      "human_approval_required": true | false
    }
  ],
  "summary": {
    "total_items": number,
    "retained_count": number,
    "dropped_count": number,
    "human_review_count": number,
    "high_risk_drops": ["item_ids that were dropped despite high or critical risk"],
    "overall_compliance_notes": "string"
  }
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Evaluate each context item independently against the regulatory framework, audit policy, and task requirements.
2. If an item is marked for removal and carries medium risk or higher, flag it for human review rather than dropping it automatically.
3. For every drop decision, provide a specific justification that references the regulatory or policy basis for removal.
4. If any item contains information that could be material to an audit, investigation, or regulatory filing, default to retain.
5. Do not drop items solely because they are long, redundant, or low-confidence unless the audit policy explicitly permits it.
6. If the regulatory framework or audit policy is ambiguous for a given item, escalate to human_review.
7. Preserve the original content of retained and review-flagged items exactly as provided.

To adapt this template, replace each placeholder with concrete values specific to your domain and use case. [CONTEXT_ITEMS] should be a structured list of items with IDs, content, and metadata. [REQUIREMENTS] should describe the downstream task the retained context will support—this helps the model distinguish essential evidence from noise. [REGULATORY_FRAMEWORK] must name the specific regulations, standards, or obligations that govern retention (e.g., GDPR Article 30, SEC Rule 17a-4, HIPAA retention requirements). [AUDIT_POLICY] should capture your organization's internal retention rules, including any data classification tiers, retention periods, and authorized deletion criteria. [CONSTRAINTS] can include token budgets, domain-specific terminology that must be preserved, or output format restrictions. [EXAMPLES] should provide at least two few-shot demonstrations: one showing a justified drop of low-risk, non-regulated content, and one showing a human-review escalation for ambiguous or high-risk material. Before deploying, validate that the output schema is enforced in your application layer—do not rely on the model alone to produce valid JSON. For high-risk domains, add a post-processing step that blocks any drop decision where human_approval_required is true but the decision is drop rather than human_review.

This prompt is not a standalone utility—it is a decision-making component inside a larger compliance workflow. The harness must treat each retention decision as a record that downstream systems and auditors can inspect. Wire the prompt into an application layer that first assembles the full context set from retrieval or document ingestion, then invokes the prompt once per batch of context items that exceed your token budget. The application should never silently drop evidence; every removal must be justified, logged, and, for high-risk items, approved by a human reviewer before the context is truncated.

Build the harness with three guard layers. Pre-inference validation: confirm that every context item has a stable identifier, source provenance, and a regulatory tag before the prompt runs. If any item is missing these fields, reject the batch and alert the operator—do not let the model guess. Post-inference validation: parse the model's JSON output and cross-check that every retained item ID exists in the input set, that every dropped item has a non-empty risk justification, and that no item appears in both lists. If the output fails structural validation, retry once with a stricter schema reminder in the error message. If it fails again, escalate the entire batch for human review rather than silently truncating. Human review gate: route any item flagged with a risk level of high or critical to a review queue. The reviewer must confirm or override the drop decision before the context is pruned. Log the reviewer's identity, timestamp, and decision for audit purposes.

Model choice matters here. Use a model with strong instruction-following and structured output reliability—GPT-4o, Claude 3.5 Sonnet, or equivalent. Avoid smaller or older models that may hallucinate justifications or mishandle the output schema. Set temperature to 0 or near-zero to maximize determinism. If your compliance domain requires data residency, deploy the model in-region or use a self-hosted option. For high-throughput pipelines, consider batching multiple context items into a single prompt call, but cap batch size at a level where the model can still produce reliable per-item justifications—start at 10–15 items per call and adjust based on eval results. Instrument every call with trace IDs, prompt version stamps, and latency metrics so you can reconstruct decisions during an audit or incident review.

The most common production failure mode is justification drift: the model produces plausible-sounding but factually weak justifications for dropping evidence that later turns out to be material. Mitigate this with a periodic audit sample where a human reviewer compares dropped items against the model's stated reason and flags any mismatch. Feed those flagged cases back into your eval set as regression tests. A second failure mode is schema non-compliance under load: when the context list is long or contains edge-case formatting, the model may emit malformed JSON or skip required fields. Your post-inference validator must catch this and trigger the retry-or-escalate path described above. Never assume the model's output is structurally correct on the first attempt.

Do not use this prompt as a substitute for proper retention policies or legal review. The prompt helps operationalize a risk-based filtering decision, but the risk taxonomy, regulatory tags, and escalation thresholds must be defined by your compliance team, not by the model. Store every retention decision—retain, drop, escalate—in an append-only audit log with the full prompt input, model output, validator results, and any human review actions. This log is your evidence if a regulator or auditor questions why a piece of evidence was excluded from a downstream decision. Wire the harness to fail closed: if the model, validator, or review queue is unavailable, retain all context rather than risk dropping evidence without a documented justification.