Architecture at a glance

You don’t need to know Fabric’s internals to use it — but a mental model helps you reason about where governance happens and what to expect from each call.

Fabric is organized as a set of capability planes behind a single governed gateway. Consumers never touch a data store or an internal service directly. Every request — console, API, or agent — enters through the gateway, which verifies identity, pins an immutable scope, starts a trace, and emits an audit event before fanning out.

Note

A platform architecture diagram will be added here. For the authoritative diagram, see the Enterprise Architecture & Deployment brief.

The path of a request

1. Unified gateway — the single governed entry point. For every request it verifies identity, resolves an immutable organization → department → project scope (no request can widen its own scope), starts a distributed trace, emits an audit event, and enforces per-organization rate limits and quotas.
2. Identity & access — authentication, the tenancy hierarchy, and authorization (enterprise SSO, SCIM, MFA, a five-role model plus custom roles).
3. Intelligence & trust — where agents reason and act: orchestration, the context graph and retrieval, the action registry, simulation, the approval engine, policy-as-code, multi-model routing, and the audit / lineage / compliance services.
4. Data & connectivity — connectors that ingest data and expose governed operations, the ingestion and semantic-mapping pipeline, knowledge bases, and structured tables.

What this means when you build on Fabric

• One endpoint, one scope contract. Whether you call over MCP, REST, or an SDK, the same governed edge verifies identity, pins your scope, traces, and audits the call.
• The context graph is never exposed directly. Your queries are scope-pinned to your project, read-only, write-blocked, and bounded — cross-tenant reads are impossible even if a client misbehaves.
• Governance lives where the action fires, not at the network edge — so it cannot be bypassed.
• No hard-coded model provider. Models are a configuration choice; sensitive data is routed to private or on-premises models automatically.

The query lifecycle

Every call — MCP or REST — runs the same fail-closed pipeline:

authenticate → resolve scope → rate / quota → validate →
policy (allow | deny | allow+gate) → approval (human-in-the-loop) →
dry-run → execute → post-process (PII redaction) → record

Each stage logs to its own system of record (audit log, policy decisions, approvals, lifecycle records), and every response carries a lifecycle_id you can use to trace and audit the call end to end.

Deploy anywhere

The identical control plane runs in three postures — managed cloud, private cloud / on-premises, or fully air-gapped — selected by configuration, with identical governance guarantees in all three. See Deployment postures.