Dimensions define business boundaries — ownership, region, department, customer, project, or account responsibility. Protection rules make those boundaries enforceable so AI-assisted work stays within trusted scope.
Why it matters
Enterprise data is not uniformly visible. A regional sales lead should not see every customer globally. A project assistant should not access unrelated contracts. Dimensions translate business boundaries into enforceable access logic before AI uses data or requests capabilities.
How it works
Dimensions attach business meaning to data fields — for example country, region, department, or customer ownership. Protection rules apply those dimensions so queries, searches, and capability requests respect scope.
Business boundary (dimension) → Protection rule → Scoped data and actions
Dimensions work with roles and policies: the active role defines responsibility; dimensions define which records fall in scope; protection ensures out-of-scope data is not exposed or modified.
Dimensions in Enterprise Knowledge
The same dimension keys (region, department, customer ownership) appear in field mappings on datasources. Operational Trust consumes those keys at query and capability time — inconsistent mapping breaks protection silently.
Protection scenario packs describe who may see which linked entities when traversing relationships. Architects review dimension design before Role Assistant pilots.
Certification impact
Governance certification verifies that users outside a dimension cannot retrieve records via search, capabilities, or cross-system links. Dimension changes after certification require re-running governance tests.
Protection uploads should be version-controlled like integration manifests — operators need to know which scenario pack was active when a worker completed a task.
Working with architects and operators
Architects define which dimension keys are mandatory for each business domain (sales region, legal entity, data classification). Operators verify that protection scenario packs match those keys before Role Assistant pilots. Integrators implement bindings on the configure track — this page stays at the business boundary.
When dimensions change after go-live, treat updates as a governed change: re-run governance certification for affected datasources and notify Role Assistant owners before expanding AI scope.
Pair dimension design with Users, groups, and roles: a role without matching dimension scope either sees too much or too little data for accountable work.
Regional and departmental boundaries often overlap — architects document precedence rules (for example customer region vs sales territory) so protection scenarios stay predictable during audits.
Document dimension defaults in architecture standards before integrators bind fields — inconsistent keys across datasources are a common cause of false passes in governance testing.
Review dimension catalogs when entering new markets or acquiring business units — inherited data often introduces conflicting region or entity keys.
Example
A Sales Manager in EMEA reviews deals for accounts they own. Dimensions filter pipeline data to the correct region and ownership. If a capability request would touch an out-of-scope customer, Operational Trust blocks it and records why.
Default dimensions and business value
Dimensions translate business boundaries into enforceable scope. The table below shows common dimension keys and why architects define them before Role Assistant pilots.
| Dimension | Business value |
|---|---|
| Country / Region | Align AI visibility with geographic responsibility and regulatory boundaries |
| Customer | Scope work to accounts the role owns or serves — not the entire customer base |
| Department | Match org structure so assistants see only relevant teams and cost centers |
| Project | Limit project assistants to in-flight delivery scope |
| Business unit | Separate divisions without creating duplicate role catalogs |
| Manager | Reflect reporting lines for approval and escalation paths |
| Role | Tie active role to dimension filters — access follows business reality, not API keys |
| Team | Support squad or pod models without role explosion |
| Environment | Separate dev, test, and production data during pilots |
Dimensions reduce role explosion. Instead of inventing a new platform role for every data slice, enterprises reuse business boundaries — region, customer, department — and let protection enforce them consistently for people and Role Assistants.
Business value
Dimensions and protection reduce data leakage risk, align AI visibility with business responsibility, and support audit-ready explanations of why data was included or excluded.