Typed Ontology Knowledge Graph

Problem

In multi-agent workflows, memory often stays scattered across chat text, temporary variables, or private skill state. That state is hard to query, validate, and reuse safely across skills. ontology123 addresses this by expressing objects, properties, relations, and constraints as one verifiable graph instead of letting each skill maintain its own unstructured notes.

How It Works

• Entity modeling: Each knowledge object is represented as an entity with a type, properties, and relations. Typical triggers include remembering a fact, querying an object, linking two entities, listing project tasks, or checking dependencies.
• Constraint validation: Default data can be stored in memory/ontology/graph.jsonl, with constraints defined in memory/ontology/schema.yaml. The material describes checks for properties, enums, forbidden values, relation types, cardinality, acyclicity for relations marked acyclic: true, and Event end >= start rules.
• Graph workflows: The skill centers on creating or updating entities, querying, linking, and validation. Multi-step plans can be modeled as a sequence of graph transformations, validating each step before execution and rolling back when constraints fail.
• Shared state and append behavior: Skills using the ontology should declare a shared-state contract. Ontology mutations can also be recorded as causal actions for cross-skill use. Existing data should be appended or merged, not overwritten, to preserve prior definitions.

Boundaries

It fits file-local shared knowledge better than a distributed database or a full semantic web. The default JSONL storage may not suit complex graphs, and the material suggests SQLite for larger cases. Some advanced constraints may remain documentation-only unless implemented in code.