Enterprise Composable Framework

An Enterprise Composable Framework is an operating decision before it is an architecture. It says: the parts of a business that every line of business needs — who a customer is, what they agreed to, what work is owed, how value moved, and what policy permits — are built once, governed centrally, and reused. Everything above them is configuration.

The decision is only real if something enforces it. A framework that relies on discipline forks the first time a deadline is tight.

The four planes

The framework separates four planes. Each has a different owner, a different rate of change, and a different answer to can a business unit change this without asking anyone?

The test the design has to pass: two unlike verticals compose and render with no kernel and no compositor change. The kernel already holds itself to that bar with unrelated certification fixtures. The experience runtime has to meet it too.

Where Fabric Platform sits

Fabric Platform implements the kernel and the contracts used to publish capabilities. It does not ship a production catalog of Party, Agreement, Settlement, or other business capabilities, render screens, or know industry vocabulary. Applications and capability packages provide that meaning.

Three properties make this composable rather than merely layered:

One mutation path. A screen, an AI agent, a scheduled worker and an offline replay all enter through submitAction. There is no second way in, so a governance rule written once applies everywhere.

One query path. Compositors, federated graphs and agents all read through ProjectionHost.project() with the actor and tenant derived server-side. A cached document can render; it can never authorize.

Contracts that fail closed at build. A capability can publish a versioned usage contract. A vertical adopts it by declaring a dependency and binding roles, slots and data maps. createModuleRegistry() rejects missing dependencies, cycles and undeclared cross-module relations, and @fabricorg/adoption-bindings fails the build when a binding invents a role the capability never offered. @fabricorg/assembly then resolves the declared module and component-pack graph into a deterministic manifest and lockfile. The application owns what it declares; Platform owns making the result reproducible and rejecting an incompatible graph.

What composability means concretely

A capability is a versioned FabricModule plus a published usage contract. Adopting one is four steps, all of them reviewable:

1. Declare a dependencies entry on that namespace and version range.
2. Relate objects only to declared dependency targets.
3. Bind experience roles, slots and data maps.
4. Resolve the application manifest, then serve reads through ProjectionHost and writes through PlatformHost.

Sharing inside one company and adopting across companies are the same mechanism. A second company composes a different registry of the same packages; it does not fork the kernel.

Server-driven UI, precisely

The server defines what may appear and which verbs are legal. The client decides pixels.

@fabricorg/gen-sdui emits data-shape bindings such as capability://agreement/summary. It emits no screens. @fabricorg/experience-contracts carries roles, slots, and action intents as fabric.experience/v1 JSON that Platform stores and deliberately does not interpret.

Application-owned composer inputs become a renderer-neutral document. @fabricorg/sdui-release validates that document against the assembly lockfile, resolved component packs, token set, and explicit grants for every capability view and intent. A promoted release is immutable input to web, mobile, point-of-sale, or agent channels. Each channel supplies its own native component registry and verifies that it implements the document's core vocabulary.

The supported experience tier keeps two different guarantees explicit:

• @fabricorg/experience-runtime/server verifies and selects an admitted release, then issues a scope-bound render plan containing opaque fragment events and named read bindings.
• @fabricorg/experience-runtime/client and @fabricorg/experience-react consume that plan. Their checks catch stale caches, bad deploys, and delivery mismatches. They do not authorize.
• @fabricorg/experience-gateway re-resolves every plan handle from trusted server state. Reads still reach ProjectionHost authorization and mutations still reach PlatformHost execution authorization. Browser assertions of actor, tenant, grants, variants, releases, or action IDs are ignored.

Four rules keep that portable:

• Document nouns stay generic — document, slot, role, fragment, intent, view URI, token set, release, channel.
• A cached document may render. It may not authorize a read or execute a mutation.
• Components must come from core vocabulary or the assembly's resolved component packs; merely supplying an undeclared pack cannot make a release valid.
• Offline and field channels use view offlineUsable and action governingMoment, so a dealer pad, a field tablet and a bedside cart take the same path.
• Theme is a token-set deploy through DesignTokensPort, not a release of the host.

Delivery status

This is a complete supported path, not a mandatory monolith. Applications may replace any experience-tier module by passing its public conformance suite. Supastarter remains the shell and @fabricorg/ui remains the Fabric family design-system owner.

Building one

The Composable application standard is the working document for teams building on this path. It covers identity and tenancy, authoring and grants, packaging and integrity, integrations and ports, promotion and release, reads and mutations, and offline and recovery — and where a rule is enforced it names the build gate or conformance suite that enforces it, because a rule nothing checks survives until the first tight deadline.

Archetypes, not industry modules

@fabricorg/archetypes is optional and versioned, and Platform does not know its names. Six abstractions carry meaning across companies:

Illustrations never enter Platform source. A vocabulary is not stable until two unlike domains certify against it without an undocumented exception.

Next

Automotive finance puts every plane into one industry's words, then the verticals show origination, refinance and collections composing the same library.

See also

• Vertical-neutral capability boundary
• Kernel capabilities and ownership
• Capability contracts and SDUI ingress
• Ports and adapters