# Add implementations

An implementation item associates an isolated source body with one exact
semantic target and one exact implementation-language profile. It is an
untrusted claim, not selected behavior, a Build artifact, or runtime authority.

## Write the fixed envelope

```one
one 1

impl acme.orders#OrdersRust@1
    realizes acme.orders#Orders@1
    using one.language.rust#OwnedAsync@1
    config
        edition = 2024
        warnings = deny
    dependencies
        cargo.serde
        cargo.tokio = >=1.40,<2
            feature macros
            feature rt-multi-thread
    toolchains
        rust = 2024
    source
        // ordinary Rust body
```

The clause order is fixed: `realizes`, `using`, optional `config`, optional
`dependencies`, optional `toolchains`, then final `source`. `realizes` selects
the semantic obligation. `using` alone selects the language definition and
profile; One never guesses from syntax, filename, namespace, or body contents.

## Keep configuration typed

The profile publishes a closed schema for `config`: field identities, value
kinds, defaults, bounds, secret/reference policy, and exact analysis, Build,
runtime, or presentation consumers. Unknown, duplicate, misplaced, and
inapplicable fields fail before analysis.

Configuration is not an unclassified string map, environment-variable bag,
tool dotfile, command fragment, provider choice, or grant. Editor navigation on
each field reaches its profile definition and use path.

## Derive and constrain dependencies

The selected language analyzer derives dependency demands from imports,
macros, plugins, native links, tests, generated interfaces, assets, and target
requirements. Add an implementation-local dependency only when analysis
cannot derive it, when a role or feature must be explicit, or when the body
needs a narrower constraint.

An entry without `=` uses project and published-package policy. An entry with
`=` intersects a local constraint with those policies and the derived demand;
it cannot widen them. Every resolved edge retains its consumer, role, reason,
qualifiers, effective constraint, exact release, and provenance.

Resolver and toolchain namespaces come from ordinary exact imports in
`one.one`. Rust, TypeScript, Python, and third-party ecosystems use the same
public dependency, toolchain, analysis, Build, and definition contracts.

## Preserve the source body exactly

The `source` suite is framed, not parsed by the `.one` semantic frontend. One
removes exactly the mandatory envelope indentation and preserves every
remaining byte, line ending, blank line, tab, brace, and language-native
delimiter. A nonblank dedent ends the body.

The formatter may move the whole body with its item but never reformats its
logical bytes. Language diagnostics map back through the framing source map.
The raw framed digest, logical-body digest, claim revision, dependency closure,
analysis receipt, Build artifact, binding, and execution receipt remain
separate identities.

## Understand language support levels

A language may support only generated contract values and clients, may host
service or activity workers, may implement the restricted portable workflow
API, or may be admitted as a complete implementation-body language. These are
distinct claims.

Rust is the canonical implementation language. Native One supplies a bounded
safe async language for ordinary contract logic and portable execution. Peer
languages such as TypeScript and Python use owner-qualified public profiles,
analyzers, toolchains, packaging, runtime bridges, conformance, and evidence.
A client SDK alone does not make a language a full implementation language.

## Follow the trust path

Checking validates the body framing, exact profile, dependency closure,
configuration, analysis completeness, exports, imports, effects, capabilities,
and target applicability. Composition determines reachability. Planning
selects a realization. Build materializes it through exact actions. Authority
issues only the applicable grant. Runtime binding and receipts prove later
stages separately.

First-party implementations have no private switches, hardcoded dispatcher,
implicit admission, or privileged normalizer output. A third-party profile can
replace a One-owned one through the same public role contracts without changing
an agnostic project builder or CLI.

Next: learn [Native One](/one/authoring/native-one) or choose the implementation
guide that fits your product—[services](/one/guides/services),
[data systems](/one/guides/data-systems),
[durable work](/one/guides/durable-work),
[agents](/one/guides/agents-and-automation), or
[applications](/one/guides/applications)—then
[check, test, and invoke](/one/lifecycle/check-test-invoke).