AI Fabrix is described two ways, at two altitudes, and the two are not the same list told twice. The four pillars name how the product is structured; the operating model names the stages governed work passes through end to end. The customer-facing Miso Controller and Dataplane applications support both with governance, lifecycle, governed data access, and execution. Architects use this page for what AI Fabrix owns technically, what becomes reusable across initiatives, and what can change without rebuilding the foundation.
Four pillars: the product structure
| Band | Pillar | What it does |
|---|---|---|
| Enabling | Operational Trust | Governs who may act, on what, under which policy and approvals |
| Enabling | Enterprise Knowledge | Gives AI reusable business meaning, relationships, and scope |
| Business value | Role Assistants | Turn business roles into governed assistants that complete recurring work |
| Business value | Evidence Fabrix | Turns completed governed work into proof and operational learning |
Enabling pillars exist to make the business-value pillars trustworthy — they are prerequisites, not lesser pillars.
Operating model: how governed work flows
What this shows: The product operating model from enterprise reality through governed work to evidence and learning — each arrow is a trust boundary, not an optional integration step.
What this is not: Deployment topology, CLI steps, or manifest structure. See Trust boundaries for where enforcement happens.
This flow is a sequence, not a second list of the four pillars. Enterprise Reality and Continuous Learning are not pillars at all — the existing systems/people/policy the flow starts from, and what the organization does with Evidence afterward. Where a stage and a pillar share a topic, they still aren't the same entry: the flow's Business Knowledge stage is where the Enterprise Knowledge pillar's governed content gets used in one piece of work, not a second name for that pillar; Governed Capabilities is where Operational Trust mediates the request; Evidence is what Evidence Fabrix preserves. Role Assistants shares its name across both by design — see Role Assistant Runtime for how it activates from published metadata.
Platform applications and technical implementation
What this shows: How optional interfaces, Role Assistant surfaces, the Dataplane application, and the Miso Controller application relate in the technical implementation — requests flow downward; governance and policy anchor the stack.
What this is not: Infrastructure sizing, regions, or SKUs. See Platform sizing and environments.
Neither application creates a bypass for enterprise data access or capability execution. AI clients never receive raw vendor credentials. The four pillars remain the product structure; these applications and technical mechanisms support their operation.
What becomes reusable across AI initiatives
A second AI initiative moves faster than the first because specific enterprise concerns are established once, validated, and reused — not rebuilt into every new agent, prompt, or integration:
| Reusable concern | Established once, then reused |
|---|---|
| Business meaning: entities, relationships, measures | A governed definition validated by an architect, read by every Role Assistant and approved AI. See Business meaning as governed content. |
| Relationships and source authority | Cross-system metadata naming which system owns the record, so it isn't re-derived per project |
| Business scope (Dimensions: role, region, customer, project, and similar) | Dimension definitions on a Business Entity, checked at runtime for any AI |
| Governed knowledge exposed to AI | Enterprise Knowledge's business metadata and relationships, reasoned over by any Role Assistant |
| Bounded business capabilities | Compiled and certified once at publish time, reused by any approved interface. See Capability gateway. |
| Authority and approval requirements | Attached to the operation itself, not one AI client, so every execution path enforces it |
| Role Assistant purpose and operating boundaries | Published metadata and active-role scope, enforced at runtime across every channel. See Role Assistant Runtime. |
| Evidence definitions and validation expectations | Defined once per capability, applied to every completed run. See Evidence Fabrix. |
| Deployment and lifecycle policy, where applicable | Environment and promotion policy set once per instance, applied to later initiatives on it. See Platform sizing and environments. |
An architect reviews and certifies a definition once; later initiatives reuse that decision instead of repeating the design work — this is the core of what makes governance faster rather than heavier. For the manifest-specific slice of this table, see Business meaning as governed content.
Independence: what can change without rebuilding the foundation
Models, AI interfaces, and the implementation technology behind a Connected System can all change without re-deriving business meaning, permissions, or capability access — because each consumes a stable, customer-owned contract instead of embedded logic:
- The generated, validated manifest — a Role Assistant or external AI reads the same business-meaning contract regardless of which model sits behind it.
- The certified capability — a Connected System's implementation technology can change behind it without the AI-facing contract changing.
- The Work vocabulary any approved external AI interface uses through the platform's MCP layer. See Runtime Orchestration MCP for how a new interface reuses that same foundation.
None of this is automatic: the customer, through their own architects and certification process, must revalidate that a new model, interface, or implementation still honors its contract. Independence means that revalidation — not a full governance redesign — is what a change requires.
Role-specific next steps: integrators start at Build AI-ready systems, architects at the Architect overview, operators at the Operator overview.
Design principles
- Business meaning before system structure — resource types and metadata precede raw APIs.
- Capabilities, not credentials to AI — models and Role Assistants request business actions; platform executes.
- Active role as boundary — Role Assistants inherit role scope, not unbounded agent authority.
- Evidence from certified completed work — audit and learning attach to validated outcomes, not chat volume.
- Certification before scale — operations, governance, and metadata trust — not a single trust check.
Deployment note
Concrete deployment topology (regions, SKUs, networking) is customer-specific and provisioned through your platform team. This documentation describes product behavior, not infrastructure sizing.