Enterprise Synchronization Fabrix

Define the business once. Synchronize on that model — not a new point-to-point project for every system.

Enterprise synchronization has traditionally been expensive: every new system adds another integration. AI Fabrix takes a different path: build Enterprise Knowledge first (Connected Systems, Business Entities, resource types), then activate synchronization as a platform capability on the same certified definitions that already power Smart RAG, MCP, and Role Assistants.

Data sync and freshness covers inbound sync, staleness, and certification impact — read that first for why freshness matters. This page covers what freshness alone does not: write propagation — keeping the same business record aligned across every system that shares it, once more than one datasource can hold the same resource type.

Why it's a distinct concept

Freshness keeps the platform's own copy current for reading. Sync bridge goes further: when two or more Connected Systems participate in the same resourceType (for example, two CRMs both modeling customer), a change on one propagates to the others, not just into the platform's copy. That is cross-system write propagation, not read freshness — and it is optional; most Business Entities never need it.

Enterprise Synchronization Fabrix is the cross-cutting name for:

Inbound sync — see Data sync and freshness
Webhooks as change signals — see Enterprise webhooks
Optional enterprise sync bridge — propagate normalized changes across datasources that share a resource type (this page's unique territory)
Continuous certification so API drift is detected before silent data corruption

For how to enable sync bridge on a manifest, CIP prerequisites, and runtime behavior, read the technical companion: Enterprise sync bridge — technical guide.

Traditional synchronization

Traditional integration connects systems directly:

CRM ↔ ERP
CRM ↔ Finance
ERP ↔ Service Management

Every connection repeats the same hard problems: record matching, field mapping, conflict resolution, API differences, failure recovery, loop prevention, audit, and ownership. Each project rebuilds enterprise understanding from scratch.

Enterprise Knowledge changes the model

AI Fabrix does not begin with point-to-point sync. It begins by modeling each Connected System as Business Entities with:

Resource type — common business vocabulary (customer, deal, document)
Enterprise identity — how records match across systems
Field mappings — normalization into business attributes
Relationships — cross-system links
Governed capabilities — read and write through CIP, not raw APIs
Authentication, governance, and operational trust

That metadata is required for AI-ready integrations anyway. Synchronization reuses it — no second mapping engine, no duplicate target lists.

HubSpot Company ──┐
Salesforce Account ├──► Enterprise Customer (resource type)
ERP Customer ─────┘

Datasources do not synchronize directly with each other. Each datasource participates in the enterprise resource for its resourceType. Adding a new system means joining the same resource type — not wiring N×(N−1) pipes.

One platform stack

Enterprise Synchronization Fabrix does not introduce a separate integration engine. It reuses existing platform capabilities:

Capability	Sync role
Resource types	Shared business vocabulary across datasources
Enterprise identity + field mappings	Record matching and normalization
CIP pipelines	`get`, `update`, `create`, `delete`, `list` — same execution as capabilities
Operational Trust	Permissions, dimensions, certification
Audit	Traceability for every propagation
Enterprise webhooks	Optional change triggers

The same certified metadata also feeds Enterprise MCP, Role Assistants, Enterprise Search, and evidence — build enterprise understanding once, reuse everywhere.

Activation model (business view)

After a Business Entity is modeled and certified, integrators declare participation — not point-to-point routes:

Mode	Business meaning
Disabled	Default — inbound sync only (if configured); no enterprise propagation
Master	Sync-bridge write role for this `resourceType` (keep copies aligned)
Bidirectional	Receive and publish enterprise changes for this `resourceType`

No target datasource lists. The platform resolves all datasources with the same resourceType and a non-disabled sync bridge mode.

Preferred write and list ownership when several systems share a resource type is a separate concern — Write and list authority across systems. Sync keeps copies current; authority decides where preferred mutations and authoritative lists go.

Optional webhooks tell the platform that something changed; business data still flows through existing CIP get and storage upsert — see Enterprise webhooks.

Continuous certification

Traditional sync projects are tested once at go-live. Enterprise Synchronization Fabrix aligns with continuous certification: authentication, API compatibility, capabilities, field mappings, webhook configuration, and trust validation are re-checked as vendors evolve — reducing reactive firefighting after business processes already depend on stale data.

Triggers feed the same propagation path

Whatever starts a sync — a scheduled or bulk job, a webhook change signal, a manual refresh, or a governed capability call — the path after that trigger is the same: CIP read → normalize → upsert → optional sync-bridge propagation to other participants. See Data sync and freshness for trigger types, modes, and batch/partial-success behavior; sync bridge does not change how a single system's data lands, only whether it then propagates onward.

Platform architecture

External systems
        │
        ▼
CIP (get / update / list / …)
        │
        ▼
Enterprise Knowledge (normalized records + metadata)
        │
 ┌──────┼──────────────┬────────────────┬────────────────────┐
 ▼      ▼              ▼                ▼                    ▼
Enterprise MCP   Role Assistants   Enterprise Search   Sync Fabrix

The more accurately the enterprise is modeled, the more capabilities activate without new integration projects.

Example

A CRM customer entity syncs hourly (sync.enabled). A second CRM is onboarded with the same resourceType: customer and syncBridge: bidirectional. When either system reports a change (schedule or webhook), the platform runs CIP get, updates Enterprise Knowledge, and propagates writable deltas to other participating datasources — governed by the same field mappings and trust rules used for Role Assistant capabilities.

Limits

Sync bridge applies to recordStorage Business Entities — document and vector entities use ingestion sync patterns instead.
Real-time behavior depends on vendor APIs, webhook coverage, and certification scope.

Configure inbound sync on the build path: Configure sync. Enable enterprise participation: Configure sync bridge. Optional signals: Configure webhook change signals. Freshness and operator expectations: Data sync and freshness.