Glossary Files
Glossary files define business-specific terms in plain English. They help the agent understand what users mean when they use terminology unique to your business or industry.
The glossary is not the place to define how metrics are calculated or which entity to query — that belongs in the entity YAML files, which are the source of truth for all data definitions. The glossary is purely about meaning in plain English.
Frontmatter
---
type: glossary
domain: "*" # or a specific domain name
---type
glossary
Identifies this as a glossary file
domain
"*", "default", "marketing", etc.
Which domain this glossary applies to
Entry Format
Each entry is a YAML key-value pair immediately below the frontmatter block.
---
type: glossary
domain: "*"
---
logo_churn:
term: Logo Churn
description: A customer who cancelled their subscription, counted as one regardless of their size. That means even a large enterprise counts as one churned logo, just like a small account.
at_risk:
term: At Risk
description: A customer we believe may churn. That means they are showing warning signs — low engagement, unresolved issues, or no recent activity.key (e.g., arr)
The lookup key — how the agent finds this entry
term
The human-readable term being defined
description
The definition — short, specific, and self-contained
Key naming: Snake_case is conventional (e.g., logo_churn, at_risk) but not required. The agent uses the term and description fields — the key is just an internal identifier.
Quoting keys with special characters: Keys containing %, +, or other special YAML characters must be quoted (e.g., "NPS%", "CTR%").
What Belongs in the Glossary
Terms that are specific to your business — words your users will type that have a particular meaning in your context, or that differ from their common industry definition.
Business-specific terminology:
Terms your company uses differently from the industry norm:
Status and segment labels users will reference:
What does NOT belong here: common industry terms with standard definitions (MRR, GMV, ROAS), metric calculations, and anything that should be defined as a metric on an entity YAML.
Domain-Specific Glossaries
You can scope a glossary to a specific domain. Named domains inherit from domain: "default" and can extend or override it. For the full inheritance model, see the Domains reference.
Best Practices
Only add terms specific to your business. If a term has a standard industry definition and you use it the same way, there's no value in adding it. Add it only if your definition differs, or if it's jargon unique to your company or industry.
Write plain English definitions. The glossary explains what things mean to a business user — not how they're calculated or which field to filter on. Calculations and metric definitions belong in entity YAML files.
Lead with the precise definition, then explain the reasoning. The first sentence should state exactly what the term means — the specific, unambiguous definition. The second sentence explains why it was defined that way, what it implies, or how it differs from a related term. This structure helps the agent understand both what to do and why, so it can apply the definition correctly in edge cases.
Don't be circular. A definition that says "NRR is net revenue retention" tells the agent nothing. Explain what the term actually means in your business context.
Configure your clarification policy for unknown terms. When a user references a term not in the glossary, the agent's behavior depends on your clarification policy. If no rule is configured, the agent may ask for clarification or attempt to interpret the term from conversation context. Add an explicit rule to your clarification policy for how the agent should handle unknown terms.
Common Pitfalls
Adding common industry terms. If everyone in your industry already knows what a term means and you use it the same way, adding it to the glossary adds no value. Only add terms that are specific to your business or that you define differently.
Circular definitions. "Logo churn is when a logo churns" tells the agent nothing. The definition should explain what the term means in plain English — not restate the term.
Relying on the glossary instead of defining a metric in the entity YAML. Including a calculation in a glossary description is fine if it helps a non-technical person understand the term. But it is never enough on its own. If a term has a precise calculation, it must also be defined as a metric in the relevant entity YAML — that is the source of truth the agent uses. The glossary is a dictionary for business users; the YAML is what the agent actually queries against.
Vague definitions. "A customer who uses the product a lot" is not a definition. Be specific about what the term actually means in your business.
Putting long explanations in the glossary. If a term requires more than two sentences, it belongs in a knowledge file. The glossary is a quick lookup — long entries dilute it.
When to Use This File
Add a glossary entry when a term meets one of these conditions:
It's specific to your business and wouldn't be understood by a general-purpose AI
Your company uses it differently than the industry standard
It's a status or segment label that users will reference by name
Examples:
"Our team uses 'whale' to mean our top strategic accounts" → add a business-specific term
"When users say 'active customer' they mean a paying customer, not a trial" → add a status definition
"We define 'conversion' differently — it means a trial upgrading to paid, not a click" → add a term your company uses differently
"The marketing team uses 'winback' constantly but it's not an industry-standard term" → add internal jargon the agent needs to recognize
"The product domain uses 'activation' differently than the marketing domain" → create a domain-specific glossary entry
When NOT to Use This File
If it's a metric definition or KPI calculation → entity YAML metrics (that's the source of truth for how to query the data)
If it's guidance on when to use an entity or metric → entity knowledge file
If it's a SQL pattern, filter, or field convention → task instructions file
If it's a data quality caveat or business rule → knowledge file
If it's a common industry term your business uses in the standard way → don't add it at all
The glossary is for plain English meaning. Everything about how data is structured, calculated, or queried belongs in the YAML files.
Full Examples
Example 1 — Grove (B2B SaaS)
Grove sells subscription-based software to businesses. These terms appear frequently in internal conversations and reporting — without them, the agent will interpret "logo" literally and confuse revenue churn with account churn.
Example 2 — Bly (E-commerce)
Bly sells consumer goods direct-to-consumer online. These terms reflect how the marketing and growth teams talk about customers — they differ from standard industry definitions in a few key ways.
Example 3 — Arcadia (Mobile gaming)
Arcadia is a casual mobile game monetized through in-app purchases. Gaming has industry-specific terminology where exact thresholds and edge cases matter. The cutoff between whale/dolphin/minnow, what counts as lapsed, and the precise definition of D7 all vary by company — without these entries, the agent will guess.
Last updated