The first half of the One lifecycle proves that authored meaning is valid and that selected behavior satisfies it before the system is released.
Check the project
one checkChecking starts from one.one, the selected .one source, and the exact
one.lock. The entry file first passes through the ordinary .one envelope
parser and the built-in one.project@1 project-domain lowering; its project
declaration then supplies the exact source and lock paths. It:
- parses the lossless source envelope;
- resolves the primary domain, inherited language, imports, public name table, traits, applicability implementations, and exact package revisions;
- normalizes each semantic item through its selected domain owner;
- validates every proposed owner contribution and admits the exact result to Knowledge with source, definition, normalization, and contribution receipts;
- computes definition-ordered references, schemas, contracts, effects, roots, composition edges, and per-root semantic closure;
- analyzes reachable implementation bodies through their exact language profiles and source closure;
- derives dependency and toolchain demands and checks them against the atomic lock without mutating it; and
- reports source-mapped diagnostics, definition paths, proof obligations, and owner-qualified unsupported cases.
Checking is read-only. It does not execute operations, select providers, create artifacts, or grant authority. A proposed lock change is reviewable and separate from acceptance.
Test the application
one testTesting composes evidence owned by the selected root: unit and property tests, schema and codec conformance, provider suites, fault injection, integration tests, deterministic workflow histories, effect fixtures, and exact replay.
These evidence classes remain distinct:
| Evidence | What it can establish |
|---|---|
| Unit/property test | Behavior under the exact tested implementation and inputs |
| Contract conformance | Satisfaction of one public owner contract and profile |
| Simulation/fault campaign | Behavior inside an explicit model, seed, scheduler, and fault envelope |
| Benchmark | Controlled comparative measurements under an exact environment and methodology |
| Integration/application test | Behavior of one exact selected root closure |
| Production observation | A bounded assertion about an actual release at an exact time and source |
Benchmark evidence may influence Planning only when the requirement and policy accept its workload, environment, freshness, and independence. A faster result does not override a hard semantic, security, authority, or recovery constraint.
Every system and package remains independently testable. Cross-system behavior
has a deliberately named owner, while final application acceptance starts from
the same one.one lifecycle a user runs.
Simulation never becomes production evidence. Simulated clocks, entropy, transports, stores, identity, or effects are explicitly marked, isolated by policy, and barred from minting production receipts or observations.
Invoke one exact operation
one invoke <operation-id> request.jsonInvocation resolves an exact root-reachable operation. The developer interface may compose the necessary planning, Build, binding, runtime, and scoped local authority steps, but each owner still constructs and validates its own record.
The result preserves distinct failure classes:
| Class | Meaning |
|---|---|
| Domain fault | The operation ran and returned a declared business outcome |
| Admission or policy denial | Required trust or authority was not granted |
| Deadline or cancellation | The invocation did not complete within its execution contract |
| Compatibility or transport failure | The selected boundary could not carry the call |
| Provider unavailable | A selected realization could not serve the request |
| Outcome unknown | Dispatch may have happened; reconciliation is required |
| Defect | An invariant of One, an implementation, or a provider was violated |
Dropping a future is cancellation, not rollback. Retrying after dispatch is safe only with proof of non-application or an exact idempotency, deduplication, outcome-query, journal, and fencing contract.
Reuse exact evidence
An invocation may consume an already authorized realized Build report instead of rebuilding. Reuse validates artifact integrity, operation reachability, provider realizations, runtime bindings, and fresh invocation authority. It is not an implicit cache hit or reuse of release authority.
Follow Build a typed service for a complete declaration-to-invocation walkthrough and Handle failures for negative scenarios.
Authoring prerequisites: the .one source language,
domains and traits, and
implementations.
Canonical owner: Developer Interface.
Next: automate the same evidence path in CI and release automation, then plan, build, and apply.