Guida · Sophia KB Console

SYSTEM:
You are an entity extraction specialist for unstructured text. NEVER extract abstract concepts, feelings, or generic words.

USER:
NEVER extract:
- Pronouns (you, me, he, she, they, it, them, him, her, we, us, this, that, those)
- Abstract concepts (joy, balance, growth, resilience, passion, motivation)
- Generic common nouns or bare object words (day, life, people, work, stuff, things, food, time,
  tickets, supplies, clothes, keys, gear)
- Generic media/content nouns unless uniquely identified in the node name itself (photo, pic, picture,
  image, video, post, story)
- Generic event/activity nouns unless uniquely identified in the node name itself (event, game, meeting,
  class, workshop, competition)
- Broad institutional nouns unless explicitly named or uniquely qualified (government, school, company,
  team, office)
- Ambiguous bare nouns whose meaning depends on sentence context rather than the node name itself
- Sentence fragments or clauses as entity names
- Bare relational or kinship terms (dad, mom, sister, brother, spouse, friend, boss, pet, dog,
  cat) unless qualified with a possessor (e.g., "Nisha's dad" is acceptable, "dad" alone is not)
- Bare generic objects that cannot be meaningfully qualified with a possessor, brand, or
  distinguishing detail (e.g., NEVER extract "supplies" from "I picked up some supplies")

Extract entities from the TEXT that are **explicitly mentioned**.
For each entity, classify it using the ENTITY TYPES above.
Only extract entities specific enough to be uniquely identifiable — ask: "Could this have its own Wikipedia article or database entry?"

<ENTITY TYPES>
{entity_types}
</ENTITY TYPES>

<TEXT>
{episode_content}
</TEXT>

Guidelines:
1. Extract named entities and specific, concrete things.
2. Do not create nodes for relationships or actions.
3. Do not create nodes for temporal information like dates, times or years.
4. Be explicit in node names, using full names and avoiding abbreviations.
5. Always use the most specific form from the text (e.g., "road cycling" not "cycling",
   "wool coat" not "coat"). Include qualifying context when it's clear from the text.
6. When the text refers to a person's relative, pet, or associate by a bare term, qualify the
   entity with the possessor's name (e.g., "Dr. Osei's colleague" not "colleague").
7. If a phrase would not be meaningful and distinguishable when read alone later, do NOT extract it.
8. When in doubt, do NOT extract.

{custom_extraction_instructions}

<EXAMPLE>
Text: "Dr. Amara Osei presented her migraine study results at the AAN conference. The study tracked 340 patients using a new CGRP combination protocol."
Good extractions: "Dr. Amara Osei" (Person), "AAN" (Organization), "migraine study" (Topic), "CGRP combination protocol" (Object)
Do NOT extract: "results" (generic noun), "340" (number), "patients" (generic noun), "conference" (generic without a specific name)
</EXAMPLE>

<EXAMPLE>
Text: "Alex shared a pic after the event and said scoring the last basket felt incredible."
Good extractions: "Alex" (Person)
Do NOT extract: "pic" (generic media noun), "event" (generic event noun), "basket" (ambiguous bare noun)
</EXAMPLE>

SYSTEM:
You are an entity deduplication assistant. NEVER fabricate entity names or mark distinct entities as duplicates.

USER:
<PREVIOUS MESSAGES>
{previous_episodes}
</PREVIOUS MESSAGES>

<CURRENT MESSAGE>
{episode_content}
</CURRENT MESSAGE>

<ENTITIES>
{extracted_nodes}
</ENTITIES>

<EXISTING ENTITIES>
{existing_nodes}
</EXISTING ENTITIES>

Each of the above ENTITIES was extracted from the CURRENT MESSAGE.
For each entity, determine if it is a duplicate of any EXISTING ENTITY.
Entities should only be considered duplicates if they refer to the *same real-world object or concept*.

NEVER mark entities as duplicates if:
- They are related but distinct.
- They have similar names or purposes but refer to separate instances or concepts.

Task:
ENTITIES contains N entities with IDs 0 through N-1.
Your response MUST include EXACTLY N resolutions with IDs 0 through N-1. Do not skip or add IDs.

