Event Structure Extraction Prompt Template

This prompt is designed for intelligence analysts, knowledge graph engineers, and data pipeline builders who need to convert narrative reports into structured event frames. It extracts typed events with required arguments such as participants, locations, timestamps, and modalities. Use this prompt when you need machine-readable event records that can be ingested into a graph database, event store, or analytical pipeline. The prompt enforces strict argument validation, flags missing required fields, and detects temporal ordering conflicts. It is not a general summarization tool or a simple entity extractor. It assumes the input text contains at least one describable event and that the target schema is defined before extraction begins.

This prompt is the right choice when your primary goal is to populate a structured event schema—such as CAMEO, ACE, or a custom ontology—from free-text reports. It is ideal for workflows where downstream systems require a predictable JSON contract with typed fields for event_type, participants, location, timestamp, and modality. The prompt is designed to fail loudly when critical information is missing, rather than hallucinating plausible values. This makes it suitable for high-stakes intelligence pipelines where a missing field is preferable to a fabricated one. However, it is not a replacement for a full natural language understanding pipeline; it works best on text that has already been pre-segmented into event-containing passages.

Do not use this prompt for general document summarization, simple named entity recognition, or sentiment analysis. It is also a poor fit for highly abstract or speculative text where concrete events are not described. If your input contains hypotheticals, plans, or negated events, pair this prompt with the Event Factuality Assessment Prompt Template to avoid extracting non-events as facts. For cross-document event linking, combine this prompt with the Multi-Document Event Coreference Prompt Template. Before integrating this prompt into a production pipeline, define your target event schema, prepare a golden evaluation set with known event arguments, and establish a human review queue for records that fall below your confidence threshold.

This prompt template is designed for intelligence analysts and data engineers who need to convert narrative reports into structured event records suitable for graph databases, timeline tools, or downstream ingestion pipelines. The template enforces strict JSON output, requires explicit handling of missing information, and includes a validation_warnings field to surface temporal conflicts or incomplete arguments. Copy the template below, replace the square-bracket placeholders with your specific input and constraints, and integrate it into your extraction harness.

textCopy
You are an event extraction system. Your task is to read the provided text and extract all described events into a structured JSON format. Follow these rules exactly:

1. Extract only events explicitly described in the source text. Do not invent, infer, or assume events not directly stated.
2. For each event, populate the following fields:
   - event_type: A short label describing the event category (e.g., "meeting", "attack", "transaction", "arrest").
   - participants: An array of entities involved, each with a "name" and "role" (e.g., "agent", "patient", "witness").
   - location: The place where the event occurred, or null if not specified.
   - timestamp: An ISO 8601 datetime string if a specific time is given, or a relative description if only relative timing is available. Use null if no temporal information exists.
   - modality: One of "factual", "planned", "hypothetical", "negated", or "unknown" based on the language used.
   - description: A one-sentence summary of the event using only information from the source.
   - confidence: A float between 0.0 and 1.0 indicating how clearly the event is stated.
3. If any required argument for an event is missing (e.g., no location mentioned), set the field to null and add a flag to the validation_warnings array.
4. If temporal ordering between events is ambiguous or contradictory, note the conflict in validation_warnings with specific event indices.
5. Return ONLY valid JSON. Do not include any text outside the JSON object.

[INPUT]
[CONSTRAINTS]

Return JSON matching this schema:
{
  "events": [
    {
      "event_type": "string",
      "participants": [{"name": "string", "role": "string"}],
      "location": "string | null",
      "timestamp": "string | null",
      "modality": "factual | planned | hypothetical | negated | unknown",
      "description": "string",
      "confidence": "float"
    }
  ],
  "validation_warnings": ["string"]
}

To adapt this template for your own use, replace [INPUT] with the raw text you need to process. Use [CONSTRAINTS] to inject domain-specific rules, such as a controlled vocabulary for event_type values, required participant roles, or timezone normalization instructions. For high-stakes intelligence workflows, always pair this prompt with a validation step that checks for missing required arguments and flags low-confidence events for human review before ingestion into operational systems.

When deploying this prompt in production, wrap it in an application harness that validates the JSON structure, retries on parse failures, and logs every extraction with its source document identifier and model version. For regulated or investigative use cases, ensure a human analyst reviews events where confidence falls below a defined threshold or where validation_warnings indicate temporal conflicts. Never treat the model's output as ground truth without verification against the original source text.

The Event Structure Extraction prompt is designed to be called from an application layer, not used as a one-off chat interaction. In production, you will send raw narrative text as [INPUT], optionally provide a target [OUTPUT_SCHEMA] (such as a JSON Schema for typed events), and receive structured event objects. The application is responsible for pre-processing the input (e.g., stripping markup, chunking long documents), calling the model, validating the output, and deciding whether to retry, repair, or escalate to a human reviewer. This harness is critical because raw model output will occasionally contain missing required fields, temporal contradictions, or hallucinated participants that downstream systems cannot tolerate.

A typical implementation wraps the prompt in a service with the following stages: (1) Input preparation — split documents longer than the model's context window into overlapping chunks, preserving sentence boundaries to avoid cutting events in half. (2) Model invocation — send the prompt with the chunked text, the desired output schema, and any domain-specific constraints. Use a low temperature (0.0–0.2) for deterministic extraction. (3) Output validation — parse the JSON response and validate it against your event schema. Check that every event has a non-null type, at least one participant, and a timestamp or temporal_expression. Reject events where the location contradicts the document's stated geography. (4) Repair loop — if validation fails, construct a repair prompt that includes the original input, the invalid output, and the specific validation errors. Retry up to two times before escalating. (5) Deduplication and merge — when processing multiple chunks, merge events that refer to the same real-world occurrence using coreference heuristics (e.g., matching on normalized time, location, and key participants). (6) Human review gate — route events with confidence scores below a configurable threshold, or events flagged with factuality: "uncertain", to a review queue. Log every extraction with the model version, prompt hash, input hash, and validation result for auditability.

When wiring this into a data pipeline, treat the prompt as a versioned artifact stored alongside your application code. Use a prompt registry or configuration store so you can update the prompt without redeploying the entire service. Instrument the pipeline with metrics: extraction latency, validation pass rate, repair loop frequency, and human escalation rate. Set alerts if the validation failure rate spikes after a prompt or model change. For high-stakes intelligence workflows, consider running the same input through two different models (or two prompt variants) and flagging outputs where the extracted event structures diverge significantly. This cross-validation pattern catches subtle hallucinations that schema validation alone would miss. Finally, ensure your logging preserves the full chain of evidence — from source document to extracted event to any human corrections — so that downstream analysts can trace every structured record back to its origin.