# `.one` source files

`.one` is one bounded source envelope for semantic documents and isolated
executable source. It replaces neither the semantic ownership model nor the
internal semantics of embedded languages.

## Three forms, one parser

The source format has three authoring modes:

1. compact semantic-only source: one implicit semantic section;
2. compound source: explicit semantic and/or executable sections;
3. inline `one!` in Rust: one System IDL semantic region only.

Compact, compound, and inline semantic source use the same lexer, parser,
lossless Rowan tree, and owner-validation path. They are not compatibility
formats or parallel grammars.

## Compound source

```one
one 1

semantic Contracts {
    domain contracts
    namespace acme.orders
}

semantic Implementation {
    domain implementation
    namespace acme.orders
}

code OrdersRust language rust 2024 <<RUST
// exact Rust source bytes
RUST

code RiskPython language python 3.13 <<PYTHON
# exact Python source bytes
PYTHON
```

The section labels are source-local locators, not semantic identities. Every
semantic document still selects one primary domain and namespace.

## Exact executable framing

Executable bodies use bounded heredoc framing. The opener chooses a delimiter.
The closer is a line containing exactly that delimiter followed by LF, CRLF,
or end of input.

The body begins after the opener line ending and ends before the first byte of
the valid closer. One performs no indentation, newline, escape, or Unicode
normalization.

Generic tooling can therefore preserve an unfamiliar language byte-for-byte
without trying to understand its strings, comments, braces, or interpolation.

## Co-location grants nothing

Sections in one file do not share:

- lexical scope or mutable state;
- imports or package dependencies;
- semantic identity or ownership;
- implementation association;
- root reachability or provider selection;
- capabilities, grants, or runtime authority.

Same-language helpers compose through that language's explicit dependency
model. Cross-language code interacts through an exact selected contract and
static, Component Model, native ABI, process, or remote boundary.

## Stable and refreshable coordinates

Body and semantic-section digests are canonical inputs. The whole-source
receipt, section labels, absolute ranges, and source-unit diagnostic maps are
refreshable provenance.

Moving an unchanged section or editing an unrelated sibling updates
containment and source mapping without invalidating the section's semantic or
program-analysis identity.

Canonical owner:
[System IDL](https://github.com/muijf/one/blob/main/systems/system-idl/AGENTS.md).