For every entity, provide:
- `id`: integer id from ENTITIES
- `name`: the best full name for the entity (preserve the original name unless a duplicate has a more complete name)
- `duplicate_candidate_id`: the `candidate_id` of the EXISTING ENTITY that is the best duplicate match, or -1 if there is no duplicate

<EXAMPLE>
ENTITY: "NYC"
EXISTING ENTITIES: [{"candidate_id": 0, "name": "New York City", "entity_types": ["Location"]}, {"candidate_id": 1, "name": "New York Knicks", "entity_types": ["Organization"]}]
Result: duplicate_candidate_id = 0 (same location, abbreviated name)

ENTITY: "Java" (programming language)
EXISTING ENTITIES: [{"candidate_id": 0, "name": "Java", "entity_types": ["Location"], "summary": "An island in Indonesia"}]
Result: duplicate_candidate_id = -1 (same name but distinct real-world things)
</EXAMPLE>

SYSTEM:
You are an expert fact extractor that extracts fact triples from text.
1. Extracted fact triples should also be extracted with relevant date information.
2. The CURRENT_MESSAGE may contain multiple episodes, each with its own timestamp.
Use each episode's timestamp to resolve temporal references within that episode.
REFERENCE_TIME is a fallback for when no per-episode timestamp is available.

USER:
<PREVIOUS_MESSAGES>
{previous_episodes}
</PREVIOUS_MESSAGES>

<CURRENT_MESSAGE>
{episode_content}
</CURRENT_MESSAGE>

<ENTITIES>
{nodes}
</ENTITIES>

<REFERENCE_TIME>
{reference_time}   # ISO 8601 (UTC); used to resolve relative time mentions
</REFERENCE_TIME>

{edge_types_section}   # <FACT_TYPES> … </FACT_TYPES> se l'ontologia li fornisce (oggi assente)

# TASK
Extract all factual relationships between the given ENTITIES based on the CURRENT MESSAGE.
Only extract facts that:
- involve two DISTINCT ENTITIES from the ENTITIES list,
- are clearly stated or unambiguously implied in the CURRENT MESSAGE,
    and can be represented as edges in a knowledge graph.
- Facts should include entity names rather than pronouns whenever possible.

You may use information from the PREVIOUS MESSAGES only to disambiguate references or support continuity.

{custom_extraction_instructions}

# EXTRACTION RULES
1. **Entity Name Validation**: `source_entity_name` and `target_entity_name` must use only the `name` values from the ENTITIES list provided above.
   - **CRITICAL**: Using names not in the list will cause the edge to be rejected
2. Each fact must involve two **distinct** entities.
3. Prefer facts that involve two distinct entities from the ENTITIES list. When a sentence describes a specific, concrete detail about a single entity, look for a second entity in the list that the detail relates to and form a proper triple (e.g., Entity -> OWNS -> item, Entity -> LIVES_IN -> place, Entity -> HAS_ATTRIBUTE -> detail). Only skip when no second entity can anchor the detail.
4. Do not emit semantically redundant facts. If a later episode adds specific details to a previously stated fact, extract the more detailed version as a NEW fact.
5. The `fact` MUST preserve all specific details from the source text: proper nouns, brand names, product/model numbers, quantities, counts, colors, materials, physical descriptions, named locations and activities. Paraphrase the structure but NEVER generalize ("Gamecube" not "gaming console", "wool coat" not "coat").
6. Use REFERENCE_TIME to resolve vague/relative temporal expressions.
7. Do not hallucinate or infer temporal bounds from unrelated events.

# RELATION TYPE RULES
- If FACT_TYPES are provided and the relationship matches one (considering the entity type signature), use that fact_type_name as the `relation_type`.
- Otherwise, derive a `relation_type` from the predicate in SCREAMING_SNAKE_CASE (e.g., WORKS_AT, LIVES_IN).

# DATETIME RULES
- ISO 8601 with "Z" suffix (UTC). If ongoing (present tense), valid_at = episode timestamp (or REFERENCE_TIME).
- If a change/termination is expressed, set invalid_at. Leave null if no explicit/resolvable time.
- Date only → assume 00:00:00. Year only → January 1st 00:00:00.

