Cross-Lingual Event Extraction Prompt Template

This prompt is built for a specific job: extracting structured, language-agnostic event records from non-English source text while preserving the original language evidence, a literal translation, and explicit translator's notes. The ideal user is an engineer or analyst building a downstream system—a graph database, an alerting pipeline, or a cross-lingual search index—that cannot tolerate silent translation distortion. You should use this prompt when your source material is primarily in Arabic, Mandarin, Russian, Farsi, or another non-English language, and when the event schema must be consistent regardless of the source language, enabling queries like 'show me all protests involving state security forces in the last 30 days' to return results from every monitored language feed.

Do not use this prompt when your source text is already in English, when you only need a fluent summary instead of a structured event record, or when you are performing monolingual extraction with a fixed schema that has no cross-lingual alignment requirement. In those cases, a simpler event extraction prompt without the translation layer will be faster, cheaper, and less prone to over-annotation. Also avoid this prompt for real-time streaming applications with sub-second latency budgets unless you have a model that can handle the combined extraction and translation instructions within your latency window; the translation and annotation steps add token overhead that may require an asynchronous pipeline architecture.

The prompt explicitly instructs the model to flag translation-induced event distortion—for example, when a passive construction in Arabic ('تم اعتقال المتظاهرين') becomes an active event in English ('Police arrested the protesters'), or when a culturally specific event type like a Russian 'субботник' (community cleanup day) lacks a direct English equivalent. If your downstream system cannot consume or act on these distortion flags, you may be adding complexity without value. Before adopting this prompt, confirm that your ingestion schema has fields for distortion_flags, translator_notes, and original_language_evidence, and that your evaluation framework includes checks for cross-lingual event fidelity, not just monolingual extraction accuracy.

This prompt template is designed for multilingual intelligence pipelines that must extract structured event data from source text in any language. It instructs the model to produce a normalized, language-agnostic event schema while preserving the original language evidence and flagging any translation-induced distortions. Replace the square-bracket placeholders with your specific event ontology, output schema, and operational constraints before pasting this into your system instructions.

textCopy
You are a cross-lingual event extraction system. Your task is to read source text in any language and extract structured event records into a language-agnostic schema.

## INPUT
Source Text: [SOURCE_TEXT]
Source Language: [SOURCE_LANGUAGE]
Target Event Schema: [EVENT_SCHEMA]

## OUTPUT REQUIREMENTS
Produce a valid JSON object conforming to the following structure:
{
  "events": [
    {
      "event_id": "string",
      "event_type": "[EVENT_TYPE_ENUM]",
      "trigger_span": {
        "text": "original language trigger text",
        "start_char": integer,
        "end_char": integer
      },
      "arguments": [
        {
          "role": "[ARGUMENT_ROLE]",
          "value": "normalized value",
          "original_text": "original language argument text",
          "start_char": integer,
          "end_char": integer
        }
      ],
      "temporal_expression": {
        "original_text": "original language time expression",
        "normalized_iso": "ISO 8601 or null",
        "relative_marker": "before|after|during|null"
      },
      "location": {
        "original_text": "original language location expression",
        "normalized_name": "canonical location name or null",
        "geopolitical_entity": "country or region code or null"
      },
      "participants": [
        {
          "role": "agent|patient|beneficiary|instrument|other",
          "entity_type": "person|organization|gpe|other",
          "original_text": "original language participant mention",
          "canonical_name": "resolved canonical name or null"
        }
      ],
      "factuality": "factual|planned|hypothetical|negated|uncertain",
      "confidence": 0.0-1.0,
      "translation_notes": {
        "trigger_translation": "English translation of trigger",
        "key_argument_translations": ["English translation of key argument 1", "..."],
        "translation_confidence": 0.0-1.0,
        "distortion_risks": ["description of any meaning distortion risk from translation"]
      },
      "source_evidence": {
        "document_id": "[DOCUMENT_ID]",
        "sentence_index": integer,
        "extraction_timestamp": "ISO 8601"
      }
    }
  ],
  "extraction_metadata": {
    "source_language": "[SOURCE_LANGUAGE]",
    "total_events_found": integer,
    "low_confidence_events": integer,
    "translation_issues_flagged": integer
  }
}

