← All writing

Essay

Ontology Factory

More context is not the same as better context. An ontology makes meaning, evidence, ownership, and permitted action explicit.

A system can retrieve every document containing customer and confuse the purchaser, user, and caller. More documents preserve that ambiguity; they do not resolve it.

An ontology factory makes the choice explicit: which concepts the product recognizes, how they relate, what evidence supports a claim, and which actions that claim permits.

Core thesis

More context is not the same as better context. Better context has a map.

01

AI Needs a Map, Not a Larger Pile of Documents

Retrieval finds relevant material but cannot decide which local meaning controls a decision. Conversation may mean a transport session, two humans speaking, or an interaction spanning transfers. A model can surface all three and build against the wrong one.

An ontology distinguishes the contract owner from its user, states the evidence for each role, and preserves uncertainty. Retrieval can then assemble the relevant map instead of treating every nearby sentence as authoritative. The goal is selective context, not a larger prompt.

02

A Map Is a Commitment, Not a Mirror

Here is a practical working definition:

A product ontology states which distinctions the system will recognize, how they relate, and what evidence is sufficient to make claims about them.

The factory's ontology is not a description of what its repository happens to look like. A formal ontology may span schemas, APIs, policies, types, tests, and prose. The important move is making its commitments reviewable.

A hospital, insurer, and patient may model an encounter differently because decisions differ. Visible boundaries make them compatible.

An owner decides when evidence changes a state, a distinction fails, or an action exceeds its authority. Human judgment keeps the map useful; the ontology makes it testable.

03

The Smallest Useful Ontology Packet

A useful minimum has six parts:

PartQuestionTypical expressions
VocabularyWhich terms do we use, and which apparent synonyms must stay separate?Definitions, aliases, naming rules, prohibited conflations
Entities and relationshipsWhat exists in this model, and how can those things connect?Schemas, graphs, types, identifiers, cardinalities
States and invariantsWhat may change, and what must remain true?State machines, constraints, validation rules, tests
EvidenceWhat warrants a claim, and how certain is it?Events, provenance, observations, confidence, timestamps
Actions and permissionsWhat may follow from the claim, who owns the decision, and when must work escalate?Policies, capabilities, approvals, exception paths
Examples and evaluationsWhat counts as an ordinary case, a boundary, a counterexample, or a successful outcome?Fixtures, scenarios, acceptance tests, observed consequences

Together they form one semantic contract. Vocabulary without relationships is a glossary. Entities without evidence turn populated fields into truth. Evidence without permissions becomes authority. Actions without evaluation cannot improve. The packet may span prose, graphs, types, policies, and tests, provided those artifacts point to the same distinctions.

04

Boundaries and Ownership Prevent Semantic Slop

Bounded contexts let teams use one word differently. Terms remain stable inside each context; translation is explicit at the boundary.

Repository structure can expose those commitments. Consider this path:

libs/edge/audio/state-zustand-player

In SoundSculpt, each segment carries meaning: reusable owner, product-facing layer, audio capability, and reactive player-state responsibility. The path is an ownership claim, not merely an address.

AI Factory · 05a · Repository ontology / identity

A path maps and identifies an owned library

Scroll the path →

A path maps and identifies an owned libraryA repository path composes a library boundary, architectural layer, domain vocabulary, and implementation details into one semantic identity, then points people and agents to the accountable change destination.PATH IDENTIFIER · FOUR COORDINATESBOUNDARYlibs/LAYERedge/DOMAINaudio/DETAILstate-zustand-playerBOUNDARY · REUSABLE LIBRARYLAYER · EDGEcross-cutting product-facing position in the dependency stackDOMAIN · AUDIOTerms of art shape the user experiencePLAYERSOURCECHROMELEAF + OWNER CONTRACTTECH · HOWZustandTOOL · WHATplayer storeFEATURE · WHYplaybackOwned librarychange destinationpublic API + contract
The path supplies the stable coordinates: library boundary, Edge layer, Audio domain, and a player-state responsibility. The leaf contract completes the map: Zustand is the technology, the player store is the tool, and Playback is the consuming feature. Together these coordinates identify the public owner and show where a change should begin.

A layer can do more than locate the owner. It can select what belongs in that part of the stack and how the work is built, instrumented, and proved. Edge work requires product-facing integration, integration tests, and PostHog and Sentry wrapping. Schema work generates TypeScript interfaces from the database contract. Engine work pairs deterministic logic with unit tests. Skills and tool calls apply these rules automatically.

AI Factory · 05b · Repository ontology / construction

Layers make construction rules executable

Scroll the path →

