PuranOS Ontology
Typed Relationships. Governed Actions.
200 typed links across 7 databases. 20 governed mutations with lifecycle preconditions. Click any node to explore how equipment, quotes, alarms, and compliance records connect across the entire system.
How the Ontology Layer Works
Compile-time, not runtime
The link catalog is generated at build time from two sources: foreign key constraints introspected from the live PostgreSQL databases (136 edges), and a hand-curated bridge-key seed file that classifies cross-database column matches with semantic labels like MONITORS, CONTROLS, and SOURCED_FROM (49 bridge edges, 15 external ref edges). No graph database. No runtime ontology kernel.
Domain-owned manifests
The owner of the write model owns the ontology manifest. Link and action declarations live next to the domain servers that own the tables. No central ontology committee. No bottleneck during commissioning when schemas evolve weekly.
Governed actions with lifecycle preconditions
Every governed mutation declares its preconditions against lifecycle state machines auto-generated from CHECK constraints: a vendor quote can only be awarded when its status is received, under_review, or shortlisted. Every mutation emits an append-only audit event.
Cross-validated in CI
Every link edge is validated against published Postgres table schemas for field existence and type compatibility. Live database introspection catches drift between DDL files and deployed reality. The validation has caught real inconsistencies.
Multi-hop traversal and entity context
Agents traverse up to 3 hops across the link graph in a single call — from equipment to alarm definitions to control loops to downstream compliance points. A unified context tool assembles the full situation report for any entity: its data, neighbors, lifecycle state, recent actions, and decision history, all in one concurrent query.
Decision traces (reasoning memory)
When agents make non-trivial decisions — technology selections, compliance determinations, vendor awards — the reasoning chain is recorded as a decision trace: what was considered, what tools were called, what was observed, and what conclusion was reached. These traces serve regulatory audit, debugging, and cross-session learning.
System-qualified entity identity
Tables that exist in multiple databases (e.g., project in 4 DBs with different primary keys) are disambiguated via system.table format. Each governed action declares a subjects list for exact entity-to-action matching with no heuristics.