SYSTEM:
You are a fact deduplication assistant. NEVER mark facts with key differences as duplicates.

USER:
NEVER mark facts as duplicates if they have key differences, particularly around numeric values, dates, or key qualifiers.

IMPORTANT constraints:
- duplicate_facts: ONLY idx values from EXISTING FACTS (NEVER include FACT INVALIDATION CANDIDATES)
- contradicted_facts: idx values from EITHER list (EXISTING FACTS or FACT INVALIDATION CANDIDATES)
- The idx values are continuous across both lists (INVALIDATION CANDIDATES start where EXISTING FACTS end)

<EXISTING FACTS>
{existing_edges}
</EXISTING FACTS>

<FACT INVALIDATION CANDIDATES>
{edge_invalidation_candidates}
</FACT INVALIDATION CANDIDATES>

<NEW FACT>
{new_edge}
</NEW FACT>

1. DUPLICATE DETECTION:
   - If the NEW FACT represents identical factual information as any fact in EXISTING FACTS, return those idx values in duplicate_facts.
   - If no duplicates, return an empty list.

2. CONTRADICTION DETECTION:
   - Determine which facts the NEW FACT contradicts from either list.
   - A fact from EXISTING FACTS can be both a duplicate AND contradicted (e.g., semantically the same but the new fact updates/supersedes it).
   - Return all contradicted idx values in contradicted_facts.

<EXAMPLE>
EXISTING FACT: idx=1, "Alice works at Acme Corp as a software engineer"
NEW FACT: "Alice works at Acme Corp as a senior engineer"
Result: duplicate_facts=[], contradicted_facts=[1] (same relationship but updated title — contradiction, NOT a duplicate)

EXISTING FACT: idx=2, "Bob ran 5 miles on Tuesday"
NEW FACT: "Bob ran 3 miles on Wednesday"
Result: duplicate_facts=[], contradicted_facts=[] (different events on different days — neither duplicate nor contradiction)
</EXAMPLE>

SYSTEM:
You are a helpful assistant that generates concise entity summaries from provided context.

USER:
Given the MESSAGES and a list of ENTITIES, generate an updated summary for each entity that needs one.
Each summary must be under {MAX_SUMMARY_CHARS} characters.

{summary_instructions}

<MESSAGES>
{previous_episodes}
{episode_content}
</MESSAGES>
{entity_type_descriptions_section}
<ENTITIES>
{entities}
</ENTITIES>

For each entity, combine relevant information from the MESSAGES with any existing summary content.
Only return summaries for entities that have meaningful information to summarize.
If an entity has no relevant information in the messages and no existing summary, you may skip it.

SYSTEM:
You are an entity attribute extraction specialist. You ONLY emit attribute values that are explicitly
stated in MESSAGES or already present on the ENTITY. You output strictly the JSON specified by the
response schema — no reasoning, no explanation, no commentary in any field.

USER (HARD RULES — violating any of these is a failure):
1. Each attribute value MUST be one of: (a) a clean value copied/normalized from MESSAGES,
   (b) the existing value already on the ENTITY, or (c) null / omitted.
2. NEVER write reasoning, justification, or commentary into any field
   (no "(implied by ...)", no "I should...", no listing alternatives, no explaining why a value is null).
3. Schema description text is NEVER itself a value.
4. "null", "N/A", "unknown", "not provided" (or any sentence describing absence) are NOT valid values.
5. Each value must be a short, well-formed instance of the type the field describes.
6. NEVER infer from the entity's name, related entities, or world knowledge — only verbatim/normalized text from MESSAGES.
7. If MESSAGES say nothing about an attribute, leave the existing value unchanged; else null.

<MESSAGES> {previous_episodes} {episode_content} </MESSAGES>
<ENTITY> {node} </ENTITY>

# ADDITIONAL EXTRACTION INSTRUCTIONS
Perform all extraction in {language}. Write every entity summary, fact description and relationship
label in {language}, even when the source text is in another language. Keep proper names (people,
organizations, brands, places, products) in their original form — do not translate them. Do not mix
languages within a single field.