The Ontology (Petioles)

Dominir does not store rows in a table. It stores a graph of connected facts. Each fact is a triplet: a subject, a predicate (the relationship), and an object.

{
  "subject": "employee:4829a901",
  "predicate": "reportsToUnit",
  "object": "org:infra-core"
}

In plain terms: employee 4829a901 reports to the Infrastructure Core unit.

Petioles

A petiole is the slot where a piece of data lives inside an ontology class. Think of it like a typed column in a spreadsheet — except instead of a flat table, the columns belong to a structured class definition, and every value must conform to the rules that class enforces.

Petioles carry:

• ▸The expected data type (text, date, a reference to another record, etc.)
• ▸Whether one or many values are allowed
• ▸Whether the field is required or optional
• ▸Provenance — a record of where the data came from

When a record arrives, the Kernel checks each incoming value against the petiole rules. If everything matches, the record is committed to the ledger. If it does not match, the record is not discarded — it is flagged.

Shadow Petioles

A Shadow Petiole is a data field that arrived but could not be mapped to the schema. The incoming value is held in a pending state rather than silently lost.

When the Kernel flags a Shadow Petiole, it marks it with the sentinel status toggle [ STATUS: SHADOW ]. Administrators can then:

1. ▸Map the shadow field to an existing schema definition and re-commit it.
2. ▸Extend the ontology with a new petiole to accommodate the data.
3. ▸Discard it through the Airlock.

Shadow Petioles remain visible to administrators in the UI until resolved. They do not appear in standard agent queries.

Reading data back out

Records are read directly from the graph by querying the Kernel. The Hydra SDK (Python) exposes this through HydraStore.scan(). The Kernel returns results as structured data frames — rows of typed values, ready for analysis without any intermediate conversion step.