The standard
What a team has to get right to build a composable application on Fabric Platform, and which of those things the build refuses to let them get wrong.
This is the standard for building an application on top of the capability plane. It covers the layers above the semantic layer: the shell, the design system, server-driven screens, federated packaging, and the path a read or a mutation takes to reach a governed host.
Most of it is enforced rather than advised. Where a rule is checked by a build gate or a conformance suite, this standard names the check, because a rule nothing enforces is a rule that survives until the first tight deadline.
What Fabric owns, and what you own
Fabric owns artifacts and the gates that validate them. It owns no renderer, no compositor, no
content system and no shell. There is no createRoot, no ReactDOM and no renderToString anywhere
in the platform, and that is a design position rather than an omission.
| Concern | Fabric owns | You own |
|---|---|---|
| Server-driven screens | The document, release and digest, and validateSduiRelease | Authoring, composition, rendering |
| Design system | Renderer-neutral token sets, the DTCG port, component roles | The components and the brand |
| Federated packaging | The locked remote: entry, integrity, exposed modules | The bundler and the loader |
| Shell | Verified actor claims, the channel vocabulary | Navigation, routing, layout |
If Fabric owned the renderer there would be one implementation, and three surfaces would fork it within two releases. If Fabric owned nothing above the capability, whoever shapes a document would decide what it reaches, and the content system would quietly become the authorization surface.
The rule that everything else rests on
A promoted release is the only render ingress. A document is renderable only as part of a
promoted, digest-verified release. Grants, enumerated variants and locked remotes all get their
meaning from validateSduiRelease, which runs at promotion, so a renderer that accepts composed JSON
directly inherits none of it.
sduiChannelChecks() certifies this for any channel, including one you write. See
ADR 0016.
Where the trust boundary falls
Read this before designing anything in the sections that follow.
Client-side verification catches accidents. Server-side gates stop attacks.
Verifying a release, checking a remote's integrity and narrowing grants are all worth doing in a client: they catch a stale cache, a bad deploy, a CDN mismatch, and a release served to the wrong tenant. None of them prevents a hostile client from widening authority, because a hostile client does not run them.
The guarantees that hold under attack are server-side. PlatformHost re-checks authority at the
moment of execution, and ProjectionHost authorizes every query. Neither is reachable from a browser
in any case; both import Node built-ins.
Nothing you build should describe a client-side check as enforcement. The predictable failure is someone skipping a server-side check later because the client "already validated it".
Certify rather than trust
Every seam in this standard ships an executable definition of correct, so an implementation you write is certified rather than taken on faith.
| Suite | Certifies |
|---|---|
sduiChannelChecks | A channel refuses anything that is not a promoted, verified release |
mfeLoaderChecks | A transport verifies the bytes it executes |
componentPackChecks | A resolver is bound to its manifest |
experienceGatewayChecks | Mutations reach PlatformHost, reads reach ProjectionHost |
identityPortChecks | A credential resolves to claims, and nothing else does |
Run them in CI. A suite that exists and is never run certifies nothing.
Origination, refinance and collections
Three verticals composing one shared capability library — what each adds, what it reuses, and where it meets SDUI and external systems.
Identity and tenancy
Turning a credential into actor context, and why proving who someone is says nothing about where they may act.