Business metadata explains what data means in business terms. It tells AI which fields identify an entity, which describe it, which are searchable, which relationships apply, and which dimensions control visibility.
Why it matters
Raw system fields (company_id, AccountNumber, FileRef) do not tell AI what business concept it is working with. Business metadata turns technical payloads into business context — the foundation of Enterprise Knowledge.
How it works
Metadata is defined when integrations are modeled:
- Resource type — what business entity this data represents (customer, contract, document)
- Field mappings — which system fields map to business attributes
- Search and display — which fields AI and users can query and show
- Relationships — links to other business entities
- Dimensions — boundaries for access and visibility
Developers configure metadata during external system and datasource setup; the platform applies it consistently across search, capabilities, and Role Assistant context.
Metadata and AI trust
Agent metadata trust certification checks that attributes, resource types, and exposed schemas are complete enough for AI — without calling vendor APIs during the trust pillar. Incomplete metadata forces prompt-heavy, inconsistent worker behavior.
Searchable vs display-only fields matter for UX and compliance: architects standardize which attributes may appear in AI-generated summaries.
Lifecycle
Metadata changes when vendors add fields or business definitions evolve. Treat mapping updates like schema migrations — re-validate, re-run trust certification, and communicate scope to operators.
Standard attribute names across systems (customer name, owner, region) reduce duplicate governance rules and simplify Role Assistant training.
Working across systems
The same business concept often appears in CRM, ERP, and document libraries with different field names. Enterprise Knowledge standardizes resource types and attribute labels so Role Assistants see one customer story — not three incompatible schemas.
Architects publish a small metadata glossary (customer, contract, case, document) before integrators model datasources. That glossary drives search behavior, capability descriptions, and certification reviews for agent metadata trust.
When metadata is incomplete, AI fills gaps from prompts — which drifts from enterprise definitions and weakens auditability. Certification exists partly to prevent that drift.
Ownership fields (account manager, legal entity, data steward) should appear in the glossary when they drive approval workflows — not only when they appear in search UIs.
Relationship metadata (customer to contract, case to account) should use the same business labels in every datasource so cross-system workers do not reinterpret links per integration.
Publish glossary updates when legal or finance introduces new regulated attributes — metadata drift is a leading cause of failed agent metadata trust reviews.
Example
A CRM datasource mapped as customer exposes name, industry, owner, and region as business attributes — not only opaque API field names. A Sales Assistant uses that metadata to prepare a customer overview without the employee re-explaining field meanings each time.
Business value
Business metadata reduces prompt dependency, improves cross-system consistency, and makes AI reasoning align with how the enterprise describes its work.