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 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 or choose the implementation guide that fits your product—services, data systems, durable work, agents, or applications—then check, test, and invoke.