Architects design how AI Fabrix fits the enterprise: four pillars, trust boundaries, integration patterns, and certification gates before Role Assistants scale.
Purpose
Translate the AI Fabrix operating model into your reference architecture — which systems become AI-ready first, how business metadata and cross-system relationships are governed, where certification fits in release processes, and how Role Assistants stay inside Operational Trust.
Architects set standards integrators follow and operators rely on. This page is the adoption entry for that role.
What architects own
| Domain | Decisions |
|---|---|
| Operational Trust | Roles, policies, dimensions, certification requirements before production AI |
| Enterprise Knowledge | Resource types, metadata standards, cross-system relationship strategy |
| Integration standards | CLI-first create/repair patterns, schema compliance, CI validate/upload gates |
| Certification policy | When operations, metadata trust, and governance verification must pass |
| Trust boundaries | No raw API or credential exposure to models; capabilities as the only execution surface |
Certification is readiness proof for a defined scope — not a one-time checkbox. Architect policy should define re-certification triggers (vendor API changes, policy updates, new datasources).
Reference architecture flow
External systems → Enterprise Knowledge (metadata + relationships)
→ Governed capabilities (compiled, certified)
→ Role Assistants (role-scoped)
→ Evidence Fabrix (completed work)
Deep dives: Platform architecture, Trust boundaries, Capability gateway.
Integration standards for teams
- One systemKey per integration folder; multiple datasources per business entities
- Business metadata required before AI exposure — not vendor field names alone
- Foreign keys and dimensions documented before governance certification
- Upload + full certification ladder in CI for promoted environments
- No redirect or duplicate product-story pages — Foundation owns “What is AI Fabrix?”
Integrator path: Quickstart: new Connected System and Platform developer access.
Azure install path
For net-new tenants, start Path A: Installation and onboarding → foundation install guides → first integration pilot on a sandbox system.
Document certification profiles (bronze vs stricter) in architecture decision records so operators know which gates apply per environment.
Pilot program pattern
Successful rollouts usually sequence work in three waves:
- Platform foundation — Marketplace deploy, tenant ACTIVE, admin access, sizing review
- Single integration pilot — one sandbox external system modeled, certified, and operated by a small integrator team
- Role Assistant expansion — Role Assistant scoped to certified capabilities on that pilot before broadening system count
Architects define exit criteria for each wave: which certification pillars must pass, which roles may use assistants, and which evidence artifacts operators must retain.
Align pilot scope with Adoption roadmap phases so executives see business outcomes, not only technical milestones.
Stakeholder communication should emphasize governed capabilities and certification gates — not individual integration tools — so business sponsors understand why pilots pause when governance verification fails.
Recommended reading order
- Executive overview
- Adoption roadmap — phased rollout
- AI Fabrix operating model
- Pillar READMEs: Operational Trust through Evidence Fabrix
- Build AI-ready systems — integrator phase map
- Operating model — steady-state roles