# 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:

```text
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](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).