Structured Summary Prompt with Word Count Buckets

This prompt is for content operations teams, technical writers, and product builders who need to generate multiple summaries of the same source material at different compression levels. The core job-to-be-done is producing a set of summaries—for example, a 50-word headline summary, a 150-word executive brief, and a 500-word detailed overview—that each preserve the key points of the source while hitting a specific word-count target. The ideal user is someone integrating summarization into a content pipeline, a knowledge base, or a product surface where downstream consumers need different levels of detail from the same document.

Use this prompt when you have a single, self-contained source document and need multiple summaries with strict length constraints. It works best when the source is factual prose such as reports, articles, technical documentation, or meeting transcripts. The prompt is not suitable for multi-document synthesis, real-time conversation summarization, or scenarios where the summary must include external knowledge beyond the source. Avoid using it when the source contains highly ambiguous or contradictory information that requires resolution before summarization—this prompt compresses, it does not reconcile.

Before deploying this prompt, ensure you have a reliable way to count words in the output, a validation step that checks each summary against its target bucket, and a fact-consistency eval that compares claims in the summary to the source. If the summaries will be shown to end users without review, add a human-in-the-loop checkpoint for the first batch of outputs. Do not use this prompt for regulated content such as clinical summaries or legal briefs without mandatory human review and source-grounding verification.

This template is designed to be copied directly into your prompt management system, codebase, or AI orchestration tool. It uses square-bracket placeholders for all dynamic inputs, making it safe for string formatting and template engines. The prompt instructs the model to produce a structured summary object containing multiple compression levels, each with a target word count, a list of preserved key points, and a fidelity score. The output schema is embedded directly in the prompt so the model understands the expected shape before generation begins.

textCopy
You are a precise summarization engine. Your task is to read the provided [SOURCE_TEXT] and produce a structured summary object with multiple compression levels.

## Input
[SOURCE_TEXT]

## Output Schema
Return a single JSON object with the following structure:
{
  "summaries": [
    {
      "bucket_label": "string (e.g., 'micro', 'short', 'standard', 'detailed')",
      "target_word_count": integer,
      "actual_word_count": integer,
      "summary_text": "string",
      "key_points_preserved": ["string"],
      "fidelity_score": number (0.0 to 1.0)
    }
  ]
}

## Word Count Buckets
Generate one summary for each of the following target word counts: [WORD_COUNT_TARGETS]

## Constraints
- Each summary must be self-contained and readable without referring to other buckets.
- Key points must be extracted from [SOURCE_TEXT] only. Do not introduce external knowledge.
- The fidelity_score must reflect how much of the source's essential meaning is preserved at that compression level (1.0 = all key points preserved, 0.0 = none).
- actual_word_count must be the exact word count of summary_text, not an estimate.
- If [SOURCE_TEXT] is shorter than a target word count, set summary_text to the full source, actual_word_count to the source word count, and fidelity_score to 1.0.
- If [FOCUS_TOPICS] is provided, prioritize those topics in key point selection.

## Examples
[FEW_SHOT_EXAMPLES]

## Risk Level
[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with your runtime values. [SOURCE_TEXT] accepts the document or passage to summarize. [WORD_COUNT_TARGETS] should be a comma-separated list of integers like 50, 150, 300. [FOCUS_TOPICS] is optional; pass an empty string or a list of topic phrases to bias key-point selection. [FEW_SHOT_EXAMPLES] should contain one or two worked examples showing the expected output shape for a sample input. [RISK_LEVEL] accepts low, medium, or high and can be used downstream to decide whether human review is required. If your application uses a template engine like Jinja2 or Mustache, replace the square brackets with your engine's native syntax. Always validate that [SOURCE_TEXT] is non-empty and that [WORD_COUNT_TARGETS] contains at least one positive integer before sending the prompt to the model.

This prompt is designed to be called from an application layer that manages input assembly, output validation, and retry logic. The core workflow involves sending a source document and a set of target word-count buckets to the model, then receiving a structured JSON payload containing one summary per bucket. The application should treat the prompt as a stateless function: it receives [SOURCE_TEXT] and [WORD_COUNT_BUCKETS] as inputs and returns a [SUMMARIES] array. Do not rely on the model to enforce word-count limits perfectly; the application must validate compliance and handle failures programmatically.

Model Selection: Use a model with strong instruction-following and structured output capabilities, such as gpt-4o, claude-3-5-sonnet, or gemini-1.5-pro. Avoid smaller or older models that struggle with simultaneous constraints on length, structure, and factual consistency. If latency is critical, consider routing shorter source texts to a faster model while reserving the primary model for documents exceeding 2,000 tokens. Input Assembly: The application must pre-process [SOURCE_TEXT] to truncate it to a maximum token budget (e.g., 80% of the model's context window minus reserved output tokens). If the source exceeds this budget, chunk it and summarize each chunk independently before merging, or use a long-context model. Inject the word-count buckets as a JSON array of integers, e.g., [50, 150, 300]. Output Validation: Parse the model's response as JSON and validate the following before returning it to the user: (1) the response is valid JSON matching the expected schema; (2) the number of summaries equals the number of requested buckets; (3) each summary's word count falls within a tolerance band (e.g., ±15% of the target, or a stricter ±10% for buckets under 100 words); (4) each summary contains at least one key point from the source, verified by a lightweight entailment check or keyword overlap threshold. If validation fails, increment a retry counter and re-invoke the prompt with the same inputs and an added [VALIDATION_ERRORS] field describing what went wrong.

Retry and Fallback Strategy: Implement a maximum of 3 retries for validation failures. On the first retry, append the specific validation error (e.g., '50-word summary was 72 words; please shorten to within 10% of target') to the prompt. On the second retry, add a stronger constraint: 'You must output exactly the requested word counts. Do not exceed the target by more than 10%.' If the third attempt still fails, log the failure, return the best available output with a validation_warning flag, and route the task to a human review queue if the use case is high-stakes (e.g., executive briefings, legal summaries). For non-critical applications, accept the closest valid summary and surface a warning in the UI. Logging and Observability: Log every invocation with a unique trace_id, the model version, input token count, requested buckets, output word counts, validation pass/fail status, retry count, and latency. This data is essential for debugging drift when model behavior changes after an API update. Store the assembled prompt and raw response for at least 30 days to support failure analysis.

When to Add Product Code Instead of Prompt Tweaks: If word-count compliance remains inconsistent across retries, move enforcement out of the prompt and into post-processing. Use a separate, cheaper model call or a deterministic text-compression algorithm to trim or expand summaries to the exact target length after the primary model returns its output. If factual consistency is critical, integrate a retrieval step that grounds each summary claim against the source text using an NLI model before returning results to the user. Do not attempt to solve persistent reliability problems by endlessly refining the prompt; the application layer is the correct place for hard constraints. Human Review Triggers: Escalate to human review when validation fails after all retries, when the source text contains regulated content (e.g., financial disclosures, clinical notes), or when the output will be published without further editing. The review interface should display the source text, each summary with its target and actual word count, and a diff view highlighting claims that failed the entailment check.