Guarantees and boundaries

The first-release model combines the supported Rust profile, durable execution, explicit effects, scoped authority and development tools. A guarantee applies to the relevant runtime version, execution route and stated conditions.

Release perspective

This documentation describes the integrated first-public-release target, with the active runtime, authority, development and ecosystem programmes completed and qualified together. Concept pages use that target to explain how the pieces fit.

Runnable tutorials preserve the currently documented effectful command surface and state their prerequisites. Feature and distribution availability depend on the installed runtime version. A first-release design statement is not evidence that an earlier build already implements or qualifies it.

Language and development

Claim	Meaning	Boundary
Build with Rust	Code uses Rust within a supported profile	Arbitrary Rust programs and Cargo dependency graphs are not automatically admitted
Rust safety foundations	Types, ownership checks and defined semantics reduce specific bug classes	Memory safety does not establish business correctness or eliminate all security failures
Zero-build loop	Supported application and library edits use an installed runtime	Checking and lowering remain; runtime and native components have separate builds
Exact code identities	Defined artifacts and dependencies have exact content identities	Identity does not prove benign behaviour or publisher authenticity

Execution and authority

Claim	Meaning	Boundary
Deterministic core	Computation has defined semantics under its execution contract	Environmental inputs and external delivery need explicit rules
Durable execution	State and progress persist within the storage and recovery contract	No universal exactly-once external delivery or total-disk-loss recovery is implied
Actor boundaries	State ownership and message contracts give the system explicit structure	No automatic OS sandbox, independent deployment or freedom from resource exhaustion
Scoped capabilities	Grants and authenticated context constrain permitted operations	A declaration is not a grant; native host authority remains part of the trust boundary
Inspectable communication	Declared, permitted and observed views answer distinct questions	A diagram is not proof of complete field-level information-flow control

Evidence

Evidence	What it can establish	Conditions to retain
Type or profile check	Acceptance under the checked rules	Exact inputs, route and checker identity
Test	Observed behaviour for selected cases	Inputs, expected result, execution origin and environment
Replay	Reconstruction under recorded inputs and execution rules	Retained history, code and applicable replay contract
Benchmark	Performance for a measured workload	Workload, state and log sizes, hardware, configuration and samples
Formal proof	A stated property under formal assumptions	The model, proved property and scope of connection to implementation
Live observation	Behaviour in a particular operating context	Time, deployment identity, coverage and collection limits

These forms of evidence are complementary. One does not silently stand in for another.

Security boundary

The trusted runtime, native hosts and drivers, secret handling, storage and deployment environment belong in the system’s threat model. Narrow capabilities can limit code’s reach within the enforced runtime boundary. They do not remove the need to review trusted components.

Authority for completing admitted work and authority to disclose protected data can differ. Inspection and retained history must respect that distinction.

Scope beyond the first release

Cross-node execution, a managed cloud, recovery after losing all local storage, arbitrary Rust compatibility and a complete graph query-and-rules language are separate milestones. Building a web framework on the foundation is different from shipping a bundled Rails-like framework.

Comparative security or performance claims require a defined threat model or workload and reproducible evidence. The architecture alone does not establish overall superiority over another system.