Skip to content
Documentation.one source files
On this page

Page resources

Open Markdownllms.txtView source

Last updated

.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 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.