Intelligence Briefing Fact-Interpretation Extraction Prompt

This prompt is designed for intelligence analysts and verification pipeline engineers who need to process threat reports, situational briefings, and strategic assessments. The core job-to-be-done is separating verifiable factual observations with explicit source provenance from analyst judgments, confidence assessments, inferred implications, and rhetorical framing. This is not a general-purpose text classifier; it is a precision extraction tool for high-stakes content where downstream decisions depend on knowing exactly what is known versus what is assessed. Use this prompt when you must produce a structured, auditable decomposition of an intelligence product before it enters a verification pipeline, a knowledge base, or a decision support system.

The ideal user is operating inside a structured intelligence workflow. They have access to the original source material and can provide it as the [SOURCE_TEXT] input. They need the output to distinguish between direct reporting (e.g., 'The convoy was observed at grid coordinates X at 1400Z') and analytical synthesis (e.g., 'The convoy's movement pattern suggests a resupply operation'). The prompt requires a pre-defined [CLASSIFICATION_TAXONOMY] to map each extracted statement to a specific type, such as 'Direct Observation,' 'Analyst Assessment,' 'Confidence Judgment,' or 'Inferred Implication.' It also requires an [OUTPUT_SCHEMA] to enforce a strict JSON structure with fields for the original text span, the extracted statement, its classification, and a source citation. Do not use this prompt on raw, unprocessed intercepts or social media feeds without first scoping the content to a specific report or briefing document. It is not designed for real-time streaming data or for making the final verification judgment itself—it only performs the separation step.

Avoid using this prompt when the source material is purely factual with no interpretive content, such as a raw sensor log or a simple list of events. In those cases, a simpler extraction prompt will be more cost-effective and faster. Conversely, do not use it when the content is almost entirely speculative or rhetorical, as the model will struggle to find factual anchors and may hallucinate distinctions. The prompt is also not a substitute for human analytic tradecraft; it is a force-multiplier that requires a human reviewer to validate boundary decisions in ambiguous cases. Before deploying, ensure you have a validation harness that checks the output against the [OUTPUT_SCHEMA] and an evaluation rubric that measures boundary precision against human-labeled examples. The next step is to review the prompt template and implementation harness to understand how to wire this into a production verification pipeline.

This prompt template is designed for intelligence analysts and verification pipeline builders who need to decompose threat reports, situational briefings, and assessments into two distinct streams: verifiable factual observations with source provenance, and analytical judgments with confidence assessments. The template uses square-bracket placeholders that you must replace with your specific content, classification taxonomy, and output schema before use. The core instruction forces the model to treat every sentence as either a reportable fact or an interpretation, never blending the two without explicit labeling.

textCopy
You are an intelligence briefing analyst. Your task is to process the provided [BRIEFING_CONTENT] and separate every statement into one of two categories: FACTUAL OBSERVATION or ANALYTICAL JUDGMENT.

### CLASSIFICATION RULES
- FACTUAL OBSERVATION: A statement that reports what was seen, heard, measured, or directly observed. It must be verifiable against source data, sensor logs, human reporting, or documentary evidence. Include the specific source, date, and reporting chain if available. Do not include inferences, assessments, or predictions.
- ANALYTICAL JUDGMENT: A statement that interprets, assesses, predicts, or draws conclusions from observations. This includes confidence assessments, threat evaluations, implications, forecasts, and statements about what a fact "means." Always include the analyst's stated confidence level if present in the source.

### BOUNDARY RULES
- If a sentence contains both a fact and an interpretation, split it. Extract the factual core into FACTUAL OBSERVATION and the interpretive layer into ANALYTICAL JUDGMENT. Link them with a shared `source_span` reference.
- If a statement appears factual but lacks any source attribution, flag it as ANALYTICAL JUDGMENT with a note: "Unattributed assertion; cannot verify provenance."
- Direct quotes from named sources are FACTUAL OBSERVATION (the fact that someone said something). The content of the quote may be ANALYTICAL JUDGMENT if the speaker is interpreting events.
- Numerical data, timestamps, locations, and named entities are FACTUAL OBSERVATION when directly reported. Trends, percentages derived from analysis, and comparative assessments are ANALYTICAL JUDGMENT.

### INPUT
[BRIEFING_CONTENT]

### OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "briefing_id": "[BRIEFING_ID]",
  "processed_at": "[TIMESTAMP]",
  "factual_observations": [
    {
      "id": "fact-001",
      "statement": "The exact factual claim",
      "source_span": "Paragraph 3, sentences 1-2",
      "source_attribution": "SIGINT intercept dated 2024-03-15 / Field report from Station Alpha",
      "verifiability": "directly_verifiable | partially_verifiable | requires_corroboration",
      "linked_judgment_ids": ["judgment-003"]
    }
  ],
  "analytical_judgments": [
    {
      "id": "judgment-001",
      "statement": "The interpretive or predictive claim",
      "source_span": "Paragraph 5, sentence 3",
      "judgment_type": "threat_assessment | prediction | implication | confidence_statement | inference | unattributed_assertion",
      "stated_confidence": "high | medium | low | not_specified",
      "basis_fact_ids": ["fact-004", "fact-007"],
      "analyst_note": "Preserve any caveat or uncertainty language from the original"
    }
  ],
  "processing_notes": ["Any boundary cases or splitting decisions that require explanation"]
}

