Data Sources

Object types can be backed by warehouse datasets, letting the ontology govern data whose system of record is an existing analytical store.

Registration and mapping

A data source (a warehouse connection) is registered, reviewed, verified, and activated through the same governed designer flow as everything else — never auto-seeded. Credentials are held as references resolved through the configured secret store (Azure Key Vault in production); credential values never live in the ontology.

A backing-dataset mapping binds an object type to a table: which columns feed which properties, and which keys align rows to instances. Mapped reads serve instance data through the ontology's access-control seam — warehouse rows arrive with row filters and masking applied like any other read.

Drift

The warehouse evolves, and mappings can silently rot. Manifest scans for drift — schema changes that break a mapping — surfaces findings for review, and marks broken mappings rather than serving wrong data. Repair (rebinding) is a governed change like any other.

Write-back

Governed edits can flow back to the warehouse: approved actions upsert to the backing table with idempotency protection, so the ontology's review flow becomes the front door for warehouse mutations rather than a divergent copy.

Fail-closed at boot

At startup every active source is validated: well-formed connector configuration and resolvable credential references, or the deploy crashes. Reachability is deliberately not checked — a warehouse being down is an operational fact, not a deployment fault.