Layers make construction rules executableThree repository layers select both what should be built and how it should be verified or instrumented. Edge maps to product integration, integration tests, and PostHog and Sentry wrappers; Schema maps to typed database contracts and generated TypeScript interfaces; Engine maps to deterministic domain logic and unit tests. Skills and tool calls apply each contract automatically.LAYER CONTRACTS · SELECTED EXAMPLESLAYER 01Edgeproduct-facingWHATIntegration boundarypublic API + adapterHOWIntegration testPostHog + Sentry wrappersSkill + tool callsapply the contractLAYER 02Schemadata authorityWHATTyped DB contractcanonical schema + typesHOWGenerated TS interfacederived from the databaseSkill + tool callsapply the contractLAYER 03Enginedeterministic logicWHATDomain enginerules + transformationsHOWUnit testsfast behavioral proofSkill + tool callsapply the contract
A layer is not only a position in the dependency stack. It selects a build contract: what belongs there, which proof is required, and which tooling is applied. Edge work receives product-facing integration, integration tests, and PostHog and Sentry wrappers. Schema work turns database structure into generated TypeScript interfaces. Engine work pairs deterministic domain logic with unit tests. Skills and tool calls apply these contracts automatically while ownership remains explicit.

A README defines scope. An AGENTS contract governs work and verification. A skill supplies a specialized procedure. Their authority remains separate.

For each task, the factory dynamically composes the relevant owners, rules, and procedures within the agent's context budget. Selection changes what it holds, not which contract governs.

AI Factory · 05c · Repository ontology / operation

Contracts compose context for bounded action

Scroll the path →

Contracts compose context for bounded actionFor each task, the README, AGENTS file, and applicable skill remain distinct sources. Their relevant constraints are dynamically composed into context that fits the agent's available budget, governs action, and can be evaluated.THREE CONTRACTS · THREE DISTINCT JOBSREADMEWhat is this scope?purpose · boundaries · ontologyAGENTSHow may work proceed?workflow · verification · invariantsSkillWhich procedure applies?specialized · reusable · situatedDynamic contextselected for the taskfits the agent's context budgetscope + rules + procedureAgent actionauthority remains explicitObserved outcomeevidence can revise the map
Context is assembled for the task, not copied as a static document bundle. Scope, operating rules, and procedure remain distinct; the relevant parts are selected to fit the agent's context budget. That context bounds action, keeps authority explicit, and preserves outcome evidence that can revise the map.

A stable identifier finds the owner. Typed relationships constrain dependencies. Contracts route work. Procedures perform it. Evaluation tests the original commitment. Without those boundaries, generated work becomes semantic slop: polished and executable, but wrong in meaning.

05

Two Examples Make the Cost Visible

An ontology matters when confusing concepts changes behavior. Mango must split events ordinary language compresses. SoundSculpt must preserve relationships a simple object model would flatten.

Mango: a protocol answer is not a conversation

“When an answered call ends, send the customer a follow-up” sounds precise, but answered may mean a provider connection, voicemail, human participation, or a Mango-defined conversation. SIP sessions and successful responses establish technical facts, not that two humans spoke. Answering-machine detection adds a fallible classification that may remain unknown.

Mango therefore needs an evidence hierarchy rather than one overloaded call record:

call attempt → session or dialog established → machine, human, or unknown classification → sufficient evidence of human participation → Mango-defined conversation

Each arrow requires evidence and a product rule. Transport observations say what happened; product claims say what Mango may conclude. Permissions attach to the justified state, so ambiguity can delay, escalate, or prevent action.

Music presents the opposite risk: flattening a work, its realizations, and its reception into one object.

SoundSculpt · relationship map

One creative object becomes several related claims

CompositionPerformanceProductionRendered Sound

Rendered Sound

  • observable acoustic characteristics
  • product-specific timbre assessments
  • contributes to perceived mood

Perceived Mood

  • depends on rendered sound
  • depends on listener
  • depends on context

Rights & Attribution

  • relates people and works
  • relates recordings and uses
  • depends on territory and conditions
Each claim belongs to the relationship that makes it valid; none is an intrinsic field on a single object.

Copyright law distinguishes a musical work from its sound recording. Timbre research treats perception as multidimensional. SoundSculpt can therefore attach a timbre assessment to a rendered sound, while perceived mood remains a relationship among rendering, listener, and context. The ontology locates each claim where it becomes valid instead of forcing every quality into an intrinsic field.

Controlled language helps after the model exists

ASD-STE100 Simplified Technical English constrains vocabulary and usage. A six-task 2026 experiment reduced mechanical rule violations but did not measure factual correctness, completeness, or safety. Controlled language clarifies claims; it cannot decide what answered or mood refers to. The factory needs a sound model and clear expression.

06

The Ontology Learns from Use

An ontology that never changes is a museum. A working ontology participates in the same loop as the product:

observation → ontology commitment → assembled context and implementation → evaluation → counterexample or consequence → revision

New distinctions change schemas, interfaces, tests, prompts, and policies. Observations expose missing states, weak evidence, or absent authority. Revision versions terms, identifies owners, migrates dependents, and preserves provenance.

Tests check consistency; review challenges distinctions; consequences test permitted actions. Together they enable correction. The factory's product is not a perfect map, but a governed way to revise it.

The Cognitive Factory uses this map to interpret signals, connect history with current priorities, and discover the context a decision needs. Shared definitions make that memory usable across people, agents, and organizational boundaries.

07

Sources