# Languages and SDKs

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:

```rust,ignore
let result = rust_client.orders().get(request).await?;
```

```typescript
const result = await typescriptClient.orders.get(request);
```

Follow [Generate and use an SDK client](/one/examples/sdk-client).
To author executable bodies, read
[add implementations](/one/authoring/implementations) and
[dependencies and toolchains](/one/reference/dependencies-toolchains).

Canonical owner:
[Contracts](https://github.com/muijf/one/blob/main/systems/contracts/AGENTS.md).