Executable sections#

Executable sections let one .one source unit contain native-One and foreign implementation source without merging languages or weakening the semantic trust boundary.

Language definition and implementation profile#

An executable header names a versioned SourceLanguageDefinition. It owns the language's grammar and static-semantics identity, module model, frontend contracts, bounds, and diagnostics contract.

A separate semantic implementation declaration names an ImplementationLanguageProfile. That profile 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 source header does not select a tool 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 recommended first target is a typed contract function compiled to a WebAssembly component with an exact, receipted WIT projection.

Foreign languages remain native#

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.

Analysis before selection#

An executable candidate follows:

body + dependency closure
  -> sandboxed analyzer candidate
  -> bounded structural admission
  -> language/profile owner validation
  -> Composition activation
  -> Planning selection
  -> 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.

Code-only and helper sections can receive syntax and formatting support without an implementation claim. Claim-aware type/effect checking additionally needs the expected contract, profile, dependency closure, and analysis envelope.

Canonical owners: System IDL, Contracts, and Build.