Write and list authority across systems

Purpose

Write and list authority is how AI Fabrix lets several Connected Systems share one business object — for example customer — and still know where preferred writes and authoritative lists go, without building multi-system write glue.

Define ownership once on Business Entity metadata. Systems of record stay authoritative for their domains; the platform routes preferred mutations and lists instead of inventing a second master. Role Assistants and Enterprise MCP keep one governed capability surface for the resource type; they do not ask users to pick “which CRM.”

This page is the product story. How to set the flag: Configure write and list authority.

Why it matters

Enterprises almost never run a single system of record. Sales, service, finance, and legacy CRMs all hold overlapping customers, deals, or cases. Traditional answers are expensive:

AI Fabrix separates business meaning (resourceType) from which Connected System is preferred for mutation and authoritative list. That is a platform differentiator: multi-system participation with one preferred write/list target — declared in metadata, not coded.

Without a clear preferred authority, the platform cannot safely route writes when several datasources are writable for the same resource type. Conflicting or missing preferences surface as compiler findings and can disable write capabilities until ownership is clear.

How it works

What this shows: one business object spanning several Connected Systems — reads may compose; preferred writes and lists route to one authority.

What this is not: sync participation, Role Assistant skill tiers, or human approval authority (Operational Trust).

Several Connected Systems share resourceType (e.g. customer)
  → declare one preferred write/list authority
  → Enterprise Knowledge compiles routing
  → Role Assistants / MCP request customer.update once
  → platform routes the write to the authority system

Rules in product language:

• Reads may compose across contributing systems so assistants see joined business context.
• Writes route to a single preferred authority datasource for that resource type.
• If only one writable Business Entity exists for the resource type, preferred authority can be implicit (no extra declaration required).
• If several are writable, the enterprise must make one preferred authority explicit.
• Sync bridge master is a sync write-role only. It does not by itself define preferred write/list authority for governed capabilities.

Example

CRM A and CRM B both publish customer.

• CRM A is the preferred write and list authority — updates and authoritative lists go there.
• CRM B still contributes to composed knowledge (and may sync copies via the sync bridge) without becoming the write target.
• A Sales Assistant requests customer.update once. Users never choose “CRM A vs CRM B.” The platform routes to CRM A because ownership was declared on the Business Entities.

Business value

• Multi-write landscapes without custom glue — add another Connected System that shares the resource type; adjust preferred authority in metadata; no new point-to-point write project.
• One governed action surface for Role Assistants and Enterprise MCP — business language stays stable while systems change underneath.
• Safe fail-closed behavior when ownership is ambiguous — better than silent dual-write.
• Clear separation from sync (copies) and from who may approve (Operational Trust).

Limits

• Preferred write/list authority does not bypass RBAC, ABAC, or Operational Trust at execute time.
• It does not replace sync bridge when you need copies kept current across systems — use both when the landscape requires it.
• Integrators still publish writable capabilities (create/update) on the authority entity; authority alone is not a substitute for certified operations.

Related

• Configure write and list authority — Track B how-to
• Enterprise Synchronization Fabrix — sync vs authority
• How Role Assistants get capabilities — catalog membership ≠ write routing