Onboarding seeds a minimal set of dimensions. Extend only when the business needs a real boundary (ownership, region, department, customer) — not for every field or API. Quality over quantity.
Dimensions are a business perspective, not a technical attribute dump. One Dimension catalog is shared across Connected Systems and Business Entities: the same region, department, or customer key applies to CRM, contracts, documents, and cases. Protection makes those shared boundaries enforceable. Role Assistants inherit that scope wherever they look — they do not invent a boundary model per system.
Dimensions are not permissions. Roles grant capabilities; dimensions decide which records are in scope — across systems. The Controller holds keys and types; values come from controlled lists or Connected Systems; protection projects who gets which values; runtime scopes search, capabilities, and AI context consistently.
Why it matters
Enterprise data is not uniformly visible and not held in one system. A regional sales lead should not see every customer globally. Reviewing a customer often needs CRM deals, contracts, cases, and documents together.
If each system invents its own region or department labels, visibility and protection break when Role Assistants join context. Shared dimensions mean the person has scope once (for example region=europe); every Business Entity that carries the same keys respects it.
Dimensions also avoid AIM group explosion: do not create a group per org unit or customer. Prefer values from business systems (HR, CRM, projects). Relevant is not the same as permitted — Enterprise Knowledge may assemble useful context; Operational Trust still applies the same dimension keys on every linked entity.
How it works
One Dimension catalog (shared keys)
→ Bound on many Business Entities / Connected Systems
→ Values from lists and/or those systems
→ Protection projects grants to people
→ Same scope on search, capabilities, and cross-system AI context
| Layer | What it does |
|---|---|
| Shared dimension | One Controller key — reused on CRM, CLM, files, cases, and more |
| Values | Static lists or dynamic values from synced business records |
| Protection | Assigns values to users and/or groups |
| Runtime | Filters what AI and search may see — on every entity that shares the key |
Shared across systems
| Without shared dimensions | With shared dimensions |
|---|---|
| CRM “EMEA”, contracts “Europe”, files free text | One region (or equivalent) and agreed values |
| Protection only inside one app | Same scope when assistants open deals, contracts, and documents |
| Cross-system review leaks or blanks inconsistently | Visibility and protection stay aligned |
Architects pick a minimal shared set; integrators bind the same keys on each Business Entity. Inconsistent keys break protection silently. See Cross-system relationships and Business entities and resource types.
Two ways people get scope
Same catalog and runtime; different how values are assigned:
- Via groups — protection grants values to an existing identity group (for example Europe Sales gets
region=europe). Use for real teams — not one group per org-unit code. - Via business data — protection grants values to users from Connected System records (for example HR department codes → managers via manager email), optionally gated by a coarse role-like group such as Manager — not one AIM group per department.
Business system syncs → Protection reads record fields → Grants to users/groups → Effective dimensions scope AI and search
Groups are one principal type, not required for every dimension. Protection does not create identity groups. IdP claims alone are not the primary protection scope — projected grants from synced data are.
Roles, certification, and who does what
Pair dimensions with Users, groups, and roles and AI Fabrix roles. Configure bindings on the Build track — Configure business policies.
Governance certification proves users outside a dimension cannot retrieve records via search, capabilities, or cross-system links. Recertify when dimensions or protection change. Document precedence when boundaries overlap (for example customer region vs sales territory).
Example
A Sales Manager in EMEA reviews a customer. Shared region and ownership filter CRM deals, contracts, and documents to the same scope across Connected Systems. Separately, HR syncs organization units; managers receive department scope from person records without a group per department. Out-of-scope capability requests fail closed under Operational Trust.
Dimension types
Types classify the business boundary — keep the live key set small.
| Type | What it is for | Example keys |
|---|---|---|
| domain | Enterprise domain taxonomy | domain |
| owner | People responsible for the record or area | owner, manager |
| geography | Geographic / regulatory scope | country, region |
| classification | Sensitivity labels | sensitivity |
| status | Lifecycle or process state | lifecycleStage, dealStatus |
| segmentation | Org and commercial slices | department, team, businessUnit, customer, project, … |
Live keys and values live in the Controller. Seeded keys are a starting point — not a requirement to enable every row. Org-unit style boundaries usually use department, businessUnit, or team with values from Connected Systems.
Domain dimension values
The domain dimension is static product taxonomy. Roles, resource types, and evidence kinds may carry a domain tag so catalogs stay browsable and Role Assistants stay coherent. Start from this planned set; add in the Controller only when the enterprise needs more.
System domains the platform needs
Two domain values are required for AI Fabrix to operate. They are not optional business labels — seeded platform catalogs and systems reference them:
| Value | Display name | Why the system needs it |
|---|---|---|
platform |
Platform | Groups AI Fabrix platform work: administration, deploy, develop, observe, discovery, Business Transformation, and the Everyone consume role. Seeded AI Fabrix roles, platform resource types, and platform evidence kinds tag domain: platform. Without it, platform roles and systems have no taxonomy home. |
llm |
LLM | Groups the enterprise model surface (call / embed). The seeded llm resource type and LLM Connected System scope tag domain: llm. Everyone and other consume paths depend on this domain existing in the Dimension catalog. |
Do not rename, delete, or repurpose platform or llm for industry taxonomy. Map industry work to business domains below (sales, finance, …). Keep system domains for product-owned catalogs and systems.
Business and industry domains
Remaining values are a menu for how the enterprise organises work. Enable what you need; do not invent a parallel domain per Connected System.
| Value | Display name | Groups work in… |
|---|---|---|
sales |
Sales | Commercial pipeline and customer growth |
finance |
Finance | Financial control and transactions |
people |
People | Workforce and HR context |
collaboration |
Collaboration | Teams, meetings, shared workspaces |
content |
Content | Documents and content libraries |
knowledge |
Knowledge | Knowledge and learning assets |
operations |
Operations | Delivery and operational execution |
governance |
Governance | Policy, approval, and control |
it |
IT | IT services and change |
security |
Security | Security controls and risk |
compliance |
Compliance | Audit readiness and obligations |
procurement |
Procurement | Suppliers and purchasing |
service-delivery |
Service Delivery | Cases and customer service |
manufacturing |
Manufacturing | Production and quality |
supply-chain |
Supply Chain | Supply and inventory flow |
legal |
Legal | Contracts and counsel |
security and compliance also appear on some seeded platform admin roles (for example Security Admin, Compliance Admin). Treat them as shared taxonomy — still do not remove them if those roles are in use.
Common dimension keys (menu)
Treat as a menu — enable what the enterprise needs; do not turn every attribute into a dimension.
| Dimension | Business value |
|---|---|
| Country / Region | Geographic responsibility and regulatory boundaries |
| Customer | Accounts the role owns or serves |
| Department | Org structure from systems of record (for example HR) without a group per unit |
| Project | In-flight delivery scope |
| Business unit | Separate divisions without duplicate role catalogs |
| Manager | Reporting lines for approval and escalation |
| Team | Squad or pod models without role explosion |
| Environment | Separate dev, test, and production during pilots |
Dimensions reduce role and group explosion only when the set stays shared, business-owned, and minimal — a few clear boundaries enforced for people and Role Assistants across systems.