Artifact Ontology for AI Systems

The Problem: Untyped Artifacts

Most AI companies track their outputs in flat tables. A validation run stores a target path, a score, and a result. A deploy log stores a timestamp and a commit hash. A billing record stores a Stripe price ID and a client name. Each table knows about one dimension of one artifact. None of them know that the research paper, the agent trained on that paper, the site displaying that agent, and the billing flow gating access to that site are all connected.

The consequences surface in operational questions that should be simple but are not. When a research paper fails re-validation, which agents are built on its findings? When a shared component changes, which client sites are affected? When a knowledge base is refreshed, which downstream artifacts need re-validation? Flat tables cannot answer these questions. The operator traces the dependencies manually, every time, or does not trace them at all.

The root cause is the absence of a schema for what the company produces. The system stores validation scores but has no formal definition of what a “research paper” is versus what an “agent” is versus what a “site” is. It stores relationships implicitly in code paths and naming conventions rather than explicitly in a queryable structure. This is the problem an artifact ontology solves.

The Foundry Precedent

Palantir solved this problem at enterprise scale with the Foundry Ontology. Foundry defines exactly three first-class concepts: Object Types, Link Types, and Action Types. An Object Type is a schema definition of a real-world entity. An Airport has properties: name, country, IATA code. An Employee has properties: name, department, start date. Each object type declares its property names, data types, and a primary key. The schema is the source of truth, not the application code.

Link Types define relationships between objects with declared cardinality and direction. An Employee “is assigned to” a Ticket. A Flight “departs from” an Airport. Links are not implicit foreign keys buried in application logic. They are first-class entities that can be queried, traversed, and governed independently.

Action Types define governed mutations. “Create ticket and assign to employee” is not an ad-hoc database write. It is a declared operation with preconditions, the mutation itself, postconditions, and side effects. Actions have rules about who can execute them and what happens after they complete.

The Ontology SDK generates typed interfaces from these definitions. Properties become fields. Links become accessor methods. Actions become typed edit batches. The compiler enforces the schema. If you add a new object type and forget to handle it somewhere, the code does not compile. This is the model worth adapting for AI artifact governance.

Artifact Types for AI Companies

An AI company that builds software for clients produces a specific set of artifact types. Each carries its own property shape. The discriminant is the artifact type. Validators, routers, and persistence layers operate on the discriminant rather than on string comparisons or file extension checks.

Each type shares a base set of properties: a unique identifier, a lifecycle state (draft, active, deprecated, archived), an owning entity, timestamps, and a last-validated result. The type-specific properties live in a structured metadata field. This mirrors Foundry's pattern: shared properties for universal operations, typed metadata for domain-specific logic. Adding a new artifact type means declaring its property shape, not writing new routing logic.

Relationships and Lineage

Artifact types alone are a taxonomy. The ontology becomes operational when you add relationships. In Foundry's terms, these are Link Types: directed, typed connections between objects with declared cardinality and cascade behavior.

For AI systems, the critical relationships form a directed acyclic graph. Research feeds knowledge bases. Knowledge bases train agents. Agents are embedded in sites. Sites are bundled into reveals. Billing flows gate access. Each edge carries a semantic label and a cascade flag: when the source changes, should the target be re-validated?

The lineage graph these relationships produce answers the questions that flat tables cannot. When a knowledge base is updated, a single graph traversal identifies every agent that depends on it and every site that displays those agents. When a shared component changes, the graph surfaces every client artifact in the blast radius. The traversal is a recursive query over an adjacency list, not a manual investigation.

Cascade semantics make this operational. A knowledge base refresh triggers re-validation of the agent it feeds, which triggers re-validation of the site that embeds it. The cascade follows the edges. It does not re-validate the entire graph, only the subgraph downstream of the change. This is Foundry's link traversal pattern applied to AI artifact governance: the ontology encodes the dependency structure, and the system walks it automatically when something changes.

Governance Through the Ontology

Foundry's third concept, Action Types, is what turns a data model into a governance system. An action is a governed mutation: it has preconditions, the change itself, postconditions, and side effects. For AI artifacts, the action layer is where detection becomes remediation.

Each artifact type carries a validation contract: the set of checks it must pass before it can be promoted from draft to active, or from staging to production. The contract is a function of the artifact type, not of the code that happens to validate it. Adding a new check to all agents means updating the contract for the “agent” type, not editing a validator file.

What This Changes

Without an ontology, adding a new validatable artifact means editing the router, the awareness module, the validator registry, the persistence layer, and the reporting system. Every new type is a code change in multiple files with no compile-time safety and no guarantee that all paths were updated. The architecture scales with the developer's memory, not with the system's structure.

With an ontology, adding a new artifact type means declaring its property shape, its validation contract, and its relationships in a registry. The router reads the registry. The cascade engine reads the registry. The reporter reads the registry. One declaration propagates through the entire system. TypeScript discriminated unions enforce exhaustive handling at compile time: add a new type, and the compiler shows every switch statement that needs updating.

The deeper shift is from implicit to explicit. Dependencies between artifacts stop being encoded in code paths and naming conventions. They become queryable rows in a graph. The question “what does this client's product consist of?” becomes a single traversal. The question “what is affected if this changes?” becomes a recursive walk. The question “when was this last validated, by what process, and what score did it get?” becomes a join. The ontology does not add new capabilities to the system. It makes the capabilities the system already needs actually possible to implement.