One composes languages at the level of contracts, not by pretending their syntax, runtimes, type systems, failure modes, and costs are identical.
Language support is capability-specific
A language can support one or more distinct levels:
| Level | What the language can do |
|---|---|
| Contract values | Use generated nominal types, schemas, validators, and OCS codecs |
| Client | Invoke exact operations across a selected boundary |
| Service or activity host | Implement operation handlers in the language's own runtime |
| Portable workflow | Implement the restricted deterministic workflow API |
| Full implementation body | Participate in .one implementation items with an admitted profile, frontend, Build path, runtime bridge, and conformance |
Supporting one level does not imply the next. A client SDK does not need to reimplement Planning, Build, Deployment, Authority, or History, and it does not need a local Rust process when the selected protocol can be implemented natively.
Rust and native One
Rust is the canonical platform implementation and first SDK language. It can compose owned contracts statically and expose atom-sized libraries without the CLI or generated application code.
Native One is the first-class executable language selected by an exact implementation-language profile inside an implementation item. Its source is still an untrusted claim: parsing or compilation cannot establish semantic conformance, provider selection, artifact admission, binding, or authority.
Choosing Native One or Rust
Start with Native One when the behavior is connective: it constructs projected values, sequences exact operation calls, matches outcomes, and handles effects, cancellation, and uncertainty supplied by the selected semantic closure. Reach for Rust (or another peer profile) as soon as the work needs general algorithms, data-dependent iteration, numeric kernels, provider SDKs, low-level concurrency, arbitrary I/O, FFI, or a library ecosystem.
| The behavior… | Use |
|---|---|
| Constructs one owned value and returns it | Native One |
| Matches an operation result and sequences the next call | Native One |
| Branches on a declared fault, cancellation, or outcome unknown | Native One |
| Cancels, compensates, or reconciles a declared effect | Native One |
| Iterates over an unbounded or data-dependent range | Rust |
| Needs a numerical, parsing, crypto, or provider library | Rust |
| Opens a socket, file, process, clock, or entropy source directly | Rust, behind an exact capability |
| Runs long CPU-bound or low-level concurrent work | Rust |
Both choices remain an isolated impl body selected by an exact profile, so
moving behavior to Rust does not reduce its analysis, Build, binding, or
authority obligations. See Native One and
add implementations.
Peer implementation languages
Python, TypeScript, Go, C, and other languages participate through exact source-language definitions and implementation profiles. A complete profile defines parsing, analysis, effects, source closure, target support, Build, packaging, runtime transport, conformance, and evidence.
Inside an implementation item, the exact profile also owns the closed config
schema and declares which imported dependency-resolver and toolchain contracts
it can consume. Source analysis derives consumer-scoped demands; project and
implementation-local constraints narrow them; the atomic lock resolves them.
No language name, package-manager prefix, or first-party profile is hardcoded
into the project builder or CLI.
Language tools receive only the logical body slices and explicit dependencies
reachable for the requested operation. Generic .one tooling preserves an
unknown body byte-for-byte instead of guessing its grammar.
Reusable target-language behavior belongs in small ordinary packages. Code generation projects only mechanical, contract-specific material; it never templates whole applications, provider protocols, authentication machinery, state machines, or framework integration.
One Contract Schema
One Contract Schema (OCS) is the canonical language-neutral schema and frame model at process and remote boundaries. Projection profiles define how owned types, constraints, faults, operations, and compatibility map into each target language.
A projection receipt commits the source contract revision, profile, toolchain, configuration, generated outputs, and any mapping loss. Generated code is a cache. The owner contract remains the authority.
Boundary choices
One selects the smallest fitting boundary:
- in-process Rust uses native types and static composition;
- WebAssembly uses WIT and the Component Model canonical ABI;
- external processes and remote services use OCS frames over a selected transport;
- native plugins use a versioned C ABI with explicit ownership and allocators;
- a Rust dynamic library exists only within one exact toolchain lock and is not treated as a stable cross-version ABI.
The boundary is part of Planning and Build evidence. WebAssembly is a replaceable realization, not the universal definition of portability.
Example
Illustrative Rust and TypeScript clients preserve the same nominal operation:
let result = rust_client.orders().get(request).await?;const result = await typescriptClient.orders.get(request);Follow Generate and use an SDK client. To author executable bodies, read add implementations and dependencies and toolchains.
Canonical owner: Contracts.