ontology

• Du vill att en agent ska komma ihåg strukturerad information mellan sessioner (t.ex. "Kom ihåg att Alice äger Projekt X").
• Du behöver länka relaterade objekt och traversera dessa länkar senare (t.ex. "Visa alla uppgifter för projekt Z", "Vad är beroende av X?").
• Flera skills behöver dela tillstånd utan att skicka råtext — en skill skriver ett Commitment, en annan läser det som en Task.
• Du planerar arbete i flera steg och vill att varje steg modelleras som en validerad graftransformation med återställning vid regelöverträdelse.

• Du behöver bara tillfällig, enkelväxlad kontext och har inget behov av persistens mellan agentkörningar.
• Din data är helt ostrukturerad (fritext) utan några meningsfulla entitetsrelationer att modellera.
• Du behöver en produktionsfärdig grafdatabas med hög samtidighet — för stora eller komplexa grafer rekommenderar SKILL.md själv att migrera till SQLite.

Levereras med en omfattande uppsättning fördefinierade typer som täcker agenter (Person, Organization), arbete (Project, Task, Goal), tid och plats (Event, Location), information (Document, Message, Note) samt resurser (Account, Device, Credential). Varje typ har typade egenskaper och valfria fält så att du kan modellera verkligheten utan att behöva uppfinna scheman från grunden.

Varje mutation valideras mot regler definierade i memory/ontology/schema.yaml innan den genomförs. Begränsningarna inkluderar obligatoriska fält, enum-värden, förbjudna egenskaper (t.ex. blockering av råa hemligheter på Credential), regler för relationstyp/kardinalitet, acyklicitetskontroller samt temporala rimlighetskontroller som end >= start på Event.

Grafen lagras som en append-only memory/ontology/graph.jsonl-fil — varje skapa-, uppdatera- och relatera-operation är en ny rad, vilket bevarar hela historiken. För komplexa grafer rekommenderar SKILL.md att migrera till SQLite, med bibehållet samma gränssnitt.

En scripts/ontology.py CLI tillhandahåller kommandon för alla kärnoperationer: create, query, get, related, relate, validate och schema-append. Detta gör det möjligt att köra det som skript från vilket skalsteg eller agentåtgärd som helst utan att behöva skriva anpassad grafkod.

Kompetenser kan deklarera ett ontology-kontrakt i sin egen SKILL.md som specificerar vilka typer de reads (läser) och writes (skriver) samt för- och eftervillkor. Detta gör databeroenden mellan kompetenser explicita och granskningsbara, och förvandlar ontology till en typad meddelandebuss mellan förmågor.

Flerstegsplaner kan modelleras som ordnade sekvenser av grafoperationer (CREATE → RELATE → CREATE …). Varje steg valideras innan det utförs och hela planen kan rullas tillbaka vid en begränsningsöverträdelse, vilket ger agenter ett strukturerat och granskningsbart planeringslager.

En agent skapar Person- och Project-entiteter första gången de nämns och kopplar sedan samman dem med has_owner- eller has_member-relationer. Vid framtida dialogturer kan frågan "Vad vet jag om Alice?" traversera grafen för att lyfta fram alla relaterade projekt, uppgifter och händelser – utan att förlita sig på konversationshistoriken.

En e-postläsningsfärdighet extraherar ett åtagande från ett meddelande och skriver en Commitment-entitet till ontology. En separat uppgiftshanteringsfärdighet frågar regelbundet efter väntande Commitment-objekt och skapar automatiskt länkade Task-entiteter — ingen direkt koppling mellan de två färdigheterna krävs.

En planeringsagent modellerar ett projekt som en uppsättning Task-entiteter med blocks-relationer. Acyklicitetsbegränsningen förhindrar att cirkulära beroenden sparas, och en related-fråga visar omedelbart vad som måste slutföras innan en given uppgift kan påbörjas.

Innan agenten kör ett komplext arbetsflöde (t.ex. "Schemalägg teammöte och tilldela uppföljningsuppgifter") omvandlar den varje steg till en validerad grafoperation. Om något steg bryter mot en begränsning rullas hela sekvensen tillbaka, vilket ger ett säkert och inspekterbart körningsspår via loggen av typen Action.