Architect overview

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	Lifecycle standards for creating, validating, and certifying integrations before promotion
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

Enterprise Reality (external systems) → Business Knowledge (metadata + relationships)
                                       → Governed Capabilities (compiled, certified)
                                       → Role Assistants (role-scoped)
                                       → Evidence (completed work)

This mirrors the platform's operating model — stage names, not the four pillar names. See Platform architecture for why the operating-model stages and the four pillars are deliberately different concepts. Further deep dives: Trust boundaries, Capability gateway.

Integration standards for teams

Each Connected System is a distinct integration boundary with its own certification
Business metadata required before AI exposure — not vendor field names alone
Foreign keys and dimensions documented before governance certification
Full certification ladder required before promoting to shared environments — see Build — certification
No redirect or duplicate product-story pages — Foundation owns “What is AI Fabrix?”

Integrator path: Quickstart: new Connected System and Platform developer access.

Pilot program pattern

Successful rollouts usually sequence work in three waves:

Platform foundation — tenant provisioned and ready for governed work; see Installation and onboarding
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. Document certification profiles (bronze vs stricter) in architecture decision records so operators know which gates apply per environment.

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.