What is a domain model?
A domain model is a structured, verified representation of a defined business domain. It gives people, systems and AI a reliable, shared understanding of how that domain operates.
"Domain" means a business area of any size: a whole organization, a department, or a narrow problem area such as work coordination.
The model has two parts. The first describes the business itself: its capabilities, accountability, operations and knowledge, whatever technology is in use. The second records the systems and data, what automation covers today and the gaps that remain.
A domain model is built from evidence: documents, interviews with the people who do the work, and the systems themselves. What cannot be confirmed is recorded as an assumption or an open question. It is not filled in from general knowledge.
The model describes the area as it is today and marks where automation could help. Strategy, process redesign and solution design start from it.
What does a domain model contain?
We decompose any business area along nine parallel structures.
| Structure | The question it answers |
|---|---|
| Capabilities | What the area must be able to do, whatever changes around it |
| Functions | Where the work is owned, managed and governed |
| Operations | How the work is performed |
| Knowledge | What people, systems or AI must know |
| Modeling | Which subjects of the area are formally represented |
| Systems | What technology records, integrates and executes the work |
| Data | What information the work depends on |
| Automation | What can be assisted, delegated or automated |
| Manual and automation gaps | Where automation is missing, partial or ineffective |
Five rules keep the structures useful:
- Separate and linked. "Customer Issue Resolution" is a capability. The process "Resolve Customer Complaint" and the CRM system are linked to it and stay separate objects.
- Business names, no vendor names. A capability is called "Customer Case Management", whichever product runs it. When the company replaces its CRM, the systems structure changes and the capabilities may stay as they are.
- Work first, org chart second. The same function sits in different boxes depending on company size. The structure follows the work, and the org chart is attached as evidence about one company.
- Knowledge apart from data. Data records information. Knowledge gives it meaning, rules and context. Documents and repositories are sources of knowledge.
- Evidence before a gap. Manual work is not a gap by itself. It becomes one when evidence shows delay, inconsistency, an avoidable dependency or weak control. Automation is one possible response among several.
Each diagram in the model carries a detailed text description, because AI reads text.
Domain model example
Our reference model of a hospitality business shows how one subject, the guest's stay, appears in each structure.
| Structure | Entry in the hospitality reference model |
|---|---|
| Capabilities | Accommodation Lifecycle |
| Functions | Rooms Division |
| Operations | Arrival and Check-In; Housekeeping and Room Turnaround |
| Knowledge | Guest and Accommodation Knowledge |
| Automation | Guest and Accommodation Automation |
The scope is stated as plainly as the content. The model covers commercial activity, the guest lifecycle, property operations and enterprise support. Property development, major construction and major renovation are excluded.
A narrow problem area is modeled the same way. Our reference model of work coordination covers how delegated work is defined, handed over, accepted, monitored, escalated and closed between people and AI. Planning, project management and the specialist work itself are outside it.
We keep reference models for hospitality, retail, software-as-a-service, consulting and small manufacturing businesses. Each is a starting hypothesis. For a specific company every element is confirmed, adapted or excluded.
Domain model vs operating model, process map, ontology and the software domain model
| What it describes | Where it pays off | |
|---|---|---|
| Domain model | How a business area works and how far it is automated | Strategy, requirements and architecture, and through them the code |
| Business capability map | What the business must be able to do | One of the nine structures of a domain model |
| Process map | How one piece of work runs, step by step | Redesigning a process for people and AI |
| Knowledge base | What the business knows, organized and owned | The moment AI does the work |
| Operating model | How the business is set up to run, today or in the target state | Deciding what AI executes and what stays with people |
| Software domain model | The concepts and rules of a problem domain, written for the people who build an application | Designing and coding that application |
The domain model comes first. The process map goes deeper into one of its processes, and the knowledge base fills its knowledge map.
"Operating model" has two uses. Inside a domain model, the operation model describes how the area runs today. In an AI Organization Strategy, the AI operating model is a design for the future: which work AI performs and which decisions stay with people.
An ontology is a formal, general scheme of what exists in a field. A domain model describes one business area in the words of the people who work in it. The formal entities and relationships it needs belong to the knowledge model.
Software teams use "domain model" for the concepts and rules behind one application, the meaning that comes from domain-driven design. A business domain model is wider and also covers accountability, operations, knowledge, systems and gaps. We borrow two ideas from that practice when we set the scope: the bounded context, a boundary inside which every term keeps one meaning, and the ubiquitous language the people in the domain share.
Why does AI need a domain model before automation?
A language model knows something about most fields. What it knows about a particular business area is contradictory and vague, and worse for niche fields. It fills the gaps itself and gives different results in different contexts. What it returns is a guess until the area is formalized.
A written description changes this. Used as context, it is a fixed baseline: outputs drift less from one context to the next, the work takes less effort and the quality improves.
More documents do not replace it. Knowledge of an area is scattered across documents, systems and people, and an agent that can read every document can still contradict principles that live only in people's heads.
An engineering leader told us the technology was not his obstacle. The hard part was modeling how a functional domain works, such as what accounting contains.
"Before automation" describes the order within one area. The first area modeled is the first one to be automated, and the rest of the company can wait.
How is a domain model built?
Our domain modeling process has seven activities. This is the build order of one model, not a rollout order for a company.
| Activity | What happens | What it leaves |
|---|---|---|
| 1. Scope definition | The sponsor confirms why the model is needed, its boundary, its depth and its later use | Scope definition, modeling profile |
| 2. Methodological research | The methods and standards of the field are researched, and the structure rules of the model are agreed | Methodology overview, structure principles |
| 3. Business structure | Capabilities and accountability are analyzed from the company's own materials | Organization structure model |
| 4. Operating context | Process documents are reviewed, and the people who know the area explain how the work is really done | Operation model |
| 5. Knowledge structure | The knowledge the work depends on is mapped with its sources, owners, rules and gaps | Operational knowledge map |
| 6. Current-state automation | Systems are cataloged with the people who run them, and workers describe what is still manual | Systems catalog, manual gap analysis |
| 7. Future-state blueprint | Validated gaps become automation opportunities and candidate agentic systems | Automation model, AI-native system blueprint |
Each activity ends with a review. AI summarizes materials and drafts each artifact. People validate, resolve assumptions and approve.
In the room, every activity starts from a draft. We ask a language model what it knows about the field, or start from a reference model, and read the draft aloud to the people who do the work. Then we walk the screens of the real system. In one session the screen said "appliances" and the database said "jobs", and the model records both terms.
The blueprint stays conceptual. It names the candidate systems, their boundaries and the points of human oversight. Prompts, interfaces and implementation plans belong to later work.
What does an AI-drafted domain model get wrong?
In one modeling session for a small repair business, we brought a draft built from the company's website and an AI session. The person who runs the business corrected it live. These are eight of the twelve kinds of correction.
| Kind of error | What the draft said | What the person corrected |
|---|---|---|
| Wrong starting point | The process starts at lead intake | It starts earlier, at lead generation |
| Wrong order | Collect the details, then explain the fee | Explain the fee first |
| Wrong rule | The service-call fee is waived if the repair goes ahead | The fee is collected and credited |
| Wrong word | The customer receives an invoice | A receipt, because payment is made on site |
| Wrong owner | The owner manages suppliers | The technicians do |
| Generic driver | Seasonality follows heating and cooling appliances | Seasonal residents leaving and arriving |
| Wrong boundary | Residential customers only | The class of appliance, set by access to parts |
| Missing altogether | Nothing | Complaints, payment collection, business customers, telephony, the team's messenger, missed calls |
Every line of the draft was plausible. The corrections are facts that sit with the people who run the work.
What keeps a domain model accurate?
Our method sets rules for what may enter a model, and the method catalog illustrates each rule with a case.
- Confirmed current state. A claimed integration between two systems is added only after system evidence or the person who runs the system confirms it.
- Traceable sources. An approval threshold in the model is linked to the policy section and to the interview that confirmed current practice.
- Visible uncertainty. A disputed system owner is marked "unconfirmed" with an open question. The most plausible name is not chosen.
- Documents compared with reality. A procedure says every contract exception goes to legal review. Interviews show that only high-risk exceptions do. Both are recorded, and the difference becomes a question for validation.
- Contradictions investigated. Two departments each say the other approves refunds. Investigation shows that one approves below a set amount and the other above it. The model records two bounded authorities.
- People decide domain truth. When an AI inference conflicts with the accountable process owner, the claim stays unresolved until the evidence is reconciled.
Four reviews carry the most weight: the capabilities, the functions, the operations, and the split of future automation into agentic systems. Nothing later is built on any of them until it is approved.
How wide should a domain model be?
The process has three outcomes, and the choice sets the boundary.
| Model | Boundary | Adjacent areas |
|---|---|---|
| Organization model | The whole organization and its cross-functional relationships | Outside the company |
| Department model | One department | Treated as interfaces, inputs and outputs |
| Problem area model | One problem and its outcomes, across org-chart lines | Left out unless the problem touches them |
An organization model feeds the AI strategy. Narrow models feed process definition, knowledge work and automation. A model starts broad and shallow and is deepened in the areas picked for automation.
Whatever the width, the boundary has an entry event, an exit state and named exclusions. In one modeling session for a training-development department, the entry event was a request to develop a training. The exit state was a training ready for delivery. The delivery itself and the planning of the training portfolio were excluded.
A model is also maintained. A new model runs the full process. An update reuses what was approved and revalidates only what the change touches.
Who takes part in domain modeling?
On the company's side the sponsor, the process owners, the people who know the subject and the owners of the systems and the knowledge take part. The people who do the daily work are interviewed about what is still manual.
Four decisions stay with them, and the process does not infer any of the four:
- The scope of the model and what it will be used for.
- The current organization structure and who is accountable for what.
- How the work is really performed, where documents and practice differ.
- Which systems and technologies are in use.
On the modeling side there are six roles.
| Role | Responsible for |
|---|---|
| AI strategist | Scope, boundaries, modeling profile |
| Business analyst | Methods, capabilities, functions, the organization structure model |
| Process analyst | Operating evidence, interviews, the operation model |
| Knowledge analyst | Knowledge analysis, the knowledge map |
| Enterprise architect | Systems catalog, manual gap analysis |
| AI architect | Automation model, agentic systems, the blueprint |
In a small engagement one person may hold several roles, and the responsibilities stay separate. Each role works with its own AI assistant, which drafts while the person decides.
How EIC models a domain
A finished model is eight documents: the scope definition, the organization structure model, the operation model, the operational knowledge map, the business systems catalog, the automation model, the manual gap analysis and the conceptual blueprint.
The rest of the work starts from these documents:
- Strategy. In AI Organization Strategy the same method covers the whole company. The organization model is the first deliverable, and the AI-native blueprint and the phased roadmap are built on it.
- Process engineering. Each area picked for automation gets a process definition. AI Process Reengineering maps the real workflow with the people who run it and turns it into a goal-oriented reference process.
- Knowledge engineering. AI Knowledge Base derives the knowledge model from the knowledge map and the process definitions, and gives each area an owner.
- Skills and agents. Skills, assistants and agents come after the process and the knowledge are defined.
The model also keeps bottom-up automation orderly. With a known slot for every piece, a quick automation built by one team can later be rebuilt or connected without breaking anything.
One area is enough to begin, and the first model carries over to the next. Short answers on process mapping and the goal-oriented reference process are in the FAQ on the AI Process Reengineering page.
