Documentation Index

Fetch the complete documentation index at: https://docs.aifabrix.ai/llms.txt

Use this file to discover all available pages before exploring further.

Operating model

Prev Next

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 worker 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 Worker 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 Activity
Per integration change validate → test → upload → re-run certification pillars as needed
Quarterly Review certified systems, worker scope, dimension assignments
After vendor API change download, repair, E2E, re-certify operations pillar
After policy change Re-run verify-governance; update protection scenarios
Per Role Assistant task Evidence captured per Evidence Fabrix rules

Decision gates

Before expanding a Role Assistant to new capabilities or datasources:

  1. Integration certified for that scope (three pillars + lifecycle)
  2. Business metadata complete for new entities
  3. Governance sign-off on dimensions and relationships
  4. Operator runbook for failure and escalation

Skipping a gate moves risk from controlled platform behavior to ad hoc prompts and manual API use.

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.

Mermaid diagram

Raw credentials and vendor endpoints stay outside model context. See Trust boundaries.

Relationship to adoption roadmap

Use Adoption roadmap for time-phased rollout. Use this page for steady-state responsibilities after pilot.

Related