## CONSTRAINTS
- Extract every event that matches the target schema, regardless of language.
- Preserve the original language text in all `original_text` fields. Do not translate these fields.
- Provide English translations only in the `translation_notes` section.
- Flag any translation-induced distortion risks explicitly in `distortion_risks`.
- If an event argument is missing, omit it rather than hallucinating a value.
- Set `confidence` based on extraction certainty, not translation certainty.
- Use `translation_confidence` to indicate how confident you are in the translation.
- For languages you are less proficient in, lower `translation_confidence` and increase `distortion_risks` detail.
- If the source language is ambiguous, note it in `extraction_metadata`.
- Do not extract events from [EXCLUDED_EVENT_TYPES] even if they appear in the text.
- If the text contains no extractable events, return an empty `events` array with appropriate metadata.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

After pasting this template, adapt it by populating [EVENT_SCHEMA] with your target event types and argument roles, [EXCLUDED_EVENT_TYPES] with any event categories you want the model to ignore, and [FEW_SHOT_EXAMPLES] with 2-3 examples in your most common source languages. For high-risk intelligence workflows, set [RISK_LEVEL] to high and ensure a human reviewer validates all events where confidence is below 0.7 or translation_confidence is below 0.6. The distortion_risks field is your primary defense against translation-induced event errors—monitor it in production logs to identify language pairs that need better translation support or human review.

Before deploying, test this prompt against a golden dataset of 20-30 documents in at least three languages, including one low-resource language your pipeline will encounter. Measure precision and recall per language, and pay special attention to false negatives in languages where the model's translation confidence is low. If you observe event type confusion or argument role swapping in specific language pairs, add those as counterexamples in [FEW_SHOT_EXAMPLES]. For production, wire the output through a JSON schema validator that rejects any event record missing required fields or containing out-of-enum values for event_type, factuality, or role.

The cross-lingual event extraction prompt is designed to be called from an application layer that manages language detection, model routing, and output validation before the extracted events reach a downstream intelligence pipeline or graph database. The application should first detect the source language using a fast classifier or the [SOURCE_LANGUAGE] field if already known, then select a model with strong multilingual performance for that language family. For high-risk intelligence workflows, prefer a model that supports structured output or function calling so the event schema is enforced at the API level rather than relying solely on prompt instructions. The application should send the prompt with the source text, target event ontology, and output schema, then validate the response before ingestion.

After receiving the model response, run a multi-stage validation pipeline. First, check that every extracted event has all required fields: event_type, participants, location, timestamp, and modality. Second, verify that each event includes an original_language_evidence snippet quoting the source text—this is critical for auditability and for detecting translation-induced distortion. Third, confirm that translation_notes are present for any event where the model translated participant names, locations, or event descriptions. If validation fails, implement a retry loop with a maximum of two additional attempts, each time appending the specific validation errors to the prompt as [PREVIOUS_ERRORS]. If the third attempt still fails, route the document to a human review queue with the partial extraction and error log attached. Log every extraction attempt—including source language, model version, validation pass/fail status, and retry count—so the team can monitor language-specific failure patterns and model drift over time.

For production deployment, consider batching documents by language to reduce model-switching overhead and to apply language-specific post-processing rules, such as date format normalization or name transliteration consistency checks. If the extracted events will be ingested into a graph database, add a final transformation step that maps the validated event JSON to your target ontology and generates idempotent insert statements. Avoid sending raw model output directly to downstream systems. The translation_notes field should be preserved in the event record as metadata, not discarded, so that analysts can audit translation decisions later. When the source text contains multiple languages or code-switching, flag the document for human review regardless of validation status, as current models frequently mishandle event boundaries in mixed-language passages.