Ontological Thinking: Designing the Knowledge Layer

You’ve argued that design should own the knowledge layer. Here’s what doing that work actually looks like.

ChatGPT generated image

In a previous article, I argued that the knowledge layer — the structured representation of entities, relationships, and constraints that determines what an AI system can understand — belongs to design, and that we have systematically given it away. Designers are excluded from knowledge-structure decisions not by deliberate choice but by organizational default. The cost of that exclusion is silently absorbed by systems that handle their domains rather than understand them. That argument was about ownership. This one is about the work.

If you agree that designers should be in the room when knowledge structures are built, the immediate next question is: what do you actually do when you get there? What is the design practice for this layer? What does a knowledge layer artifact look like, and how do you produce one? This article addresses those questions directly.

Consider this scenario: a design team at a mid-sized financial institution has been iterating on its AI-powered client-servicing platform for six weeks. Users keep reporting the same complaint: the system “doesn’t understand what I need it to do.” The team runs usability sessions. They simplify the prompts and restructure the interface to surface more guidance. They even add a tooltip explaining what kinds of requests the system handles; however, the complaint persists.

Eventually, a data scientist on an adjacent team pulls up the entity taxonomy underlying the system’s reasoning. She finds it almost immediately: “client” and “counterparty” have been mapped as synonyms, thereby treating the two words as the same type, with the same attributes and routing logic.

In the Treasury domain, they are not the same. A client is a firm that the institution serves, with a relationship manager, a KYC profile, and a credit facility. A counterparty is an entity with which the institution transacts and that is subject to a different regulatory framework, risk classification, and access constraints. The two categories share almost nothing except that both appear in the institution’s systems.

The AI was not confused; it was executing correctly on a flawed knowledge structure. The entity model had been built by an engineer who understood the data pipeline but had neither the domain expertise nor any design input. The design team was never in the room when it was built, and weeks of UI iteration couldn’t compensate for a classification decision made in a data modeling session.

This is the knowledge-layer failure mode that design is best positioned to prevent — and unfortunately, the one most designers have no framework to catch.

Three Failure Modes with a Common Cause

Classification errors like the one above are not edge cases. They are the predictable result of building a knowledge structure without design input. Three failure modes appear repeatedly in AI products built without knowledge layer design input:

Category collapse. Two distinct domain concepts are mapped to the same entity type because they share surface features: both appear in the same database table, use similar vocabulary, and are referenced in the same workflows. The system treats them as equivalent, but the domain treats them as categorically different. Every interaction the system has with either concept inherits this error.

Relationship blindness. The entity types are present, but the relationships between them are undefined or underpowered. The system knows what exists, but not how things connect. It can answer “who is this client?” but not “what obligations exist between this client and this counterparty?” It can identify a regulatory scenario but cannot trace the chain of entities implicated in it. The knowledge is present but in pieces, and understanding requires understanding how they connect.

Constraint absence. The system knows what is possible but not what is permitted. It can identify paths through the domain, such as this entity type, this relationship, this outcome, but has no specification of which paths are restricted, which require escalation, and which are prohibited entirely. Constraint design is knowledge layer design, and without it, the system explores the full space of what’s possible rather than the bounded space of what’s allowed.

None of these failures manifests primarily at the interface layer. They manifest in system behavior with outputs that feel wrong, recommendations that miss obvious domain logic, and escalations that the user expected the system to handle. The UX team inherits the symptoms of the upstream cause.

The Knowledge Layer Design Brief

Each of these failure modes has a design solution, not a technical one. The work is structural: defining what exists in the domain, how things relate, and what the system is and is not permitted to do with that knowledge. The artifact that captures this work is the Knowledge Layer Design Brief, a structured specification of the domain model from which the AI system will reason.

A complete brief addresses five questions:

What are the key entities in this domain? Named, defined, and distinguished from similar entities that the system might otherwise conflate. The definition should be precise enough to answer the entity-type classification question for any input the system will encounter.

What attributes characterize each entity? The properties that the system uses to distinguish instances, determine category membership, and route behavior. Attribute design is where domain expertise translates into system knowledge.

What are the critical relationships between entities? Named relationships with direction, cardinality, and significance. The relationship between a client and their relationship manager, between a transaction and the regulatory body that governs it, and between a risk flag and the escalation path it triggers.

What constraints govern those relationships? Which relationships are restricted, which require human review, and which are prohibited? Constraint design is the knowledge-layer equivalent of confidence-boundary design — it defines where the system must stop and defer.

Where does the knowledge boundary sit? The explicit limit of what the system knows with sufficient confidence to reason from autonomously. Beyond this boundary, the system must acknowledge uncertainty or escalate. It’s not a technical threshold; it’s a design decision.

The brief need not cover the full domain to be useful. A partial brief that covers the highest-stakes entities and their most consequential relationships is more valuable than no brief, and more honest than a knowledge structure built by inference.

Getting into the Room

Most designers working on AI products are not currently involved in knowledge structure decisions. The brief for this work has not been formally assigned to design, and in most organizations, the people building the knowledge structure are not sure what design would contribute. These entry points are practical.

Find the entity. Building any AI product requires defining its foundational concepts and the specific entities the system must understand. Secure a seat in data modeling and schema design meetings. Your contribution is not technical execution, but domain rigor and forcing the room to answer: “What does the user actually mean?” and “How does the business functionally distinguish these cases?”

Run a synonym audit. Hunt for knowledge-layer risks: identical terms with conflicting meanings, or disparate words that mask the exact same concept. Every ambiguity requires a structural fix. If a term shifts in meaning based on context, define a classification rule to distinguish between them. If multiple terms overlap, define a normalization rule to establish equivalence. Documenting both is your entry point for controlling the knowledge-structure conversation.

Define one entity completely. Do not propose a Knowledge Layer Design Brief as a new process; demonstrate it. Isolate the most consequential entity in your product — the one where misclassification carries the highest risk. Write its definitive record: its exact attributes, its relationships to adjacent entities, and the strict constraints binding those relationships. Deliver this to the data science team. The artifact forces a concrete conversation.

Document the first known gap. Expose the friction between system architecture and user reality. Pinpoint exactly where the system’s knowledge structure fails the user’s mental model — whether it conflates two distinct concepts, leaves a relationship undefined, or misses a critical constraint. Log this as a formal design gap and assign strict ownership for the fix. This is your first knowledge boundary record, and the foundation of accountable knowledge layer design.

The Brief Is the Claim

Design’s absence from knowledge-structure decisions is an organizational habit, not an inevitability. The previous article established how designers can build the vocabulary and the mandate to secure a seat in those rooms. This article is the blueprint for what you do once you are inside.

The Knowledge Layer Design Brief is a structural mechanism, not a complex artifact. It is five structured questions answered in writing, with named owners and documented constraints. A practitioner can draft a functional baseline in a single working session. A complete version — mapping all critical entities, relationships, and constraints — scales with the domain: as long as the subject matter is complex and the stakes are high.

The primary shift is accountability. When a knowledge structure emerges from informal data modeling, classification decisions are unowned and invisible. A Knowledge Layer Design Brief forces the opposite: making every structural decision visible, attributable, and correctable before it hardens into the foundation.

The synonym audit, the entity definition, and the constraint specification are not new tasks for anyone grounded in information architecture. You are answering the same questions, but for a different consumer: the AI system itself. Everything the model understands about the domain — and everything it fails to grasp — is strictly bound by the precision of this work.

Practitioners who master this artifact will build systems that actually understand their domains. Those who do not will continue inheriting interface failures rooted in data-modeling sessions upstream — in rooms no one invited them to attend.