Event Factuality Assessment Prompt Template

This prompt is designed for intelligence analysts, knowledge graph engineers, and data pipeline operators who need to distinguish factual events from hypothetical, planned, negated, or uncertain ones in unstructured text. The core job is to assign a factuality label, a modality marker, and a polarity flag to every extracted event, ensuring that downstream systems do not treat a canceled meeting or a speculative forecast as an established fact. Use this when your ingestion pipeline feeds a timeline, a graph database, or an alerting system where false positives from non-factual events carry high operational cost.

The prompt requires a pre-extracted event structure as input—typically the output of an event extraction step that already identifies the event trigger, arguments, and source span. You must supply the event text, its surrounding context, and any known document metadata. The template is not a general-purpose fact-checker for arbitrary claims; it assumes you have already isolated candidate events and now need to assess their factuality status. Do not use this prompt on raw, unprocessed documents or as a standalone veracity classifier without event extraction upstream.

Before wiring this into production, define your factuality taxonomy explicitly. The prompt uses labels such as FACTUAL, HYPOTHETICAL, PLANNED, NEGATED, and UNCERTAIN, but your downstream schema may require a different set. Adapt the [FACTUALITY_LABELS] placeholder to match your ontology. Also plan for human review on UNCERTAIN or conflicting signals—this workflow is high-risk when ingested events trigger automated actions. The next section provides the copy-ready template you can adapt and test against your own event corpus.

The following prompt template is designed to be copied directly into your AI harness. It takes an extracted event and its surrounding context as input and returns a structured factuality assessment. The template uses square-bracket placeholders for all dynamic inputs, making it easy to parameterize in code. Before using this prompt in production, you must define your [FACTUALITY_LABELS] taxonomy, prepare representative [FEW_SHOT_EXAMPLES], and decide on the [OUTPUT_SCHEMA] that your downstream ingestion pipeline expects.

textCopy
You are an expert linguistic analyst specializing in event factuality assessment. Your task is to analyze an event extracted from a source text and determine its factuality status.

## INPUT
**Source Text:**
[SOURCE_TEXT]

**Extracted Event:**
[EXTRACTED_EVENT]

**Surrounding Context (3 sentences before and after):**
[SURROUNDING_CONTEXT]

## TASK
Analyze the extracted event and assign a factuality label from the taxonomy below. Consider hedging language, modal verbs, negation, conditional structures, future tense, and counterfactual markers.

## FACTUALITY TAXONOMY
[FACTUALITY_LABELS]

## OUTPUT SCHEMA
Return a single JSON object matching this schema:
[OUTPUT_SCHEMA]

## CONSTRAINTS
- Base your assessment ONLY on the provided source text and context. Do not use external knowledge.
- If the event's factuality is ambiguous, set the confidence score low and explain the ambiguity in the `evidence_rationale` field.
- Flag any hedging language, modal verbs, or negation cues in the `linguistic_markers` array.
- If the event is negated, set the `polarity` field to "negative" and explain what is being denied.
- If the event is hypothetical or conditional, identify the condition in the `modality_trigger` field.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template for your use case, start by defining your factuality taxonomy. A minimal taxonomy might include factual, probable, planned, hypothetical, negated, and counterfactual. For intelligence or legal workflows, you may need finer-grained distinctions such as reported_by_source versus directly_observed. The [FEW_SHOT_EXAMPLES] placeholder is critical for model performance—include at least one example per factuality label, with clear linguistic markers highlighted. If your risk level is high, add an instruction for the model to abstain and return "factuality": "uncertain" with a confidence score below a defined threshold, triggering human review in your harness.

After copying this template, wire it into your application with a validation layer that checks for schema compliance, missing required fields, and confidence scores below your operational threshold. For high-stakes domains like intelligence analysis or legal review, always route low-confidence assessments to a human review queue. Test the prompt against a golden dataset of 50–100 annotated examples covering all factuality labels, including edge cases with nested hedging, double negation, and mixed modality signals.

The Event Factuality Assessment prompt is designed to sit inside a document processing pipeline where raw text has already been segmented into candidate event spans. Before calling the prompt, your application should extract the sentence or paragraph containing the event claim, along with surrounding context (typically ±2 sentences). The prompt expects a structured [INPUT] containing the event text, a [CONTEXT] window, and an optional [OUTPUT_SCHEMA] defining the factuality labels your downstream system expects. Do not send entire documents; the model performs best when the event span is isolated with just enough context to resolve pronouns, temporal references, and discourse markers.

Wire the prompt into an application harness that enforces a strict JSON output contract. After receiving the model response, validate that every required field is present: factuality_label must be one of your defined enum values (e.g., factual, hypothetical, planned, negated, counterfactual), modality_markers must be a non-empty array of strings extracted from the source text, and polarity must be either positive or negative. If validation fails, implement a single retry with the validation error message appended to the prompt as a [CONSTRAINTS] amendment. After two failures, route the event to a human review queue rather than looping indefinitely. Log every assessment with the model version, prompt template hash, raw response, validation result, and reviewer decision for auditability.

For high-stakes domains—intelligence analysis, legal fact extraction, financial event processing—never treat the model's factuality label as ground truth without human confirmation. Implement a confidence threshold: if the model's response includes a confidence field below your defined cutoff (typically 0.85 for automated acceptance), or if the modality_markers contain hedging terms like 'allegedly,' 'reportedly,' or 'may have,' escalate to human review. Store the original source spans alongside the assessment so reviewers can quickly verify the model's judgment against the raw text. Avoid using this prompt for real-time decision systems where a misclassified counterfactual could trigger an automated action; the modality detection is strong but not infallible on edge cases involving sarcasm, implicit negation, or culturally specific hedging patterns.