How enterprises run AI Fabrix day to day — roles, boundaries, certification rhythm, and evidence — after the initial build path.
Purpose
The build path makes systems AI-ready. The operating model defines who maintains that readiness, who approves Role Assistant scope, and how proof accumulates in Evidence Fabrix.
This page complements Role Assistants operating model, which focuses on assistant concepts; here the emphasis is organizational roles and cadence.
Core roles
| Role | Responsibility | Primary docs |
|---|---|---|
| Executive sponsor | Outcomes, investment, risk appetite | Executive overview |
| Enterprise architect | Pillars, trust boundaries, integration standards | Architect overview |
| Integrator / developer | Model, validate, publish, certify integrations | Build AI-ready systems |
| Security / governance | Dimensions, protection, certification sign-off | Operational Trust |
| Business operator | Role Assistant tasks, outcomes, escalation | Operator overview |
| Platform operator | Environment health, lifecycle, re-certify triggers | Operate phase |
No role receives unfettered API access for AI. Role Assistants and capabilities are mediated by Operational Trust.
Operating cadence
| Cadence | Business activity |
|---|---|
| Per integration change | Re-validate and re-publish the change, then re-run whichever certification pillars that scope covers |
| Quarterly | Review certified systems, Role Assistant scope, and dimension assignments |
| After vendor API change | Refresh the local integration from the deployed system and re-certify the operations pillar |
| After policy change | Re-confirm governance sign-off and update protection scenarios |
| Per Role Assistant task | Capture and certify the result when Evidence is required — an Ask answer alone is not certified Evidence |
The commands behind each cadence step (validate, upload, download, repair, certification verbs) are taught in Build AI-ready systems.
Decision gates
Before expanding a Role Assistant to new capabilities or Business Entities:
- Integration certified for that scope (three pillars + lifecycle)
- Agent metadata and business semantics complete (trust pillar green — not
notTrusted) - Governance sign-off on dimensions, protection, and Content Review rules where documents are involved
- Operator runbook for failure, escalation, and evidence review
Skipping a gate moves risk from controlled platform behavior to ad hoc prompts and manual API use.
What becomes reusable as adoption scales
This operating model does not restart for every new Role Assistant. The same certified systems, governed business meaning, Dimension definitions, and Evidence definitions carry forward — later initiatives add and validate only what is genuinely new for their business outcome instead of rebuilding the enterprise foundation. See Platform architecture for the underlying table of what becomes reusable across AI initiatives.
Trust boundaries (summary)
What this shows: How enterprise data and authority flow through knowledge, capabilities, Role Assistants, and evidence — not direct API access.
What this is not: A technical component diagram — see Trust boundaries for enforcement detail.
Raw credentials and vendor endpoints stay outside model context. Stage names here match the operating-model flow in Platform architecture — Business Knowledge and Evidence are stages that flow describes, not second names for the Enterprise Knowledge and Evidence Fabrix pillars. See Trust boundaries.
Relationship to adoption roadmap
Use Adoption roadmap for time-phased rollout. Use this page for steady-state responsibilities after pilot.