# Business Glossary

> Every term in your model with its definition, physical name, domain, and where it is used — derived from the model instead of maintained as a separate document.

A business glossary answers a different question than a schema does: not
"what columns exist" but "what do we mean by this word?" In Sqemo it is
not a document you maintain next to the model — it is the **Glossary** view,
derived from the logical model every time you open it.

Switch the view with the selector in the toolbar: **Logical · Physical ·
Naming · Glossary · Domains**. It is part of the free core and works on
local files with no account.

## What becomes a term

A term is a logical attribute name. If ten entities have an attribute
called "Customer Number", the glossary has one row for it, listing all
ten places.

- Matching trims and collapses repeated spaces and ignores case, so
  "Order Date" and "order  date" are the same term. Spacing itself is
  meaningful — "Order Date" and "OrderDate" are two different terms.
- Attributes derived from a foreign key are skipped, because they repeat
  the parent's term. If the foreign key has a **role name**, that name is
  the term instead.
- Attributes with an empty logical name are skipped.

Each row shows the term, the physical name generated for it, its domain,
data type, definition, every entity it is used in, and a status column
for conflicts.

## Definitions live on the model

Click the definition cell and type. Saving writes the definition to every
logical attribute carrying that term, so a term has one definition per
ERD — that is the whole point, and it is why the definition cannot drift
from one entity to the next.

Nothing new is stored: the definition is the attribute's own description
field. It travels in your `.erd.json`, which means it is diffable in git,
readable over [MCP](/docs/mcp/), and included in an entity or column
definition export.

The scope of a definition is the ERD. The same word can mean different
things in two different models, and here it is allowed to — the model is
the context.

## Conflicts get flagged, not hidden

Two badges appear in the status column:

- **Definition conflict** — attributes sharing the term carry different
  non-empty definitions. The row shows the first non-empty one; editing
  the cell unifies them all (undo works as usual).
- **Domain conflict** — the same term resolves to a different domain or
  data type depending on the entity. The glossary flags it; fix it by
  assigning the domain in the inspector.

These are the rows to clean up before anyone asks you for a glossary
document — the conflicts are the drift, made visible.

## Jump to where a term is used

The **Used In** cell lists the entities using the term. Click one to
switch to the logical view with that entity selected and focused on the
canvas.

Audit columns like `created_at` or `updated_by` sit on nearly every
entity, so the cell shows the first five and folds the rest behind a
**+N more** toggle. Expand it to reach any of them — nothing is dropped.
While a search is active, matching entities move to the front so the row
always shows why it matched.

## Export for an audit

Toolbar ▸ **Export ▸ Export glossary (CSV)** writes one row per term:

```
logicalTerm,definition,physicalName,domain,dataType,entities,conflicts
```

`entities` and `conflicts` are `;`-separated. A row with a non-empty
`conflicts` value is a term that still needs a decision.

There is no term import. The glossary is a view over the model, not a
registry you load into — the words that generate physical names are
imported in the [word list](/docs/naming-standards/), and the terms
follow from the model that uses them.

## Three dictionaries, one model

Sqemo keeps three: the **word list** (how each word becomes a
physical word), the **business glossary** (what each business term means),
and **domains** (the type and length a term resolves to). That split
comes from ISO/IEC 11179, where a data element's name and its definition
belong to the same registry entry rather than to separate systems. For the
longer argument, see
[Data Dictionary vs Business Glossary](/blog/data-dictionary-vs-business-glossary/);
for what the standard specifies and where it stops, see
[ISO 11179 Naming Conventions](/blog/iso-11179-naming-convention/).

## Sharing and team standards

On a read-only [shared link](/docs/collaboration/) the Glossary view is
visible but definitions cannot be edited.

Unlike words and domains, definitions are **not** locked while a project
is connected to a team standard. Words and domains are a cached copy of
the standard; a definition is your project's own data, so you can keep
editing it whether or not the project is linked.

---
Source: https://sqemo.com/docs/business-glossary/ · Updated 2026-08-02