Enterprise
It covers the systems a whole organisation relies on, not one screen or one report.
What is an ESDM
What is an Enterprise Semantic Data Model?
A map of what your systems mean, in plain business language, with proof for every fact.
Systems nobody fully understands
Every organisation runs on software systems: for orders, payments, customers and suppliers. Over the years these systems grow, change hands and collect layer after layer of changes. In most organisations today, no single person understands a whole system.
The knowledge still exists, but it is scattered. Some of it is in business requirement documents, some in functional specifications, API documentation, process diagrams and the code itself. A large part lives only in the heads of a few long-serving experts.
This matters more now than ever, because AI assistants and agents need the same understanding. An AI can read a database, but if it doesn’t know what the data means, it guesses.
What an ESDM is
An ESDM, or Enterprise Semantic Data Model, is a map of what an organisation’s systems mean.
It describes the business things a system deals with, how they connect and which rules apply, in plain business language. It also records exactly where each of those things lives in the real system.
The name, word by word
Semantic
It is about meaning. “prch_ordr is a material request” is a semantic fact.
Data model
It is structured, so both people and software can read it.
A map and a translator in one
A city map doesn’t replace the streets, but it lets a newcomer find their way without walking every road. In the same way, the model lets anyone find their way around a system, from a new analyst to an AI agent, without reading every document.
Why it’s called SemanticTwin
The model is a digital twin of the system’s meaning: it mirrors what the system knows, in a form everyone can use.
Video
Watch: ESDM, explained
A video overview: understanding your systems with SemanticTwin.ai.
What’s inside a semantic model
A semantic model is built from seven kinds of building block. The examples come from a procurement system, where a buyer requests building materials, sellers quote, and the accepted quote becomes a purchase order.
Business things
The nouns of the business
ExampleMaterial request, quote, purchase order, seller
Details
What we record about each thing
ExampleA request’s reference number, total amount and status
Connections
How the things relate
ExampleA purchase order comes from a material request
Rules
What must or must not happen
ExampleOnce a seller submits a quote, its prices can’t be edited
Life stages
The steps a thing moves through
ExampleA request goes from new, to quoted, to negotiated, to ordered, dispatched and closed
Links to the real system
Where each thing is stored
Example“Material request” is stored in the table prch_ordr
Proof
What makes it trustworthyWhere each fact came from
ExampleThe exact sentence in the requirements document, or the line in the database schema
The last block is what makes the model trustworthy. Every fact carries its proof, so anyone can check it instead of taking it on faith.
Why it’s hard to build one by hand
Organisations have wanted models like this for years, but building one by hand is slow, expensive and fragile. Seven things make it hard:
- The knowledge is scattered. Requirements documents, functional specifications, API documentation, process diagrams, database schemas and code each hold a piece of the story, and no single one holds all of it.
- Each source speaks a different language. The business says “material request”, the database says
prch_ordr, and an API may use a third name for the same thing. - Sources contradict each other. A requirements document may call a quantity a whole number while the database stores decimals. Someone has to notice, then decide which is right.
- Documents go out of date. Documents often describe what was planned; the code and the database show what was actually built.
- Some knowledge was never written down. It lives with a few experts, and it leaves when they do.
- The scale is large. A real system can have hundreds of tables and thousands of fields.
- It needs rare skills and a lot of time. Data modellers can spend weeks or months on one system, and the system keeps changing while they work.
The result is that most organisations either never build the model, or build one that is out of date and that nobody fully trusts.
Key takeaways
- Every organisation’s systems hold knowledge that nobody can see all at once.
- An Enterprise Semantic Data Model is a map and a translator: the business meaning of a system, its connections and rules, linked to where the data really lives, with proof for every fact.
- Building one by hand is slow and expensive, and it goes out of date while it is being built.
- SemanticTwin.ai builds it from the documents and code you already have. The software does the reading and matching; your team makes the decisions.
- The result is a model that people and AI can both trust, and it opens up a long list of uses, from AI agents to documentation to compliance.
Frequently asked questions
Is an ESDM the same as a database schema?
No. A schema says how data is stored: tables, columns and types. An ESDM says what that data means to the business, how things relate and which rules apply. It also links each meaning back to the schema.
Is it the same as a knowledge graph?
A semantic model can be expressed as a knowledge graph. SemanticTwin shows it as one in its Knowledge Graph view, and exports it in standard graph formats: Turtle, JSON-LD, RDF/XML and N-Triples.
How is it different from a data catalogue?
A data catalogue lists data assets. A semantic model also captures connections, rules and life stages, with proof for each fact. SemanticTwin generates a data dictionary from the model, so you get both.
Who uses it?
Business analysts, architects, developers, data teams, compliance teams, and AI agents.
See your system clearly.
Watch SemanticTwin.ai build a semantic model from real documents.
Book a demo