Core product terms
Application root
An independently closed, planned, built, authorized, deployed, and inspected unit such as a server, client, worker, job, tool, or plugin.
Artifact
A Build-owned materialized output with exact content identity, closure, provenance, and verification evidence.
Binding
The exact relationship between a selected provider realization and a concrete runtime endpoint or resource instance. A binding is not a grant.
Build report
Build's canonical record of an exact root selection, action graph, artifact closure, authority, provenance, verification, and realized outputs. Artifact bytes alone are not a Build report.
Contract
An owner-qualified statement of meaning and obligations: schemas, operations, faults, effects, compatibility, lifecycle, evidence, or another public boundary.
Compatibility lane
The continuing compatibility line named by authored @N, such as Order@1.
The lane is not an exact immutable revision; one.lock selects that revision.
Convergence
The state in which sufficiently fresh admitted observations satisfy a release plan's semantic postconditions. Provider acceptance and workload readiness can be inputs to convergence but do not imply it.
Definition reference
A snapshot-bound link from source, a generated symbol, a command, or an owner record to its exact defining package, export path, revision, laws, and applicable proof or projection path.
Effect
An externally meaningful action tracked from intent through authorization, dispatch, acknowledgement, observation, and reconciliation.
Evidence
An attributable, scoped record supporting one exact claim under stated inputs, environment, issuer, freshness, and policy. Evidence never proves more than its declared claim.
Grant
Authority for an exact principal, binding subject, capability scope, effect class, audience, environment, and validity window.
Implementation item
An isolated .one item whose header claims that one stable implementation
realizes one semantic target using one exact language profile. The claim and
body are untrusted until later stages admit them.
Implementation profile
An owner-qualified language contract defining source interpretation, configuration, analysis, dependency and toolchain support, Build, runtime, target, sandbox, and evidence obligations for an implementation body.
One Contract Schema (OCS)
The canonical language-neutral schema and frame model used for generated projections and selected process or remote boundaries.
Operation
An owned callable contract with nominal input and output, domain faults, effects, deadlines, cancellation, idempotency, authority, and evidence obligations. An operation does not imply a network boundary.
Plan
An immutable, owner-validated decision record. A project plan selects realizations; a release plan fixes placement, grants, actions, postconditions, and reconciliation. A plan is never mutation authority by itself.
Provider
A replaceable physical realization of an owned capability contract.
Provider profile
A precise provider claim qualified by version, configuration, target, environment, limits, authority, cost, lifecycle, conformance, and evidence.
Quantity
An exact dimensional value such as 30s, 16MiB, 100MiB/s, or 5USD whose
unit, conversions, comparisons, and arithmetic are owned by an imported
semantic definition.
Reconciliation
The fenced comparison of desired and observed state followed by only those transitions admitted by an immutable plan, with durable intent, results, and postcondition evidence.
Receipt
An owner-issued inspectable record that an exact action, projection, binding, observation, or transition occurred under stated inputs and conditions.
Requirement
A provider-independent need inferred for one root. It does not choose a provider or grant permission.
Resource
An owned entity with stable identity, lifecycle, containment, borrowing, transfer, availability, and cleanup obligations.
Root closure
The fixed point of semantic, implementation, provider, schema, codec, artifact, resource, permission, and Build reachability computed independently for one application root.
Semantic domain
The owner of a closed declaration vocabulary, schemas, normalization rules, compatibility, and meaning. One-owned and organization-owned domains use the same meta-contract without sharing ownership.
Semantic item
A non-executable .one item that selects one namespace and one primary
semantic domain.
Semantic trait
A postfix owner-defined refinement such as @Length, @Key, or @Invariant.
It is accepted only through one exact applicable trait implementation and is
not ignorable annotation metadata or a Rust trait.
Selection intent
Reviewed root- and demand-scoped provider preference or restriction authored
in Planning-owned .one source. Absence means automatic deterministic
selection; intent never makes an ineligible provider eligible.
Selection lock
Planning's exact commitment to the root-reachable semantic inputs, implementation candidates, mappings, provider catalog, topology, choices, and proofs.
Source transaction
An atomic, revision-checked patch to canonical .one source followed by exact
parsing and owner validation.
Workspace
A bounded aggregation of existing projects for selection and authority-free batch operations. It does not merge their source, locks, roots, closures, authority, or evidence.
Failure and evidence terms
Domain fault
A declared operation outcome. It is distinct from denial, cancellation, deadline, transport, provider, compatibility, and platform defects.
Missing evidence
The owner record or proof needed to support a claim is unavailable. One does not reconstruct it from weaker-stage values.
Outcome unknown
An effect may have crossed its external boundary, but acknowledgement or postcondition evidence is absent or ambiguous. Observation and reconciliation must precede unsafe retry or failover.
Unsatisfied
The requested contract is supported in principle, but no eligible realization meets the exact root's constraints.
Unsupported
No declared contract or implementation path can provide the requested behavior with the required semantics.
Lifecycle shorthand
D-IR → S-IR → R-IR → L-IR → P-IR → A-IR → DPL-IR → REC-IR
The owner-separated lowering path from accepted declaration through normalized meaning, requirements, realization choices, artifacts, placement, and reconciliation.
Illustrative inspection retains every stage rather than replacing it with one digest:
declaration parcelhub.orders#OrdersApi@1
requirement requirement:sha256:…
realization provider-realization:sha256:…
artifact artifact:sha256:…
deployment deployment:operation:sha256:…
receipt effect-receipt:sha256:…