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.

Existing applications remain the systems of record. Sync keeps Enterprise Knowledge current; it does not create a competing master of the data.

Why it matters

Role Assistants and evidence depend on current business context. Without a governed sync story, AI programs drift quietly — assistants answer from stale pipeline data or unsigned contract versions.

Enterprise Synchronization Fabrix is the cross-cutting name for:

Inbound sync (bulk, incremental, on-demand) into Enterprise Knowledge
Optional enterprise sync bridge — propagate normalized changes across datasources that share a resource type
Webhooks as change signals (not a separate ingestion engine)
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 (not a webhook-only product)

Synchronization can start from:

Scheduled or bulk sync jobs (large loads persist in batches with one governed persistence path)
Webhook change signals
Manual or API-initiated refresh
Governed capability execution (including Role Assistant tasks)

The execution path is the same regardless of trigger: CIP read → normalize → upsert → optional sync-bridge propagation. Bulk upserts classify insert vs update sets and persist them in batches; operators should expect deployment-specific batch and row limits, and treat pre-persistence rejects separately from successful rows in a partial response.

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.

Documentation Index