• HallucinationFabricates nonexistent facts with a straight face
• UncontrollableAsk the same question twice and the reasoning paths can diverge wildly
• UnauditableWhen something goes wrong, it can't answer "why was this approved?"

The industry's answer is oddly unanimous: put a "semantic cage" around AI

In an engineering context, ontology is no longer a philosophical inquiry but something concrete—the domain's semantic schema. An e-commerce risk-control ontology spells out at least three things explicitly:

• Concepts: what is a "user," a "risk," an "order"
• Relations: user → places → order
• Rules: orders over 100k must go through risk-control approval

Four elements

• ClassCore domain concepts: Person, Disease, Drug—like a "class" in OOP or a "table" in a database
• PropertyData properties (hasAge) describe traits; object properties (treats) connect different classes
• ConstraintCardinality (exactly two biological parents), range (age > 0), disjointness (Man and Woman don't intersect)
• Inference ruleOWL's soul. Declare hasParent transitive, or write SWRL rules; a reasoner (HermiT, Pellet) scans the whole base to derive new relations automatically

hasParent(?x,?y) ∧ hasParent(?y,?z) → hasGrandparent(?x,?z)

An often-overlooked design premise

• Open World Assumption (OWA): information not in the knowledge base isn't "false," only "unknown"—great for inferring over incomplete knowledge, but awkward for "checking whether data is compliant"
• So the W3C created SHACL specifically: closed-world, validation-oriented, purely for "does the data look right." One handles reasoning, one handles validation—in the classic ontology stack, "description" and "constraint enforcement" have always been two separate mechanisms
• Top-down, expert-driven: domain experts supply concepts and rules, knowledge engineers translate to OWL; pursuing "small and precise"
• The cost: very high build cost, hard to maintain, poor scalability on massive dynamic data—so industry standards like the GO gene ontology and SNOMED CT clinical terminology use it, but few run live business on it

Extremely tolerant of reality's incompleteness

• Weak constraintsDoesn't force every "person" to have a "birth date," or the data couldn't get in at all
• Allows gapsA just-released film can go without "total box office" for now
• Tolerates conflictEncyclopedia A says born 1900, B says 1901—accept both, reconcile later

Both construction and reasoning are the opposite of OWL

• Bottom-up, auto-extracted: NLP extracts entity relations from massive text (information extraction) → aligns to existing bases (entity linking) → induces a type system (schema induction)
• Data-driven statistical inference, not seeking logical necessity: path ranking (PRA), graph embeddings (KGE, core assumption h + r ≈ t), simple transitive rules—all "probably holds" rather than "logically necessary"
• Pursues "large and complete": covering vast entities, millisecond-scale relational lookup. This sits behind Google's Knowledge Graph, e-commerce recommendations, and QA

• Type ≠ instanceAn object type is pure metadata with no data values—Airport is a type, JFK is an instance; a link type is a relationship schema, a link is the single row "Melissa Chang → Acme, Inc." (official analogy: one row after joining two datasets)
• Shared property"Created time/status/priority" defined centrally, referenced in many places, change once syncs all—DRY realized at the type-system level
• InterfaceA contract sliced by capability: Inspectable, SchedulableResource—an interface-facing scheduling flow applies unchanged to meeting rooms, venues, vehicles (composition over deep inheritance). Interfaces can define Actions, but only edit shared properties, and no Action may change a primary key
• Value typeWraps a string into "email address/UUID" with constraints attached—"age > 0" becomes a reusable asset
• Reflexive relationOn Employee, "direct report ↔ manager"—org hierarchies and BOM parent-child parts all rely on it

"Living" isn't magic, it's pipelines

• Each object type has a backing data source: batch pipeline / stream pipeline (low latency) / direct connect; the data source for many-to-many links attaches to the link type itself
• Incremental indexing (on by default in OSv2) processes only changes—the engineering meaning of "the model reflects underlying changes instantly"
• Security is part of the type system: MDO multi-source data objects (column-wise like a join: contact info from a public directory, salary from a controlled HR base, split at property level; row-wise like a union: each region supplies its own rows); restricted views do row-level permissions and inherit to object instances—at a cost: strictly read-only, can't be a downstream input, no external sync

So business users can ask directly: "average vibration of equipment with status 'awaiting repair' at the 'Shanghai plant' over the past 24 hours"—the system parses objects, conditions, and aggregation automatically.

Manages four things

• Ontology iterationAuto- or semi-auto-updates the semantic layer from data/feedback/business changes—spot a frequently searched "long-tail" field, suggest promoting it to a standard property
• Action optimizationFind 90% of approvals pass via one role → suggest "auto-approve"; run root-cause analysis on frequently failing actions
• Rule evolutionMine new patterns from history to generate alerting rules, adjust thresholds dynamically by season
• CompatibilityThe lifeline: version coexistence, auto-migration, deprecation warnings, canary release

Sounds like a vision? The product has concrete counterparts

• Global Branching handles structural evolution: schema changes (adding object types, altering property definitions) branch first, test in isolation, merge to trunk after validation—zero downtime; the complementary "Scenarios" handle sandbox what-ifs at the data level
• Schema migration: after OSv2 supports breaking changes, it migrates existing user edits over rather than discarding them
• Versions record "semantic state" rather than row-level snapshots: relation establishment and dissolution, entity-identity merge and split, confidence updates. In the defense ontology, every assertion carries a standardized 1–5 confidence level + source system + report location and timestamp—so you can "return to any point in time and see what was known then," the foundation of decision traceback and audit compliance

• Deterministic matchPrecise matching via unique IDs like ID number or employee number—100% accurate, but can't cover long-tail data lacking a unified ID
• Probabilistic matchWithout a unique ID, analyze similarity of name, address, phone (TF-IDF, cosine similarity, random forest) to compute a "same entity?" confidence score—covering deterministic matching's blind spots
• Survivorship rulesArbitration logic when the same entity's info conflicts (e.g. "trust the most recently updated system"), determining the final golden record

Defense scenarios go further

• Multi-source data objects merge a social media account, customs passport number, corporate registration record into the same Person
• Every assertion carries a 1–5 confidence level and full provenance (source system, location, timestamp)
• The unified object keeps all source links—a sanctioned entity's shell-company network spanning jurisdictions and languages surfaces automatically this way

• ① Structured retrievalGet typed objects, deterministic property values, explicit relation edges via OSS—not similarity-ranked text fragments
• ② Schema+permission constraintsRetrieval results are trimmed by ontology schema and caller permissions. Classic RAG mishaps like "retrieving a proposal abandoned three years ago and using it as the latest plan" are structurally eliminated
• ③ Deterministic tool callsMath and optimization aren't left to the LLM to brute-force: AIP Logic identifies the subtask, calls NVIDIA cuOpt (supply-chain optimization) or Prophet (time-series forecasting) via ontology functions, and hands only verified output back to the LLM for language synthesis. The LLM is repositioned from "omnipotent reasoner" to "coordinator": task decomposition, tool orchestration, result explanation
• ④ Full provenanceEach inference traces back to specific objects, properties, and relation edges—the answer isn't "the model feels," but "here's the evidence"

• AIP LogicA low-code LLM-function orchestrator. Input ontology objects or strings, output objects or ontology edits; write-back has two modes—auto-apply or staged for human review; can be driven on schedule/event by Automate
• AIP EvalsPulls a non-deterministic system back into engineering discipline: run the same prompt hundreds of times for statistical evaluation, test edge cases with real production data; built-in exact-match/regex/Levenshtein evaluators, complex judgment via LLM-as-a-Judge scored 1–5 against a rubric; tracks variance across runs—high variance means an unstable prompt or rubric, not allowed into production
• Agent StudioConfigure multiple specialized copilots into a coordination network, using the ontology as a safe shared exchange medium, each agent with its own domain knowledge and operating permissions
• Object monitorsContinuously evaluate object state (stock below threshold, abnormal vital signs), auto-triggering notifications and actions when conditions are met—the sentinels of the "verb" system

Agent permissions aren't a separate scheme

• Inherited from the human user's or project's permission structure: data access is governed by the same security policies as humans
• Callable logic assets are permission-constrained, the scope of action can be precisely bounded, all activity enters the telemetry log
• Official scale for the Data–Logic–Action–Security four-way integration: real-time coordination of fine-grained policies for tens of thousands of humans and agents

From augmentation to automation: a dial, not a switch

Tampa General Hospital's three tiers: L1 data coordination ("patient-room-bed" unified operational twin) → L2 language interface (OAG natural-language query of live state) → L3 autonomous agents (monitor, draft, coordinate, alert—leaving only final approval to humans). The companion philosophy is "staged by default": actions are staged by default for human final review; as logs and operational data accumulate, the org gradually opens trusted, well-tested flows to the automated loop—the scope of autonomy scales up or down dynamically, changes take effect instantly.

Lock-in isn't a contract clause, it's an architectural property (three layers)

• The ontology can't run independently of Foundry—there's no mechanism to export and rebuild elsewhere
• Data must be materialized and integrated via Funnel—it can't merely be "referenced"
• Different ontology instances can't be linked—in a federated deployment, the supply-chain ontology's "supplier" can't connect to the finance ontology's "accounts payable"

Three honest statements

• The Hacker News jab "this is just object-oriented programming" actually nails the point—the value isn't theoretical novelty, it's depth of execution
• Going live isn't the finish line but the start: the model drifts with the business, and one change cascades across apps, functions, APIs, and agents—the day the ontology goes live is the day governance begins
• It's no silver bullet: in many scenarios, a lightweight schema plus prompt engineering is more worthwhile. Step back to see the whole elephant, so you don't mistake one leg for the elephant itself