Packaging answers two separate questions: at which boundary an implementation is connected, and which support level a language or target actually provides. "Supported" is never one boolean.
Choose the smallest fitting boundary
One selects the smallest boundary that satisfies the requested contract:
| Boundary | What it carries |
|---|---|
| Static in-process | Native types and monomorphized local calls; the default |
| WebAssembly / Component Model | WIT mapping and the Component Model canonical ABI |
| Native C ABI | Versioned opaque handles, fixed-width types, and explicit allocator and ownership functions |
| Process and remote | OCS frames over a selected transport; no location transparency |
Each boundary makes its own serialization, identity, authorization, deadline, cancellation, delivery, backpressure, partial-failure, and cost obligations explicit. Local and remote endpoints remain distinct even when they share one operation identity. A Rust dynamic library is not a stable cross-version ABI; it may exist only inside one exact toolchain lock as an implementation detail.
A compiled component binds exact evidence
A component compiled from native One binds the checked program, the exact Components expected interface, its implementation analysis receipt, the exact compiler and toolchain, the ABI binding, and a finite P-IR envelope. Build owns the concrete compiler action and target artifact; Deployment validates the runtime binding separately.
None of those coordinates may be inferred from a function name, module path, crate membership, successful compilation, or a matching wire shape. See Languages and SDKs, Add implementations, and Deployment.
WebAssembly and browser delivery
A WebAssembly component realizes one already-owned contract through the
canonical ABI. A host grants only the capabilities the plan selected, under
memory, fuel, and time quotas. For browser targets, core Wasm has no ambient
DOM, network, storage, clock, entropy, device, or user authority. Every import
comes from a planned BrowserHostImportSet.
Shared memory and threads require a CrossOriginIsolated target capability,
COOP/COEP header policy, CORP/CORS compatibility for every loaded resource, and
a declared non-threaded fallback. Browsers do not execute Component Model
binaries directly today; a removable Jco lowerer converts a component into ES
modules plus core Wasm artifacts and records its toolchain, size, startup, and
semantic-loss report. A same-origin Wasm module is not trusted more than
JavaScript from the same artifact.
Browser WebAssembly remains a documented profile rather than an activated renderer or product claim; the description above is end-product guidance.
Language support is a capability ladder
Each published language distribution declares which independently testable capability sets it provides:
| Capability set | Required surface |
|---|---|
| Contract values | Generated or dynamic nominal values, bounds, validation, identities, and faults |
| Client | Contract values plus typed call, stream, and workflow handles over a selected codec |
| Service / activity worker | Client obligations plus handler interfaces, admission, cancellation, credits, and server-boundary conformance |
| Portable workflow | Worker obligations plus the restricted deterministic command API and replay |
| Implementation-body language | Exact source-language definition, implementation profile, frontend, toolchain, dependency model, Build, artifact inspection, and admission |
| Native embedding | One exact ABI, ownership, and lifecycle boundary with its safety and conformance evidence |
Satisfying a lower row never proves a higher one. A generated client does not
make a language an admitted .one implementation language, and a
wire-compatible server does not prove portable workflow replay or internal
memory safety. See Profiles and assurance and
Generate and use an SDK client.
Package target-qualified artifacts
A build produces target-qualified bundles with explicit platform capability, signing, update, and accessibility metadata. OCI and other archive formats are packaging and distribution encodings, not internal architecture; the artifact closure, provenance, and receipts remain the evidence.
Ordinary framework-native applications keep their routes, components, state, layout, and interaction behavior while consuming narrow One contracts. See Applications and One Contract Schema.
Packaging grants no runtime authority
Packaging never grants runtime authority. Installing a package, publishing a distribution, or matching a wire protocol does not activate a provider, issue a grant, or prove internal behavior. Supply-chain admission, planning selection, Build realization, deployment binding, and runtime enforcement remain separate stages; follow Supply chain.
Normative owner & evidence
The contract, projection, and profile owners are Contracts; the component, ABI, and runtime boundary owners are Components; artifact realization belongs to Build and Deployment.
Demonstrated today: the in-process Rust boundary, the Component Model host and capability-empty analyzer guest, the C ABI and process/remote OCS frame contracts, and the bounded TypeScript client slice. Illustrative: browser Wasm delivery, the Jco lowering path as a product capability, and language distribution rows whose exact profile, toolchain, and conformance are not yet selected for a root.