# Packaging and boundaries

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](/one/platform/languages),
[Add implementations](/one/authoring/implementations), and
[Deployment](/one/platform/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](/one/reference/profiles) and
[Generate and use an SDK client](/one/examples/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](/one/guides/applications) and
[One Contract Schema](/one/reference/ocs).

## 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](/one/platform/supply-chain).

## Normative owner & evidence

The contract, projection, and profile owners are
[Contracts](https://github.com/muijf/one/blob/main/systems/contracts/AGENTS.md);
the component, ABI, and runtime boundary owners are
[Components](https://github.com/muijf/one/blob/main/systems/components/AGENTS.md);
artifact realization belongs to
[Build](https://github.com/muijf/one/blob/main/systems/build/AGENTS.md) and
[Deployment](https://github.com/muijf/one/blob/main/systems/deployment/AGENTS.md).

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.