Build AI-ready systems

How do I make an enterprise system AI-ready?

This section is the integrator path. You connect Connected Systems, model Business Entities with business metadata, link cross-system relationships, enforce protection, expose governed capabilities, validate, test, publish, certify, and maintain lifecycle — so Role Assistants can use the system inside Operational Trust.

In the dataplane UI, a Connected System is a vendor or platform integration. Each Business Entity is one governed business resource exposed to AI from that system.

Start here: Quickstart: new Connected System

Three layers (how humans and agents build)

Configure pages describe what to set on each Connected System and Business Entity. Command flags and help topics live in the reference tier.

Why this path exists

Integration platforms move data. AI Fabrix makes data meaningful and governable for AI:

• Business metadata — what records mean in business language
• Cross-system relationships — how customers, contracts, and documents connect
• Governed capabilities — business actions AI may request, not raw APIs
• Certification — proof across operations, agent metadata trust, and governance
• Evidence — completed work creates learning, not chat history

Without this path, AI gets access without authority — unsafe for enterprise roles, audits, and recurring work.

Build phases

Build path

Choose system
  ↓
Scaffold (aifabrix create) + copy fixture
  ↓
Register resource types + model JSON
  ↓
Configure authentication
  ↓
Model business metadata
  ↓
Define dimensions and protection
  ↓
Link cross-system relationships
  ↓
Expose governed capabilities
  ↓
Validate and repair
  ↓
Test (integration → E2E → governance)
  ↓
Publish and certify
  ↓
Operate and improve

flowchart TB
  GS[01 Get started]
  CS[02 Connected Systems]
  BE[03 Business Entities]
  VT[04 Validate and test]
  PC[05 Publish and certify]
  OP[06 Operate]
  GS --> CS --> BE --> VT --> PC --> OP

Enterprise AI Certification

Before Role Assistants rely on a connected system, integrators run three certification pillars (Builder CLI):

Then read the report: aifabrix lifecycle <systemKey>. Details: Certification.

Certification is readiness proof, not zero-risk guarantee.

Prerequisites

• Builder CLI installed; aifabrix auth status (login if needed)
• Dataplane reachable for your environment
• OpenAPI or MCP source for the target system
• Test credentials resolved via kv:// in env.template

Typical integration folder

integration/<systemKey>/
  application.yaml
  <systemKey>-system.json
  <systemKey>-datasource-*.json   # Business Entity manifests (one file per entity)
  env.template
  <systemKey>-deploy.json

Local files are source of truth until upload. Use aifabrix repair when manifest and JSON drift.

Who should read this section

Product context

• What is AI Fabrix?
• Operational Trust — governable AI
• Enterprise Knowledge — business context
• Role Assistants — role-scoped workers
• Evidence Fabrix — proof from completed work

Command quick reference

See CLI workflow reference for the full ladder.

Common integrator mistakes

Phase detail (what each folder proves)

01 — Get started

Scaffold from OpenAPI or MCP, resolve credentials via kv://, and align on systemKey / datasourceKey (Business Entity key) naming. The primary walkthrough is the recommended first read; Quickstart is the command-heavy variant.

02 — Connected Systems

Configure the Connected System manifest: auth, roles, subscriptions, AI interfaces, and lifecycle. See Connected Systems band.

03 — Business Entities

Model each Business Entity: entity types, business vocabulary, data flow, AI contract, sync, and policies. See Business Entities band.

04 — Validate and test

Schema validation, repair for manifest drift, integration tests, and E2E against sandbox or production test tenants. Do not upload broken JSON — validate is cheaper than debugging cloud drift.

05 — Publish and certify

Expose governed capabilities, upload to the dataplane, run the three certification pillars plus lifecycle. Publication makes capabilities available to Enterprise MCP and Role Assistants; certification proves readiness.

06 — Operate

Download online config, repair local folders, re-certify after vendor API changes, and extend integrations with Role Assistant capabilities. Treat integration folders as long-lived products, not one-off scripts.

When to use which get-started page

Evidence and Role Assistant handoff

Certified capabilities feed Enterprise MCP and Role Assistant task design. Operators do not configure raw API endpoints for workers — they assign roles and capabilities within certified scope. Completed tasks produce evidence under Evidence Fabrix, separate from chat transcripts.

For a single end-to-end path from multiple integrations to a live worker, see From integrations to Role Assistant and Operate your first Role Assistant.

When expanding from one pilot system to many, repeat phases 02–05 per systemKey before widening worker scope.

Success criteria (integrator checklist)

You can consider a system AI-ready for a defined scope when:

• Business Entities validate and E2E tests pass for exposed entities
• Business metadata and resource types are documented for operators
• Dimensions and foreign keys match governance sign-off
• Governed capabilities upload successfully and appear online
• All three certification pillars plus lifecycle report pass for that scope
• Operators know which Role Assistant roles may use which capabilities

AI-ready does not mean “every possible AI feature enabled globally.” It means certified, governed access for the integration and roles you configured.

Limits

Some Role Assistant evidence and UI surfaces vary by deployment. Certification proves readiness for the integration you configured — not every future AI feature in every environment.