The Living Ontology.

Executive summary

A decision layer is only as useful as the ontology beneath it. Most enterprise systems freeze that ontology at install time and evolve it through quarterly data-engineering sprints. The cost is real: by the time the ontology catches up with what operators actually do, the operators have already worked around it.

We propose, and have shipped, a different model: every change to the ontology — a new entity type, a promoted property, a relaxed approval threshold, a deprecated relationship — flows as a typed Evolution Proposal, emitted by agents watching tenant behaviour, decided by operators in an inbox, and recorded on the same tamper-evident audit chain that governs every operational action.

The result is not "AutoML for schemas." It is a governed, reversible, defence-grade pipeline in which the ontology itself becomes a first-class operating surface. Phase 1 is live in our taygeta.maiaintelligence.io substrate. This paper describes the architecture, the heuristics, the governance guarantees, and why this is the moat.

The frozen-ontology problem

Operational platforms acquire ontology debt the same way they acquire technical debt: every workaround an operator does to work around a missing object type, every property they fill in ad-hoc as a free-text comment, every link they draw by hand because the system does not codify it. Each of these is a signal that the ontology has drifted from the work.

Palantir Foundry's recent General Branching release (May 2026) recognises this and ships a real proposal-and-merge workflow on top of Action Types, with Ontology Proposals auto-created when a branch carries schema changes. C3 AI invests heavily in lineage and veracity to keep the type system traceable. ServiceNow and Salesforce both offer ontology evolution paths stitched through their workflow engines.

What none of them ship — and what defence and government operators specifically need — is an ontology evolution surface whose actors are the agents themselves, governed under the same evidence-bound autonomy rules that gate every operational action.

Evolution Proposals as first-class objects

An EvolutionProposal is a typed record. It carries its kind (promote-property, introduce-type, relax-threshold, deprecate-type, classify-tighten), its target (the entity-type, property, relationship, or action it touches), an engine-readable patch (the change to apply on approval), and the evidence chips that triggered it — typically a count, a ratio, a recency window, or a federation hint from a peer tenant.

Each proposal also carries its blast radius in plain numbers: how many entities the change affects, how many actions it touches, how many tenants would inherit it on federation opt-in. The operator sees the cost of the change before they decide, which is the difference between an inbox and a bug farm.

Severity is computed, not declared: confidence above 0.85 routes to a critical lane, 0.5–0.85 to review, below 0.5 holds in a draft state that never reaches the operator queue unless additional evidence accumulates. This honours our HITL rule: agents may auto-execute when confidence is unambiguous and the action class is approved for automation, but every schema-level change crosses a human gate.

The Proposer Agent

Phase 1 ships five heuristics, each deterministic against a snapshot of the live runtime:

1. Property promotion. If an inferred property appears on at least 60% of entities of a single type, propose canonicalising it. Adds typed validation, autocomplete, and downstream agent eligibility.
2. Threshold promotion. If an action ofREVIEW severity has been approved by operators with greater than 90% acceptance across at least 25 decisions, propose moving it to AUTO. Removes friction without losing audit.
3. Relationship promotion. If the same source-to-target link has been drawn by hand at least eight times in nine days, propose codifying it as a typed relationship. Lets agents traverse the graph without inferring intent.
4. Type deprecation. If a type has fewer than three instances and no new activity in fourteen days, propose retiring it. Reduces operator cognitive load; instances migrate to an archive ontology rather than being deleted.
5. Classification tightening. If at least four entities of a type carry a property pattern (sub-meter coordinates with friendly-force affiliation, for example) that suggests a higher classification floor, propose raising it. Gates downstream OSINT exports.

Each heuristic is a starting point, not a ceiling. The actual production pipeline composes these with embeddings-based pattern detectors that read the persisted ledger, plus federation hooks that surface proposals adopted at peer tenants — sharing the delta, never raw entities.

Governance and reversibility

Three guarantees make this safe in a defence context:

Tamper-evident chain. Every transition — proposed, approved, applied, rejected, rolled-back — writes a row on the audit ledger with a FNV-1a-linked previous-hash pointer, mirrored asynchronously to a durable store, and optionally signed via an RFC 3161-style timestamp authority for inter-agency disclosure. The lineage of every ontology change is reconstructible at any point in time.

