Data, Ontology, and Events
The sovereign ontology gives your institution one structure for its knowledge, and applications, models, and workflows all use it. The ontology shows objects, relationships, and approved actions. The data design keeps current operational state apart from historical evidence. Governed events connect these two views across time and across the boundaries of organizations. Privacy policy states how you can collect, derive, move, and use data at each stage.
Ontology as institutional source of truth
The ontology describes the institution in terms that the institution owns. Relationships show how the objects connect. Approved actions state what an actor can do with the objects. The ontology objects include:
- actors
- authority
- intents
- requirements
- resources
- capabilities
- decisions
- work orders
- evidence
- outcomes
People and software use the same structure. An interface can show a work order, an agent can reason about it, and a workflow can act on it. No single application owns the definition of the work order.
The ontology must stay the same when you change an application, model, or store. Its definitions and relationships stay portable when you change a storage system or an enterprise connector.
Operational state and historical evidence
The architecture gives each data component a different role:
| Component | Architectural role |
|---|---|
| Operational store | Current entities, permissions, relationships, and active state |
| Open table format | Historical analytical datasets, snapshots, and reproducible views |
| Object storage | Raw documents, datasets, artifacts, and evidence |
| Product analytics | Experience events, experiments, and outcome measurements |
| Lineage relationships | Links among sources, derivations, decisions, and actions |
We use Postgres as an example of a transactional database, Iceberg as an example of an open table format, and PostHog as an example of product analytics. You can replace each of them.
Historical data lets you rebuild a decision with the data and features that existed at that time. Current operational state shows what the institution has permission and is ready to do now. Do not use historical data in place of current state, or current state in place of history.
Observations, features, inferences, and declarations
Keep four classes separate: raw observations, computed features, inferred attributes, and facts that a user declared.
An observation records a thing that a source captured. A feature records a derivation. An inference states an interpretation with uncertainty. A declaration records what a subject stated explicitly. Do not merge these four classes into one profile. If you merge them, you cannot explain or govern the result.
Lineage links the source, observation, feature, inference, decision, and action. Each inference must stay explainable, and you must be able to revoke it. The system keeps the observations behind each inference as separate records.
Sovereign event architecture
Each regional cell keeps local operational authority and sends governed events across boundaries. The rule is synchronous coordination inside a region and asynchronous exchange between regions.
An event gateway applies controls for identity, message integrity, schemas, data class, access policy, provenance, and audit. The gateway makes sure that repeated events have no extra effect (idempotency), and it controls replay. When an event goes to another region, it does not give the sender authority over the actions of the receiver.
Privacy as runtime policy
If data is available, that does not mean you have permission to use it. Policy controls how you collect, keep, join, and delete data, and how you move it across jurisdictions. Policy also controls these items:
- the purpose of the data
- which inferences you can make from it
- which models and capabilities can use it
- how far a deletion must spread to copies and derived data
- when a human must review
Each data item can carry a label, which is called a datum envelope. The label states the source, subject, time, confidence, authorization, purpose, sensitivity, allowed uses, and lineage of the item. Thus, privacy limits go with the data into later decisions.
Reference build
A reference build has these parts:
- an ontology for the institution
- a transactional store for current state
- historical tables
- storage for raw evidence
- an event gateway
- analytics
- a policy service outside the application
Derived features and inferences keep links to their sources. Approved capabilities use governed views. Outcomes go back into the evidence loop.
From the research
- “Data does not equal permission.” Master summary
- “Do not overwrite observations with inferences.” Master summary