Ontology Knowledge Graph

Problem

When an AI agent needs to remember facts across turns, link objects, query dependencies, or share state with other skills, conversational memory can be too loose. The same "project" may behave like an entity in one message and a label in another, and prior knowledge may be overwritten without history. This skill treats knowledge as a typed ontology graph: objects are entities with type, properties, and relations, and mutations are checked against constraints before they are committed.

How It Works

• Local storage: default data lives in memory/ontology/graph.jsonl, while constraints live in memory/ontology/schema.yaml; larger graphs can migrate to SQLite.
• Controlled changes: main workflows are creating entities, querying the graph, linking entities, and validating constraints. Existing data should be append/merged rather than overwritten, preserving history.
• Validation scope: supports property, enum, and forbidden checks, relation type and cardinality validation, acyclicity checks for acyclic: true relations, and Event checks such as end >= start. Higher-level semantic constraints may be documentation-only unless implemented in code.
• Planning and shared state: multi-step plans can be modeled as graph operations, with each step validated before execution and rollback on constraint violation. Mutations can also be logged as causal actions or exposed to other skills as shared ontology objects.

Fit and Caveats

Use it when you need a queryable knowledge graph, cross-skill shared state, or dependency tracking in local agent workflows. It operates on workspace files, so it fits local or sandboxed environments. If a constraint is only described in the schema but not enforced by code, validation may be limited.