Build a composable enterprise. Govern every change.
Fabric Platform is designed to implement the governed foundation of an Enterprise Composable Framework: reusable business capabilities, one trusted path for every change, deterministic application assembly, and portable experiences across channels.
What follows is the whole argument: the problem a framework solves, what one actually is, the mechanism that makes it hold, how a capability reaches a pixel, and where the boundary of this product sits.
Every line of business re-answers the same questions.
An enterprise with three businesses has three answers to who is this customer, three definitions of what they agreed to, three compliance implementations, and three audit trails. Nobody chose that. It happens because the second business unit had a deadline and the first one’s code was not shaped to be adopted.
The cost is not the duplicated code. It is that a policy change now has to be made in three places by three teams who disagree about what a customer is, and that no one can answer who approved this, and under what rule across the portfolio.
The duplication is the problem, and reuse alone does not fix it. A shared library that teams may fork under deadline pressure becomes three libraries within two releases. What makes the right-hand picture stable is not the library — it is that adopting it is the only path that compiles.
§ 02definition
02 · The operating model
What is an Enterprise Composable Framework?
An operating decision before it is an architecture. It says: the parts of a business every line of business needs — who a customer is, what they agreed to, what work is owed, how value moved, what policy permits — are built once, governed centrally, and reused. Everything above them is composition.
The decision is only real if something enforces it. A framework that relies on discipline forks the first time a deadline is tight.
So the framework separates four planes, each with a different owner, a different rate of change, and a different answer to can a business unit change this without asking anyone?
The contract on each boundary is what makes the plane replaceable. The experience tier speaks only roles, slots, fragment events, and named bindings — never SQL, never a policy decision. Read the arrows as the only permitted vocabulary across each line.
The test the design has to pass
Two unlike lines of business compose and render with no change to the foundation and no change to the composer.
Two unlike businesses — the vocabulary of one must be meaningless to the other. If closing the gap needs a change to the foundation, the foundation has absorbed business meaning. If it needs a change to the composer, the experience layer has absorbed authorization. Either way the framework has stopped being a framework.
§ 03mechanism
03 · The mechanism
Two paths in, and nothing else.
Two invariants do the work. Everything else in the platform exists to make one of them true: there is one way to change state, and one way to read it.
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 to all four. The gates run in a fixed order and every one of them fails closed.
The order is the guarantee. Policy runs before state, state before durability, durability before the handler — so an approval that arrives after authority was revoked is refused at execution, not honoured because it was legal at capture.
One query path, and why a cached screen cannot authorize
Every read goes through ProjectionHost with actor and tenant derived server-side, never taken from a caller parameter. This is what makes server-driven UI safe: the document that describes a screen is not a permission. A client can hold a cached document and render it; the moment it asks for data, authorization is re-evaluated at the host.
Views declare their own freshness contract — maximumAgeSeconds and offlineUsable — and actions declare whether authority governs at capture, at execution, or both. That pair is what lets a field or point-of-sale surface work with no signal and still refuse an action whose authority evaporated while the device was dark.
§ 04composition
04 · Capability to pixel
How a capability reaches a screen without carrying authority.
This is the part that answers how does a business capability stay contract-driven all the way to a pixel. Six artifacts, six gates. Each gate fails the build rather than the screen.
The capability:// reference is the whole trick. A document says put the agreement summary here and this button submits the payoff intent — never a query, never an endpoint. So a document can be authored in a CMS, cached on a device, and rendered by three different renderers without any of them being able to widen what the viewer may see or do.
Two rules keep it honest, and both are enforced in the release validator rather than in documentation:
Publication is not permission.
A capability publishing a view proves the view exists, not that this document may use it. The release carries explicit grant lists, and a reference outside them fails validation.
Components come from resolved component packs.
A component must be in the channel’s core vocabulary or in a pack the assembly locked. Supplying an undeclared pack cannot make a release valid.
§ 05boundary
05 · Product boundary
What Fabric Platform owns.
Platform owns the cross-industry mechanisms that must stay consistent as capabilities, applications, vendors and channels evolve. It deliberately does not own your company’s business vocabulary or your customer experience — and the fact that it declines to is what keeps it small enough to trust.
Platform shipped
The governed foundation
Capability contractsVersioned modules, dependencies, actions, policies, state machines, events, adapters, and views.
Provider adaptersConnections to systems of record, payment rails, search, identity, and industry services.
Production operationsHosting, secrets, observability, SLOs, backup, restore, and exact-environment certification.
Platform is infrastructure for the framework, not a prebuilt enterprise suite.
It does not ship a production capability catalog, your application shell, product-domain components, brand system, provider adapters, or industry policies. Those remain explicit application and enterprise responsibilities, and the framework only works because they do.
§ 06build order
06 · Implementation path
Turn the operating model into software.
The order is not arbitrary, and it is not the order most teams use. Most build the screens first and try to add governance underneath — which is why most composable programmes end up with a second mutation path. Start with one capability and one governed mutation, then expand without changing the foundation.
01
Publish a capability as a module.
You cannot govern what you cannot name.
Define its namespace, objects, actions, policies, state machines, events, adapters, views, and dependency ranges in a FabricModule. Declarative vocabulary only — the module describes what exists, never how a screen renders it.
Gate — the module graph exports to a deterministic, versioned manifest, and no industry noun appears in foundation source.
This is the product. Everything before it is preparation; everything after it is reach.
Derive trusted actor and tenant context at the gateway. Let PlatformHost enforce policy, current state, idempotency, durable execution, event truth, and recovery. Authorization is evaluated twice — at submission and again at execution.
Gate — every gate fails closed; approval does not preserve revoked execution authority; domain writes and canonical events commit in one transaction.
Server-driven UI is only safe if reads are governed independently of the document that requested them.
Authorize before storage access, hydrate compatible snapshots, replay ordered evidence, and use minimumCheckpoint when the UI must observe a completed write. A projection is never authoritative domain state.
Gate — tenant-isolation tests on every snapshot and event-source path; bounded waits return a typed timeout rather than stale data claiming to be current.
This is where “reusable” becomes enforceable instead of aspirational.
@fabricorg/assembly locks compatible modules and packs into a deterministic manifest and lockfile. @fabricorg/sdui-release validates documents, token sets, views, intents, grants, and channel compatibility before anything is promoted.
Gate — two unlike business fixtures sharing one capability produce deterministic lockfiles, accept a compatible upgrade, and reject a breaking drift. This discharges the §02 test.
The moment work leaves the process, “did it happen” stops being knowable and starts being evidence.
Swap policy engines, workflow runtimes, databases, systems of record, and external services without moving vendor shapes into capability code. Adapter outcomes are typed, and only transient idempotent outcomes retry.
Gate — an ambiguous outcome routes to reconciliation with durable evidence and is never retried; every declared port requirement resolves against a real interface.
Speed comes from removing repeated decisions, not from bypassing control. Teams change the part they own while stable contracts protect every other part — and the audit story stays single even as the portfolio grows.
What changes
Without a governed framework
With Fabric Platform
A new product
Each application recreates its own customer and agreement model
Composes existing identity, agreement, work, policy and settlement contracts and builds only its distinct workflow
A policy change
Policy and audit behaviour drift between channels and business units
Enforced once at the governed action boundary, for a person, an API, an automation, an offline queue or an AI agent alike
A brand or channel
UI releases become coupled to core business deployments
Validated releases change presentation while capability URIs and grants stay stable
A provider
Vendor APIs leak into domain logic and become hard to replace
Typed ports keep providers replaceable and make failure semantics explicit rather than assumed
A failure
Interrupted work is discovered from support tickets
Durable invocation, fencing, sagas, outbox delivery and reconciliation make interruption visible and recoverable
§ 08worked example
08 · Worked example
Automotive finance is one example.
The framework is cross-industry. Automotive finance simply makes the value visible: one company may operate origination, refinance, servicing and collections across dealer, customer, operator and field channels while sharing most of its business meaning. Same applicant, same agreement, same compliance evidence — four different workflows over them.
Three businesses, one vocabulary, four channels. Origination decides and books, refinance replaces an agreement, servicing and collections manage an active account — and all three read the same applicant and write to the same ledger. The channels differ only in the release they consume.
Why this helps the business.
A new finance product starts with reusable foundations.
The team adopts party, offering, agreement, settlement and compliance capabilities, then builds only its distinct workflow. The reuse is enforced by the assembly, not by a code-review convention.
A policy change lands once.
State licensing, approval authority or right-to-cure logic is enforced at the governed action boundary instead of copied into every screen — and the same rule covers the dealer portal, the mobile app and the overnight batch.
A brand or channel changes without rewriting the business.
Validated documents and token sets change presentation while capability URIs and grants stay stable. A new channel is a new release, not a new integration.
A provider can be replaced behind a port.
A bureau, LOS, servicer, payment rail or e-signature adapter changes without becoming the enterprise domain model, and its failure modes stay typed rather than inferred from a status code.
The framework contracts and supported experience path are shipped and certified. Production readiness still depends on the capabilities, product composition, adapters and operating environment your organization supplies — and a claim about an environment we have not run in would not be worth much.
Platform shipped
Governed mutation and projection kernels
PostgreSQL store, outbox, fencing, and recovery
Temporal saga lifecycle and reconciliation seams
Deterministic assembly manifests and lockfiles
SDUI documents, grants, packs, and release validation
Signed promotion, scoped render plans, gateway routing, and React adapter
PostgreSQL 16 migration and concurrency certification
Enterprise required
Production capability catalog and policy content
Product documents, domain components, brand mapping, and shell integration
Provider-specific adapters and systems of record
Identity, secrets, observability, and SLOs
Deployment database certification
Backup, restore, security, and adopter controls
Start with one capability
Build the shared foundation without building a monolith.
Publish one module, govern one mutation end to end, and prove that a second application can reuse it without a fork. That proof is the framework; everything else is scale.