Reversibility flag per proposal. Additive changes (new properties, new types, raised classification floors) are reversible by definition; one click rolls back the patch and the change is recorded as a new ledger event. Destructive kinds — type merge, type split, type deprecation — carryreversible: false and wait for an explicit operator gesture beyond approval, even after approval, so the moment of mutation is always operator-owned.

Federation by delta, never by data. When a tenant opts a merged proposal into the federation, the network receives the anonymised delta, the severity tag, the blast-radiuscounts only, and the agent class that emitted it. Raw entities never leave the tenant. Peer tenants see the proposal in their own inbox as a federated suggestion; they decide independently. This is the only honest model for cross-tenant ontology learning in classified or sovereignty-constrained environments.

What this looks like in the product

The Phase 1 surface ships at /evolution-proposalsinside the Taygeta substrate. Three columns, Foundry-style:Inbox (pending operator review, sorted by severity), Reviewing (approved, awaiting apply or recently applied), Resolved (rejected, rolled back, or expired — last seven days).

Each card carries a severity stripe, a kind icon, a one-line title, the impact pills (entities, actions, tenants), a confidence bar, and the agent that proposed it. Click opens a side drawer with the full body, three to five evidence chips, the engine-readable patch as JSON, the audit trail of the proposal so far, a reversibility callout, and approve / reject / rollback buttons with required rationale on reject.

The colour ramp is MIL-STD-2525 affiliation: amber for review, red for critical, lime for applied, cyan for approved, slate for resolved. This is not theming for theming's sake — it propagates across every defence surface in our platform so an operator's eye trains on a single lexicon of state.

Why this is the moat

Every operational decision platform competes on integrations, workflows, and dashboards. Those are necessary and they are not differentiating; the long tail of feature-parity catches up. What does not catch up is an ontology that improves with usage, because the improvement curve compounds across tenants in proportion to the size of the network.

A new tenant joining MAIA does not start at the same place a new Foundry tenant starts. They start with the merged history of every reviewed and accepted proposal that prior tenants opted into the federation. Their typing autocompletes their data shapes on day one. Their agents reason against properties that, in a frozen-ontology system, would take a quarter of data engineering to surface.

This is the only architecture in which the marginal cost of onboarding falls as the network grows — the textbook definition of a moat.

What ships next

Phase 2 takes the proposal stream from a per-tenant Kanban to a federated network. A signed registry of Network Proposalsrelays anonymised deltas between tenants; subscribers receive them as pre-populated suggestions. Adoption analytics flow back as counts, never as identities.

Phase 3 adds the timeline river chart: every type a row, every merged proposal a block, every reverted proposal a counter-block. Hover surfaces the diff. The operator can scrub backward in time and see exactly the ontology the platform was running on any given day — the same property that makes the audit chain useful to an inspector general.

Phase 4 wires the proposer to a richer signal substrate: embeddings-based pattern detection over the persisted ledger, adversary-model deltas (an ontology shift that benefits a known adversary class is flagged for compliance review before it reaches the operator), and outcomes-attributed feedback loops (proposals whose applied form correlates with poor outcomes in subsequent decisions auto-roll-back at a configurable confidence floor).

An invitation

The live Phase 1 surface is at taygeta.maiaintelligence.io/evolution-proposals. We seeded the demo with six representative proposals against our maritime and aviation ontology — approve them, reject them, roll them back. Each gesture appends to a chain you can verify.

We welcome critique, especially from teams building in the same space. The argument we are making — that the ontology should evolve from observed behaviour under tamper-evident governance — is not original to us; the implementation that ships this paper into operational practice is.

References

• Palantir Foundry, Ontology Proposals & Global Branching (Foundry docs, May 2026).
• Palantir AIP Logic, Automate & Proposal Cards (Foundry AIP docs, 2026).
• C3 AI, Lineage and Veracity in the Type System (c3.ai/c3-agentic-ai-platform, 2026).
• TerminusDB, Git-style schema branching for knowledge graphs (terminusdb.com, 2026).
• Stardog, Integrity Constraint Validation for production knowledge graphs (docs.stardog.com, 2026).
• Glean, Knowledge Graph: single-tenant by design (docs.glean.com, 2026).