Ontology Generation: How AI Logs Turn Work Into Organizational Knowledge

When AI becomes the universal interface, interaction logs can reveal both what an organization does and the concepts it uses.

An ontology represents an organization’s concepts, their properties, and their relationships in a structured form. Palantir’s Foundry platform uses this approach to model organizational entities and operations, making objects, properties, relationships, and actions explicit and queryable.

Structured organizational knowledge lets people act systematically. Without it, expertise often remains with individuals, process documentation diverges from practice, and departures cause knowledge loss.

The problem has always been construction. Building an ontology is expensive. It requires extracting knowledge from experts, formalizing it into structures, validating that the structures match reality, and maintaining them as the organization evolves. Most organizations don’t have the resources or discipline to do this well. So the knowledge stays scattered, implicit, inconsistent.

The Universal Interface Changes This

When agentic AI becomes the universal interface, users express every task, query, and operation through natural-language interaction with the tool.

If every system interaction uses that interface, the logs record all of that work.

From those logs, two things emerge:

Structural ontology: what things are. When someone says “find all orders for customer X that shipped after Y,” the interaction reveals:

• Entities: orders, customers
• Properties: ship date
• Relationships: orders belong to customers

Thousands of interactions reveal recurring entities, their relevant properties, and relationships. Those usage patterns provide the material for an organizational ontology.

Procedural patterns: how things get done. When someone successfully completes a task, the interaction captures:

• The specification of intent
• The generated approach
• The execution result

Repeated successful approaches to similar tasks become candidates for reusable templates.

Comprehensive interaction logs provide the source for both the structural ontology and procedural templates.

The Generation Path

For structural ontology:

1. Interactions reference concepts. Every task mentions entities, properties, relationships: implicitly or explicitly.

2. Concepts accumulate across interactions. The same entities appear repeatedly. Properties get referenced. Relationships get expressed.

3. Structure becomes visible. “Customers” appear with “orders.” “Orders” have “ship dates” and “line items.” “Products” belong to “categories.” The conceptual model emerges from usage patterns.

4. Validation confirms or corrects. Human review checks whether the emergent structure matches organizational reality. Artifacts get renamed, relationships get clarified, gaps get identified.

For procedural patterns:

1. Tasks produce logs. Each interaction generates a record: what was asked, what was produced, whether it worked.

2. Successful approaches get identified. When tasks succeed, the logs capture working solutions: intent, translation, artifact.

3. Recurring patterns get extracted. Similar tasks solved similarly become candidates for templates.

4. Reviewers approve templates. Humans decide which patterns merit reuse. Validated patterns become method-bearing artifacts whose exposed methodology provides a basis for defensibility.

5. Templates become available. Validated patterns are distributed: available to agents across the organization.

Construction, Maintenance, and Distribution

The construction problem. Both structural ontology and procedural templates get built as a byproduct of work, not as a separate project. Every interaction contributes.

Maintenance. Traditional ontologies can diverge from practice because updating them requires separate work. Rebuilding from interaction logs tracks usage continuously, although reviewers must account for differences between what people say and what they do.

Knowledge held by individuals. Expert interactions record the concepts they use and how they complete tasks. The tool helps them articulate previously inexpressible knowledge, making it available to others. This is tacit space shrinkage in practice.

Distribution. Every agent can use a concept or pattern once it is in the system, without separately training each user.

The Palantir Comparison

Palantir’s approach requires deliberate construction: ontology architects who model the organization, engineers who build integrations, ongoing maintenance to keep the model current. It works, but it’s expensive. It requires commitment and expertise that most organizations lack.

In the generation approach, experts’ normal work provides the source material. Their natural-language interactions continuously produce candidate concepts and relationships that humans still need to validate.

Both approaches produce structured organizational knowledge. Palantir’s is designed top-down by specialists. The generation approach derives bottom-up from usage. For organizations that can’t or won’t invest in deliberate construction, the generation path produces ontologies as a side effect of adoption.

Implementation Requirements

Comprehensive logging. All interactions must use the tool and be recorded in queryable form. Interactions that bypass it leave gaps in the logs.

