Packaging and integrity

A component pack is a versioned set of components with prop schemas, slot declarations, declared roles, and the digest of its published artifact. It is what a document's components resolve against.

Roles are the substitution contract

implements declares which role a component fills. A brand substituting its own component for one in a pack is checked at build time by @fabricorg/adoption-bindings: the substitute must fill the role it claims. That is how a white-label design system stays honest without Fabric owning any components.

Federated delivery

A federated pack executes whatever its remote entry serves at load time. The approved artifactDigest describes the pack somebody reviewed, which is a different thing from the code that runs. So a pack that is delivered as a remote declares how.

remote: {
  entry: "https://cdn.example.com/uikit/1.0.0/remoteEntry.js",
  integrity: "sha384-…",
  exposes: { card: "./Card" },
}

resolveAssembly locks all three beside the artifact digest, and validateSduiRelease rejects a release whose declared remote does not match the locked one, or which adds or drops a remote the assembly did not. Entry, integrity and the exposed-module mapping are compared: comparing only the first two would let a component be re-pointed at a different module inside the same bundle.

Fabric loads nothing. Your shell's loader verifies integrity against the lockfile before executing.

The check that actually proves a loader works

mfeLoaderChecks includes fabric.mfe-loader.mismatched-digest-denial.v1, which supplies a well-formed integrity value that cannot match the approved bundle.

This matters more than it sounds. Rejecting a malformed integrity string proves a regular expression ran. The probe keeps the pack identity and changes only the digest, so a transport cannot pass by rejecting it for some unrelated reason, and a control load with the approved digest must still succeed. Same-realm federated code carries your application's own authority, so a transport that executes whatever an origin serves has handed that origin your application.

The loader validates origin and SRI syntax; it never sees the bytes. Exact-byte verification is delegated to your transport and cannot be established by inspection, which is precisely why it is certified instead.

Component pack conformance

componentPackChecks requires a resolver bound to its manifest:

• Each declared component resolves to a distinct renderer. One placeholder returned for everything satisfies "not null" for every component while binding none of them.
• A name the manifest does not declare resolves to nothing.
• Resolution is deterministic, compared by identity for anything not JSON-representable. Every function stringifies to undefined, so a structural comparison silently accepts a fresh function per call.

The adapter plane

A capability's usage contract can require ports. Until now the assembly resolved capabilities, component packs, and bindings, and whether the ports were satisfied was a separate deployment gate that nothing tied to the assembly digest. An assembly manifest now carries adapters, each one the output of certifyAdapter, and resolution judges every port a contract requires by the same rule the deployment gate uses: no adapter is unsatisfied_port, an adapter without a certification is uncertified_adapter, and a certification against an older port contract is stale_certification when the port definitions in force are supplied. The lockfile records each certified adapter with the port version it was certified against and a digest of the certification, and the assembly digest covers them, so a build cannot claim a certified pricing adapter it does not have.

const certified = await certifyAdapter({ definition: PRICING_PORT, fixtures, adapter, vendor: "heritage" });
resolveAssembly({
  manifest: { ...manifest, adapters: [certified] },
  portDefinitions: [PRICING_PORT],
  // ...
});

Every declared adapter is recorded, certified or not, so the lockfile says what is deployed and not only what passed. At startup, assertAssemblyRuntimeCompatible handed the runtime's registered adapters refuses an approved adapter that is not registered, a registered one the assembly never approved, and a registered one whose certification is not the one approved.

Declaring adapters, even empty, is what engages the plane. An assembly that does not declare it resolves as before, digest included, with port satisfaction as the separate deployment gate it always was; a vertical that wants the build to refuse a missing or stale adapter declares the field.