Data dictionary · Context for AI · ERP
The data dictionary: the document that makes Claude and ChatGPT understand your company
An open-format data dictionary explains what every entity and field in the ERP means in your business. It is the context assistants and AI agents need so they stop making things up.
Ask an AI assistant connected to your ERP what the margin of project X was last quarter. It will find a table called projects, another called entries, a field type with values 1, 2 and 3, and it will answer with confidence. The answer has a good chance of being wrong, not because the model is bad, but because nobody told it what “project”, “margin” and “type 2” mean in your company.
The document that solves this has an old name and little glamour: the data dictionary. It is the core deliverable of the Data mapping Koltren provides, and it is what separates an AI that helps from an AI that makes things up.
What it is (and what it is not)
A data dictionary is the description, in business language, of every relevant entity and field in the company: what it means, where it comes from, which values are valid, who owns it and which rules apply.
It is not the database schema. The schema says type is an integer. The dictionary says type = 2 is “measurement approved by the customer”, that it can only exist after a type = 1 measurement, and that finance owns that rule.
It is also not the ERP manual. The manual explains the screen. The dictionary explains the business the screen represents, including the parts the company adapted its own way.
What goes in
In a typical mapping, the dictionary covers:
| Block | What it describes | Example |
|---|---|---|
| Entities | What exists in the business | Project, supplier, measurement, requisition |
| Fields | Meaning, format, valid values | Measurement status: draft, sent, approved, invoiced |
| Rules | What must not happen | Payment before an approved measurement |
| Synonyms | What each area calls the same thing | Project = job = cost center 3xx |
| Sources | Where the data is born and where it flows | Born in the field app, enters the ERP through the nightly integration |
| Owners | Who answers for the definition | Finance answers for “margin” |
| Examples | Real, anonymized cases | A full measurement, from draft to invoice |
The examples are what helps a language model most. An abstract definition is ambiguous; a concrete example is not.
Open format, readable by people and by models
The dictionary we deliver is text: Markdown with structured YAML blocks, versioned in a repository. No proprietary tool, no license, no lock-in.
That matters for three reasons:
- Any model consumes it. Claude, ChatGPT, your ERP’s own agent or an open model running inside the company receive the same file as context.
- Any person reads it. The new analyst understands the business in an afternoon. The auditor finds the rule they are looking for.
- It can be versioned. When a rule changes, the file changes, and the change is recorded with date and author.
How it is used
Once ready, the dictionary becomes the context layer for everything that reads the data:
- AI assistants receive the dictionary as context and stop inventing the meaning of fields.
- Agents use the rules to propose actions with judgment: holding a payment without an approved measurement, for example, instead of just listing payments.
- BI and reports switch to the canonical name, and the manager stops keeping the parallel spreadsheet.
- Integrity signals run every day on the dictionary’s rules and raise a flag when something drifts. See the most common ones in Seven signs your ERP data is not ready for AI.
How to keep it alive
A dictionary that never changes is dead. Three habits keep it alive: every new rule is born in the dictionary before it goes into the system; every question about a field is answered in the dictionary, not in chat; and one person owns the document, with a quarterly review. In AI implementation, the agent itself helps, pointing out fields it could not interpret.
If your company already tried Claude or ChatGPT on the ERP and ran into wrong answers, the data dictionary is usually what was missing. Koltren builds yours in Data mapping; the diagnostic call is the first step.