Skip to content
DocumentationHow One works
On this page

Page resources

Open Markdownllms.txtView source

Last updated

How One works

One keeps meaning, requirements, realization, authority, runtime behavior, and evidence separate so each can be inspected and replaced independently.

One owner for every contract

Every stable identity, schema, operation, effect, provider claim, plan node, artifact, grant, observation, and fact has one semantic owner. Other systems refer to its public contract and exact revision.

Organizations can own peer semantic domains. Using the common .one grammar does not transfer their meaning to One.

Eight owned representations

D-IR -> S-IR -> R-IR -> L-IR -> P-IR -> A-IR -> DPL-IR -> REC-IR
StageQuestion
D-IRWhat accepted declaration did the author provide?
S-IRWhat is its normalized, owner-validated meaning?
R-IRWhat does one exact root require?
L-IRWhich provider-independent realization shapes are valid?
P-IRWhich exact providers, topology, and targets are selected?
A-IRWhich exact actions and artifacts materialize that selection?
DPL-IRWhere are artifacts placed and grants bound?
REC-IRWhich fenced actions reconcile desired and observed state?

Runtime state and historical facts are not extra planning stages. No earlier record is accepted as later-stage authority.

Per-root closure

Closure is computed independently for every application root and deployable. An unrelated workspace package, Cargo feature, provider, schema, codec, permission, or artifact cannot enter through ambient discovery.

A browser root therefore cannot inherit server secrets merely because both are built from one repository.

Requirements are not grants

The security path has four distinct links:

requirement -> grant -> runtime token -> host enforcement

A declaration may prove that network access is required. It cannot issue that access. Planning selects the need, Authority governs the grant, the runtime receives a scoped token, and the host enforces it.

Source is not realization

An executable section becomes usable through this path:

source descriptor
  -> explicit implementation claim
  -> language/profile analysis receipt
  -> root-visible candidate
  -> physical selection
  -> build artifact and conformance
  -> binding and runtime authority

A successful parse, type check, or compilation cannot skip a stage.

Defaults remain explanations

The ordinary path should be easier than assembling equivalent plumbing by hand, but convenience does not hide allocations, dynamic dispatch, network hops, authority, failure, provider selection, or cost.

Every default and inference keeps a source or proof edge. one inspect <subject> --explain follows those public edges.

Failure remains honest

Expected domain faults remain separate from admission, cancellation, deadline, provider, transport, compatibility, unknown outcome, and defects. Dropping a future is not rollback after an effect may have been dispatched.

When an exact realization is absent, One returns typed unsupported, unsatisfied, or missing-evidence output. It never simulates success or silently omits the boundary.

Canonical owners: root composition, Knowledge, and Planning.