Context Compression with Key Fact Preservation Prompt Template

This playbook is for RAG and document intelligence teams who hit context window limits and need a recovery strategy that compresses prior context without losing critical facts. Use this prompt when a model response fails due to token overflow, or when you need to preemptively reduce context size before a retry. It instructs the model to produce a dense, structured summary that explicitly preserves named entities, numbers, dates, and claim-evidence pairs. This is not a general summarization prompt. It is a lossless compression instruction designed for high-stakes workflows where dropping a single figure or entity breaks downstream tasks.

Do not use this prompt when you need a human-readable summary for display to end users, or when the downstream task tolerates approximate recall. This prompt is inappropriate for creative text shortening, conversational history pruning where emotional tone matters more than exact facts, or scenarios where the compression target is a general topic rather than a set of verifiable claims. It is also the wrong tool when the original context already fits comfortably within the model's context window—premature compression introduces unnecessary latency and potential information loss. Reserve this prompt for recovery paths triggered by explicit token limit errors or preflight token counting that predicts overflow.

Before invoking this prompt, ensure your application has detected a genuine context window failure or has calculated that the next request will exceed the model's limit. Wire this prompt into your retry logic as a recovery step that runs after a context_length_exceeded error, not as a default preprocessing step. After compression, validate the output by checking that all critical entity types (dates, amounts, named entities) from the original context appear in the compressed version. If the compression fails your fact-retention evaluation, escalate to a human reviewer or trigger a chunked processing fallback rather than silently proceeding with degraded context.

This template provides a direct instruction for the model to compress a given context down to a strict token budget. It is designed for RAG and document intelligence pipelines where lossless compression is required. The prompt forces the model to preserve named entities, numbers, dates, and claim-evidence pairs exactly as they appear, preventing hallucination or paraphrasing of critical details. Use this template when you need to reduce context size before a retry, fit more evidence into a limited window, or create a dense summary for a downstream task without losing factual integrity.

textCopy
Compress the following context to fit within a strict token budget of [MAX_TOKENS]. Preserve all named entities, numbers, dates, and claim-evidence pairs exactly as they appear. Do not paraphrase figures or infer relationships. Output the compressed result as a JSON object with a 'compressed_context' string field and a 'fact_index' array of preserved facts.

Context:
[INPUT_CONTEXT]

Constraints:
- Do not alter any numerical value, date, or proper noun.
- Maintain the original meaning of each claim-evidence pair.
- If the context cannot be compressed without losing required facts, flag the overflow in an 'overflow_flag' boolean field and list the omitted facts in an 'omitted_facts' array.

To adapt this prompt, replace [MAX_TOKENS] with the target token limit for your model and context window. The [INPUT_CONTEXT] placeholder should receive the raw text, retrieved passages, or conversation history you need to compress. In a production harness, you should validate the output JSON schema strictly: confirm compressed_context is a non-empty string, fact_index is an array of strings, and overflow_flag is a boolean. If the model returns invalid JSON, trigger a structured output repair retry. For high-stakes domains like healthcare or finance, route outputs with overflow_flag: true to human review before using the compressed context in downstream decisions. Always log the original context, compressed output, and fact index for auditability.

The context compression prompt is not a standalone utility—it is a recovery step inside a larger pipeline. Wire it as a pre-retry transformation that fires when the primary task prompt fails due to context length. The application layer should catch token-limit errors or truncated outputs, invoke the compression prompt on the original context, and then re-attempt the primary task with the compressed payload. This keeps compression logic separate from task logic and makes both easier to test independently.

Build the harness with these concrete components: (1) Trigger condition—detect context overflow via API error codes (e.g., context_length_exceeded), output truncation markers, or preflight token counting against the model's limit. (2) Compression call—send the original context plus the compression prompt template, requesting a structured output that preserves the required fact categories (entities, numbers, dates, claim-evidence pairs). (3) Validation gate—before passing compressed context to the retry, run a schema check that the compressed output contains all required fields and that preserved facts match the original source spans. A simple overlap check on named entities and numeric values catches most compression failures. (4) Retry with compressed context—substitute the compressed output into the original task prompt's [CONTEXT] placeholder and re-execute. (5) Escalation path—if compression itself fails validation or the retry still exceeds limits, escalate to a larger-context model, chunk the task, or route to human review.

For logging and observability, record the compression ratio (original tokens vs. compressed tokens), the fact-retention score from validation, and whether the retry succeeded. These metrics let you tune the compression prompt's aggressiveness over time. Avoid compressing context that is already within token limits—add a minimum threshold (e.g., only compress when context exceeds 80% of the model's limit) to prevent unnecessary latency. When using this in RAG pipelines, compress retrieved passages before they enter the prompt rather than compressing the assembled prompt, which preserves retrieval provenance and makes validation easier.