Blog
Lexicon: what things are called and what they mean
The lexicon is the vocabulary of a governed data product — the canonical names and definitions for every entity and field. Here’s what it is, how it’s made, and why it matters.
What it is
A lexicon is the set of terms your governed data product uses and what each one means. It includes the names of entities (e.g. Order, Customer, Shipment) and the names of attributes or fields (e.g. revenue, status, created_at), plus a clear, business-level definition for each. Without a shared lexicon, “revenue” in one system can mean GAAP revenue while in another it means billed amount — and there’s no single place to look. The lexicon is what gives every field and entity a stable, agreed meaning so humans and AI interpret data the same way.
How it’s made
In practice, a governed data product lexicon is built and stored in three connected ways:
- Schema-level definitions. When you define or ingest the asset’s schema (e.g. JSON Schema, table DDL), each field gets a canonical name and a description. That description is the start of the lexicon — e.g.
revenue→ “Total order value after discounts, in the order currency. Excludes tax and shipping.” - Business glossary linkage. Terms can be linked to a central business glossary so the same definition is reused across assets. For example, “customer_id” might point to the glossary entry “Customer identifier: unique, stable ID for a customer in the source system.” That way the lexicon is consistent across governed data products.
- Ownership and stewardship. Lexicon entries are usually owned by a domain or data owner. When the business meaning of a field changes, the definition is updated in one place and the asset’s schema or metadata is versioned so consumers know what “revenue” meant at the time they queried.
Concretely, you’ll see something like this for an Orders governed data product:
{
"entity": "Order",
"fields": [
{
"name": "order_id",
"type": "string",
"definition": "Unique order identifier from the source system (e.g. Shopify order ID). Immutable."
},
{
"name": "revenue",
"type": "number",
"definition": "Total order value after discounts, in order currency. Excludes tax and shipping."
},
{
"name": "status",
"type": "string",
"definition": "Order lifecycle status: draft | placed | paid | fulfilled | shipped | delivered | refunded | cancelled"
}
]
}The lexicon is stored as part of the governed data product’s metadata (e.g. in the asset’s definition in the catalog or in the schema registry). When you publish a new version of the asset, the lexicon is versioned with it so lineage and consumers can refer to “revenue as defined in v2.”
Why it matters for governed data products and AI
A governed data product without a lexicon is just a table with column names — ambiguous and hard to use across teams and tools. With a lexicon, search and discovery can match on definitions (“find assets that contain revenue”), and AI can interpret field meanings instead of guessing. In Loxtep, the lexicon is part of every governed data product so the context we serve to your systems and AI is semantically clear.