### CONSTRAINTS
- Do not omit any sentence from the source. Every sentence must appear in either factual_observations or analytical_judgments.
- Preserve original wording in the `statement` field. Do not paraphrase.
- If source attribution is missing, do not invent it. Mark as "unattributed" and flag in processing_notes.
- For [RISK_LEVEL] briefings at HIGH or CRITICAL, add a `human_review_required` boolean to any judgment where stated_confidence is "low" or "not_specified."

To adapt this template, replace the bracketed placeholders with your operational values. [BRIEFING_CONTENT] accepts the full text of the briefing document. [BRIEFING_ID] should be your internal document identifier for traceability. [TIMESTAMP] can be generated at runtime. [RISK_LEVEL] controls whether low-confidence judgments are automatically flagged for human review—set this based on your organization's escalation policy. The output schema is designed for direct ingestion into a verification pipeline where factual observations proceed to evidence matching and analytical judgments are routed for analyst review or confidence calibration. Before deploying, test against your organization's classification guide to ensure the judgment_type enum aligns with your analytical tradecraft standards.

This prompt is designed as a pre-processing step in a larger verification pipeline, not a standalone chat interaction. The primary integration point is immediately after document ingestion and before evidence matching. Raw intelligence briefings arrive via API, file upload, or streaming ingest. The application layer should extract the full text, preserve source metadata (document ID, classification, origin, timestamp), and pass both into the prompt's [INPUT_TEXT] and [SOURCE_METADATA] placeholders. The output is a structured JSON payload containing two parallel arrays: factual_observations (verifiable statements with source provenance) and analyst_interpretations (judgments, assessments, inferences, and confidence qualifiers). Downstream, the factual_observations array routes to evidence matching and claim verification subsystems, while analyst_interpretations routes to a separate review queue or synthesis module. This separation prevents the verification engine from treating analytical judgments as checkable facts, which is the primary failure mode this prompt prevents.

Validation and Schema Enforcement: The application harness must validate the model's output against a strict JSON schema before allowing downstream consumption. Required fields per factual observation include claim_text, source_span_reference (exact quote or paragraph pointer), source_document_id, and observation_type (enum: direct_reporting, sensor_data, witness_account, documentary_evidence). Required fields per interpretation include interpretation_text, basis_facts (array of IDs linking to factual observations), confidence_level (enum: high, moderate, low, unknown), and interpretation_type (enum: analyst_judgment, inferred_implication, forecast, alternative_hypothesis, uncertainty_caveat). If validation fails, the harness should retry with the same input and an appended repair instruction, not silently drop malformed records. After two failed retries, route the entire document to human review with the raw model output and validation errors attached. Model choice: Use a model with strong structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) and enable strict JSON mode or tool-calling with a defined schema. Avoid models under 70B parameters for this task; boundary precision degrades significantly on smaller models, especially on embedded factual assertions within analytical sentences.

Logging, Audit Trail, and Human Review Routing: Every extraction run must produce an audit record containing the input document hash, prompt version, model identifier, output schema version, validation status, and any retry attempts. This is critical for intelligence workflows where downstream decisions depend on traceable evidence handling. Store the full prompt request and response in an append-only log for at least the retention period required by the organization's compliance policy. When the model assigns low or unknown confidence to an interpretation, or when a factual observation lacks a source_span_reference, flag those records for human review automatically. The review interface should display the original passage, the model's classification, and a simple accept/reject/edit control. Track reviewer corrections as labeled data for future fine-tuning or few-shot example refinement. What to avoid: Do not use this prompt in streaming or real-time chat contexts where partial outputs might be consumed before validation completes. Do not skip the schema validation step; even minor format drift in observation_type enums will break downstream routing logic. Do not treat the model's confidence levels as calibrated without running your own eval against domain experts on a representative sample of your actual intelligence briefings.