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.
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.