Concept extraction. The system must resolve different phrasings of entities, infer relationships, and derive a schema from accumulated interactions. Current AI can reasonably extract concepts from individual texts; combining thousands of interactions into a coherent structure remains an active research problem. Extraction must be accurate enough that reviewers can catch the remaining errors.

Pattern extraction. The system must group similar successful solutions and propose recurring approaches as template candidates.

Validation process. Humans review concepts and templates before approving them for general use. They check whether concepts correspond to the organization, whether patterns generalize, and how they might fail. At scale, domain owners review candidates in their areas, prioritizing frequent cases and accepting that some will wait. Validation is the bottleneck, but having candidates waiting for review is better than having none to validate.

Distribution mechanism. Validated knowledge needs to reach agents across the organization. Concretely: a registry of approved concepts and templates, queryable by agents when they encounter similar tasks. Version control for when patterns evolve. Context tags for when a pattern applies in some situations but not others.

Objections

Privacy and security. Interaction logs contain reasoning, mistakes, and confusion as well as outcomes, making them more sensitive than server logs or transaction records. Governance must specify what is logged, who can read or query it, and how long it is retained. Generation requires logs, so the controls must match their sensitivity.

“Concept extraction will find spurious patterns.” Yes. Not every entity reference is a real concept. Not every relationship expressed reflects actual structure. Validation exists precisely for this reason. The generation process produces candidates; human judgment promotes them to canonical status.

“Different experts use different terms for the same thing.” This is where the generation approach has an advantage. Usage patterns reveal synonyms. If “clients” and “customers” appear in the same structural positions, the system can propose consolidation. Traditional ontology construction requires someone to notice and reconcile these differences manually.

Conflicting methods. Reviewers can retain multiple valid approaches for different contexts or approve one and retire another. Logging makes disagreements visible that might otherwise go unnoticed.

“This only captures what people actually do with the tool.” Domains untouched by the tool contribute no ontology. The generated structure therefore reflects use in practice. If an important domain is rarely used through the tool, the absence identifies a gap that needs attention.

“Won’t this lock in current practices?” Logs record what works in practice. Better approaches will appear as people use them, and reviewers can compare new candidates with existing templates. The ontology should change with successful practice.

“How does this start? Chicken and egg.” Initial interactions proceed without an ontology. The first patterns are extracted from scratch, and agents benefit increasingly as validated concepts and templates accumulate. The system is less valuable on day one than on day one hundred, but can start without existing ontological support.

Errors after approval. Retiring an incorrect concept or pattern requires deprecation markers, version history, and downstream dependency tracking so agents know it should no longer be used. This costs less than maintaining a traditional ontology from scratch, but still requires work.

“Different parts of the organization will develop incompatible structures.” Cross-domain coherence is a real problem. If finance models “customers” differently than operations, the ontology fragments. The generation approach needs periodic reconciliation: identifying overlapping concepts across domains, proposing unification, flagging conflicts for human resolution. Palantir’s top-down approach handles this by design. The generation approach handles it by detection and repair.

The Recursive Improvement

As structural concepts and procedural templates accumulate, agents have more to use. Better initial approaches increase success rates, producing more useful logs and a richer ontology.

This feedback loop can also amplify errors. Bad patterns promoted early get reinforced by reuse. Ontology optimized for common cases can make edge cases invisible. The validation process is what prevents the vicious cycle: catching bad patterns before they propagate, deprecating patterns that fail in practice, maintaining quality as the system scales.

As the ontology grows, the barriers described in Automating Expertise Gets Easier and Easier keep falling, provided validation keeps pace.

Connection to the Framework

Ontology generation is how Executable Knowledge Architecture produces lasting organizational value.

Individual EKA engagements produce artifacts that reveal concepts and relationships. Reviewers approve successful artifacts as procedural templates. Together, the concepts and templates represent what the organization knows and how it works.

Stored data provides facts; the ontology defines their relationships and includes reusable capabilities. Agents use both to operate as an organizational interface.

→ Return to Agentic AI as Universal Interface → Return to Executable Knowledge Architecture