name	update-kg
description	Update the ndoli personal knowledge graph. Run once at the end of a session — only when something actionable actually happened: a new contact was made, an email was sent, a meeting occurred, a deal status changed. Do not invoke mid-conversation or just because entities were discussed.

Read ~/.codex/config.toml, find the [ndoli] section, and use the path value as the absolute path to the KG directory. All TTL file reads and writes must use that path — not the current working directory, not any repo you happen to be in. Then review this conversation from top to bottom and update the KG files at that path.

Work through these checks in order:

1. New entities — did any new people, orgs, opportunities, or projects come up?

Search existing TTL files by name before adding — no duplicates
Put them in the right Tier 2 file for their class (contacts.ttl, opportunities.ttl, projects.ttl)
If the entity belongs to a new class not yet in the ontology, add the class to ontology.ttl first (step 5), then create a new Tier 2 file (e.g. events.ttl) if there are enough instances to warrant it — otherwise add to the closest existing file with a comment
Stable facts only on the entity: name, org, role, ndoli:firstContact, ndoli:lastContact, ndoli:status
No notes field — history goes in observations

2. New observations — did anything happen that should be recorded as evidence?

Write a new ndoli:Observation instance to observations.ttl
URI convention: obs:ENTITY_YYYY_MM_DD (append _2, _3 if multiple on same day)
Set ndoli:involves for each entity touched, dcterms:date, ndoli:interactionType, schema:description
Set dcterms:source to any URI that documents the observation — email thread, local file, calendar event, URL. Use multiple dcterms:source triples if the observation is documented in more than one place. Provenance is the point.
Observations are immutable — create a new one, never edit an existing one
Interaction types: meeting, call, email, async, read, event

3. Enrichment — did we learn anything new about an existing entity's stable facts?

Status changes (active → warm, pending → closed-won, etc.)
Update ndoli:lastContact on the entity to match the most recent observation date
New role, org, or research area

4. Opportunity updates — any status changes or deadline shifts?

5. Ontology gaps — did any new class, relationship type, or property come up that isn't modeled yet?

New class: something that doesn't fit any existing class and warrants its own type (e.g. ndoli:Event, ndoli:Publication)
New property: a relationship or attribute used on an entity that has no existing predicate
Add anything new to ontology.ttl with a rdfs:label and rdfs:comment

Conventions:

Use the prefix and snake_case URIs established in the existing TTL files
Dates: "YYYY-MM-DD"^^xsd:date
Link source material via dcterms:source <https://...> on the observation
Status (people): active, warm, cold, closed
Status (opportunities): active, pending, closed-won, closed-lost, deferred

After updating, briefly summarize what changed (2–4 lines max).

name	update-kg
description	Update the ndoli personal knowledge graph. Run once at the end of a session — only when something actionable actually happened: a new contact was made, an email was sent, a meeting occurred, a deal status changed. Do not invoke mid-conversation or just because entities were discussed.