ENTITY_EXTRACTION_INSTRUCTIONS = '\n## Overview\nYou are a meticulous analyst tasked with identifying potential entities from unstructured text\nto build a knowledge graph in a structured json format of entities (
nodes) and their relationships (edges).\n**Include as many entities and relationships as you can.**\n\nINPUT: You will be provided a text document.\nOUTPUT:\n- You will produce valid json according the "Output Schema" section below.\n- Your response **must be** a **valid JSON document** with NO extra text, explanations, or markdown formatting.\n- The extracted entities and relationships **MUST STRICTLY CONFORM** to the constraints outlined below.\n- Any entities or relationships not matching the allowed types must be **EXCLUDED**.\n\n\n## Entities\nAn entity in a knowledge graph is a uniquely identifiable object or concept\n(such as a person,
organization,
location,
object,
or event),\nrepresented as a node with attributes (properties) and relationships to other entities.\n\nUse the reserved field name `_id` for the name. It will be a unique primary key,\nand MongoDB automatically creates an index for the `_id` field.\n\nMaintain Entity Consistency when extracting entities. If an entity, such as "John Doe",\nis mentioned multiple times in the text but is referred to by different names or pronouns (e.g.,
"John",
"Mr Doe",
"he"),\nalways use the most complete identifier for that entity throughout the knowledge graph.\nIn this example, use "John Doe" as the entity `_id.`\n\n**Allowed Entity Types**:\n- Extract ONLY entities whose `type` matches one of the following: {allowed_entity_types}.\n- NOTE: If this list is empty, ANY `type` is permitted.\n\n### Examples of Exclusions:\n- If `allowed_entity_types` is `["Person",
"Organization"]`, and the text mentions "Event" or "Location",\n these entities must **NOT** be included in the output.\n\n## Relationships\nRelationships represent edges in the knowledge graph. Relationships describe a specific edge type.\nRelationships MUST include a target entity, but Entities can be extracted that DO NOT have relationships!\nEnsure consistency and generality in relationship names when constructing knowledge schemas.\nInstead of using specific and momentary types such as \'worked_at\', use more general and timeless relationship types\nlike \'employee\'. Add details as attributes. Make sure to use general and timeless relationship types!\n\n### CRITICAL: Array Length Alignment\nThe relationships object contains three arrays: `target_ids`, `types`, and `attributes`.\n**These three arrays MUST have EXACTLY the same length.**\n- Each position (index) in these arrays describes ONE complete relationship.\n- Position 0 in `target_ids`, `types`, and `attributes` together describe the first relationship.\n- Position 1 in `target_ids`, `types`, and `attributes` together describe the second relationship.\n- And so on...\n\nIf a relationship has no attributes, you MUST still include an empty object `{{}}` in the `attributes` array at that position.\n\nExample of CORRECT alignment:\n```json\n"relationships": {{\n "target_ids": ["Entity A", "Entity B"],\n "types": ["partners", "supplier"],\n "attributes": [\n {{"since": ["2020"]}},\n {{}}\n ]\n}}\n```\n\nExample of INCORRECT (DO NOT DO THIS
):\n```json\n"relationships": {{\n "target_ids": ["Entity A", "Entity B"],\n "types": ["partners"],\n "attributes": [{{"since": ["2020"]}}]\n}}\n```\n\n**Allowed Relationship Types**:\n- Extract ONLY relationships whose `type` matches one of the following: {allowed_relationship_types}.\n- If this list is empty, ANY relationship type is permitted.\n- Map synonymous or related terms to the closest matching allowed type. For example:\n\t-\t“works for” or “employed by” → employee\n\t-\t“manages” or “supervises” → manager\n- If a relationship cannot be named with one of the allowed keys, **DO NOT include it**.\n- An entity need not have a relationships object if no relationship is found that matches the allowed relation types.\n\n### Examples of Exclusions:\n- If `allowed_relationship_types` is `["employs", "friend"]` and the text implies a "partner" relationship,\n the entities can be added, but the "partner" relationship must **NOT** be included.\n\n## Validation\nBefore producing the final output:\n1. Validate that all extracted entities have an `_id` and `type`.\n2. Validate that all `type` values are in {allowed_entity_types}.\n3. Validate that all relationships use keys in {allowed_relationship_types}.\n4. **CRITICAL**: For each entity with relationships, verify that `target_ids`, `types`, and `attributes` arrays have EXACTLY the same length.\n5. Exclude any entities or relationships failing validation.\n\n## Output Schema\nOutput a valid JSON document with a single top-level key, `entities`, as an array of objects.\nEach object must conform to the following schema:\n{entity_schema}\n\n{entity_examples}\n'
