# Check, test, and invoke

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

```console
one check
```

Checking 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:

1. parses the lossless source envelope;
2. resolves the primary domain, inherited language, imports, public name table,
   traits, applicability implementations, and exact package revisions;
3. normalizes each semantic item through its selected domain owner;
4. validates every proposed owner contribution and admits the exact result to
   Knowledge with source, definition, normalization, and contribution receipts;
5. computes definition-ordered references, schemas, contracts, effects, roots,
   composition edges, and per-root semantic closure;
6. analyzes reachable implementation bodies through their exact language
   profiles and source closure;
7. derives dependency and toolchain demands and checks them against the atomic
   lock without mutating it; and
8. 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

```console
one test
```

Testing 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

```console
one invoke <operation-id> request.json
```

Invocation 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](/one/examples/service) for a complete
declaration-to-invocation walkthrough and
[Handle failures](/one/examples/failure-handling) for negative scenarios.

Authoring prerequisites: [the `.one` source language](/one/authoring/source-language),
[domains and traits](/one/authoring/domains-and-traits), and
[implementations](/one/authoring/implementations).

Canonical owner:
[Developer Interface](https://github.com/muijf/one/blob/main/systems/developer-interface/AGENTS.md).

Next: automate the same evidence path in
[CI and release automation](/one/guides/ci-automation), then
[plan, build, and apply](/one/lifecycle/plan-build-apply).