# Implementation items

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](/one/language/sdks).

## Analysis before selection

An implementation candidate follows:

```mermaid
flowchart TD
    body[Body + dependency closure]
    body --> analyzer[Sandboxed analyzer candidate]
    analyzer --> admission[Bounded structural admission]
    admission --> validation[Language/profile owner validation]
    validation --> composition[Composition activation]
    composition --> planning[Planning selection]
    planning --> build[Build and artifact conformance]
```

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](https://github.com/muijf/one/blob/main/systems/system-idl/AGENTS.md),
[Contracts](https://github.com/muijf/one/blob/main/systems/contracts/AGENTS.md),
and
[Build](https://github.com/muijf/one/blob/main/systems/build/AGENTS.md).