Give AI governed business capabilities — not raw enterprise APIs
Enterprise systems already contain the records, facts and transactions that run the business. AI Fabrix does not replace those systems and does not make their raw APIs the enterprise contract AI-assisted work must understand.
Instead, Connected Systems and Business Entity/datasource definitions — called Business Entity definitions on this page — describe governed system integrations. The Composable Integration Pipeline (CIP) maps, normalizes, validates and executes those system-specific integrations. Multiple implementations are referred to as CIP pipelines. The Composable Operating Model (COM) separately compiles their canonical enterprise meaning.
AI Fabrix gives AI-assisted work stable enterprise meaning and approved business capabilities without making vendor APIs, model reasoning or integration technology the source of enterprise authority.
A Connected System represents an external enterprise application or platform participating in AI Fabrix.
It carries system-level integration concerns such as connectivity, authentication configuration and the technical information required to use the participating system.
The business resources inside that system are described separately through Business Entity definitions.
This prevents an entire CRM, ERP or content platform from becoming one unrestricted AI tool.
A Business Entity definition represents one governed integration of a business resource from a Connected System — for example CRM Companies → Customer, or a Deal, Contract, Invoice or Project from another authoritative system.
Its integration contract can contain:
The canonical enterprise concept behind those integrations is a Resource Type. Several Business Entity definitions can therefore contribute to the same Resource Type when explicit contracts define identity, mappings, authority, relationships and capability bindings.
Business Entity definition = governed integration. Resource Type = canonical enterprise meaning.
CIP defines and executes how external systems are mapped, normalized, validated and exposed through governed Business Entity integrations.
It owns system-specific concerns such as field mappings, transformations, relationship bindings and defined joins, synchronization where configured, executable operations and how data is moved securely.
For example:
| Source system | Source object | Resource Type |
|---|---|---|
| CRM | Companies | Customer |
| CRM | Deals | Deal |
| ERP | Invoices | Invoice |
CIP produces governed system-specific integration results and the definitions that allow those results to participate in the canonical enterprise model.
CIP does not own canonical enterprise meaning, current authorization, Runtime continuation, Enterprise Reality, system-of-record authority or business compensation decisions.
The Composable Operating Model (COM) is the enterprise compilation layer.
It compiles published enterprise definitions into canonical Resource Types, relationships, Dimensions, resource-/field-/read-/write-specific authority information and enterprise capability information.
This creates a strict responsibility split:
CIP: how is the external system mapped, normalized and executed? COM: what does that integration mean in the canonical enterprise model?
COM compiles authority definitions; it does not choose authority autonomously and does not become authoritative itself. The responsibility table below summarizes this governing split across all layers.
Current authorized business facts remain the responsibility of Enterprise Reality. COM is not a transactional master and CIP is not an ontology.
Bounded capabilities prevent an entire enterprise system from becoming one unrestricted AI tool. A Business Entity definition can declare capabilities such as searching Customers, retrieving one Customer, updating a Deal or listing Invoices.
The responsibility split is:
Actual capability keys are customer-defined through the published enterprise definitions. The architectural guarantee is the stable business contract — not one universal example key.
Capability availability or certification does not imply current authorization.
AI-assisted work requests approved business capabilities rather than receiving vendor endpoints and long-lived system credentials as its enterprise contract.
Authentication remains behind the governed integration and execution boundary. The exact mechanism depends on the Connected System and approved deployment architecture.
This separation means the AI-facing enterprise contract describes what governed business capability is available — not how to authenticate directly to the underlying vendor system.
CIP does not decide what work happens next and it does not determine current authorization.
Enterprise Runtime determines the next governed continuation. Before an approved business capability acts through CIP, current authority is revalidated under Operational Trust against the current governed state, operation and bound inputs.
Runtime owns approved business capability execution. CIP performs the connected-system operation.
If required authority cannot be established, the operation does not execute through the governed path.
A read can expose sensitive enterprise information. A write can change business state. Both therefore remain inside the governed architecture.
A read example:
Runtime determines governed retrieval → current authority is revalidated and enforced under Operational Trust → CIP retrieves and normalizes the permitted system data → Enterprise Reality resolves the current authorized fact through its governed resolution path
A change example:
Runtime determines the governed business capability → current authority is established and the current approval state permits execution → approved capability execution invokes CIP → authoritative system accepts or rejects → actual execution outcome returns to Runtime
A successful mutation result does not automatically become refreshed Enterprise Reality. Runtime determines when subsequent Reality resolution is required.
Higher-risk operations can require stronger authority, policy or approval controls without creating a second integration architecture.
AI Fabrix does not assume one system is globally authoritative for an entire business concept.
A CRM may be authoritative for one Customer field or operation while an ERP is authoritative for another. COM can compile resource-, field-, read- and write-specific authority where those contracts are explicitly defined.
The underlying enterprise applications remain authoritative for the records, facts, transactions and operation outcomes they own.
CIP normalization does not create a competing transactional master.
Runtime does not treat a relationship as authoritative merely because a model inferred it.
Relationships become available for governed use through validated relationship definitions, including validated keys, normalized references or other governed relationship contracts.
The ownership is layered:
CIP defines system-specific relationship bindings and mappings → COM compiles canonical relationship meaning → Enterprise Reality resolves current relationship facts.
For example, Customer → Deal → Contract → Invoice can span several systems when those explicit contracts have been defined and validated.
This is not automatic entity matching or master-data discovery.
A customer-renewal Role Assistant might use Customer and Deal information from CRM, Invoice status from ERP, service information from a case platform and relevant contract information from enterprise content.
Those systems do not become one database.
How information participates depends on the governed contract and use — not simply whether the source is a document or a record. Current authorized facts belong to Enterprise Reality, reusable organisational understanding belongs to Enterprise Knowledge, and validated operational knowledge belongs to Evidence.
Their Business Entity integrations provide system-specific resources and capabilities through CIP. COM compiles canonical enterprise structure and meaning. Enterprise Runtime determines continuation and Operational Trust determines current authorization.
Multiple systems. One governed business objective. Explicit responsibility at every boundary.
AI Fabrix is not architecturally limited to one fixed list of enterprise applications.
A custom system can participate where its resources, metadata, capabilities and execution can be described through supported Connected System and Business Entity contracts.
This does not mean every system has a prebuilt production integration, every authentication pattern is supported, or every vendor API is automatically suitable for governed AI use.
The architectural principle is that system-specific integration remains contract-driven rather than becoming model-specific tool wiring.
Detailed extension contracts and supported authentication mechanisms belong in product and technical-evaluation documentation.
Only integration and capability definitions that satisfy the applicable validation and approval requirements become available for governed Runtime use.
Validation may include structural checks and, where applicable, verification of mappings, relationships, protection behaviour and executable operations.
The exact validation and certification lifecycle depends on the type of governed definition and should not be inferred as one universal lifecycle for every Business Entity definition or relationship.
CIP may apply integration-level retry or transport recovery where supported by the integration contract.
An integration failure does not transfer business continuation to CIP. Enterprise Runtime determines whether governed work retries, waits, follows an approved recovery path or stops safely.
CIP does not decide to ask a human, invent another capability or change the business objective.
Detailed retry, compensation and multi-system transaction semantics belong in technical evaluation unless separately established by canonical architecture.
AI Fabrix is not positioned as the enterprise's only integration platform.
Existing integration technologies can continue to handle system-to-system processes, events and application integration where appropriate.
AI Fabrix addresses a different requirement: giving AI-assisted work stable enterprise meaning, approved business capabilities, current authority and traceable governed execution while existing systems remain authoritative.
The connected-system boundary can therefore sit directly against an enterprise application or against an approved enterprise integration surface, depending on the customer architecture.
| Layer | Responsibility |
|---|---|
| Enterprise system | Authoritative records, facts, transactions and operation outcomes it owns. |
| Connected System | Participating-system definition and system-level connectivity/authentication configuration. |
| Business Entity definition | Governed integration contract for one business resource from a Connected System. |
| CIP | System-specific mapping, normalization, synchronization and connected-system execution. |
| COM | Canonical Resource Types, relationships, Dimensions, authority compilation and capability information. |
| Enterprise Reality | Current authorized business facts, including provenance and freshness. |
| Enterprise Runtime | Approved business capability execution and all continuation decisions. |
| Operational Trust | Current authority evaluation and enforcement. |
| Role Assistant | Governed business purpose and operating boundary. |
| Approved AI interface | User interaction and model reasoning; not enterprise authority. |
At design time:
At runtime:
The architectural principle is simple:
Describe integrations explicitly. Compile canonical meaning separately. Keep current authority with Operational Trust and business continuation with Runtime. Keep vendor-specific execution behind the governed boundary.
Review the complete architecture in your own environment.
