Implementation items let one .one source unit contain native One and
peer-language implementation source without merging languages or weakening
the semantic trust boundary.
Language definition and implementation profile
One fixed header names a stable implementation identity, the exact semantic
target it claims to realize, and one ImplementationLanguageProfile after
using. The profile is the sole authored language selector and references:
- the exact source-language definition;
- one exact contract projection profile;
- permitted source and package closure;
- target, runtime, ABI, effects, capabilities, and sandbox obligations;
- required analysis, build, conformance, and admission evidence.
The header creates an untrusted claim and associates its one body slot. It does not resolve the profile, select a tool, activate the implementation, or prove conformance.
Native executable One
Native One is one coherent implementation language owned by System IDL. It has its own grammar, name and module resolution, type/effect rules, and checked program representation.
It consumes exact One Contract Schema types, operations, faults, effects, and capability contracts. Profiles may constrain targets but cannot reinterpret the core language.
Native One is not a universal transpiler. The current application path checks bounded unary programs and builds the exact artifact form selected by the root: verified Native One bytecode for the admitted interpreter, or a WebAssembly Component for the admitted Wasmtime host. The paths retain separate Planning-owned protocol identities and cannot substitute for one another. Component interfaces are exact receipted projections of OCS.
Peer languages retain their own semantics
Rust remains Rust; Python remains Python; TypeScript remains TypeScript. Each language uses its own exact frontend, package model, toolchain, and implementation profile.
One unifies their semantic contracts and makes their boundaries explicit. It does not promise that arbitrary values, effects, ownership models, exceptions, threads, or runtimes map without loss.
A generated client or value SDK is a projection for that language, not proof that implementation bodies in the language can be analyzed, built, hosted, or admitted. Complete implementation-language support additionally requires its exact frontend/toolchain, dependency, runtime, conformance, and evidence path. See SDKs and language support.
Analysis before selection
An implementation candidate follows:
The canonical analysis receipt commits the claim, source closure, language, profile, expected OCS interface, analyzer, configuration, target applicability, diagnostics, exports, imports, effects, capabilities, and result.
Source-unit ranges and diagnostic mappings remain separately refreshable provenance.
Tool trust is explicit
one.lock can resolve exact parser, analyzer, and formatter implementations
plus Providers-owned package and trust evidence. Per-run sandbox execution
evidence belongs in the tooling or analysis receipt, not the dependency lock.
There are no code-only or helper items. Reusable source enters through the selected language's explicit module or package dependency model. Claim-aware type/effect checking additionally needs the expected contract, profile, dependency closure, and analysis envelope.
Canonical owners: System IDL, Contracts, and Build.