The machine-native lifecycle - step by step

Pre-release surface

The current public surface is an inspectable pre-release implementation, not an installed language release.

No authorized installable user-facing CLI, package, or GA is claimed. The repository exposes the kernel crates, typed descriptors, candidate proposal APIs, validator, and transaction engine for inspection. Wrappers such as sley-cli remain thin machine adapters that delegate all judgment to the kernel - they are not the source of truth. Follow this walkthrough as the architecture, not as a stable end-user API.

All seven steps below use only real implemented public-safe operations at GreyforgeLabs/sley (2.0.0-alpha.0, LicenseRef-Proprietary).

The governed lifecycle

State → Proposal → Validation → Transaction → Verified State

Every Sley 2 change traverses this boundary - proposal before mutation, validation before commit, human governance before acceptance.

1. Begin from a verified state root. Use an immutable deterministic StateRoot derived from SCB1 canonical bytes. Roots are ancestry-independent; bindings are order-independent; packing round-trips the exact root.
2. Derive the bounded information needed for a change. Rebuild SLEYIDX1 index snapshots and run the four restricted typed queries. Responses contain exact QueryId records, canonically ordered payloads, raw-ID dictionaries, and direct-edge tables with fixed no-omission/no-truncation/no-continuation. Derived state is disposable - it never grants authority.
3. Construct a proposal-only mutation candidate. Build a SLEYCAN1 candidate from the exact frozen manifest - 179 immutable descriptors over 18 kinds and 75 fields, 16 primitive classes, sixteen mutation payloads, and thirteen record fields - checking contiguous ordinals, deterministic creation IDs, and the frozen validation-profile ID. The construction performs no semantic validation, authority judgment, or state mutation.
4. Run deterministic validation. The fourteen-phase restricted validator (S20-360) owns every outcome: pure apply/reference/type/CFG/effect/policy/capability/contract/test/root judgments run in order. Unsupported semantic operation analysis and production fingerprint gaps fail closed; invalid candidates leave capability ledgers unchanged.
5. Commit through the atomic transaction boundary. Fresh commit-time revalidation, durable immutable-object and receipt ordering, 19-field parent-bound Transaction and 9-field Receipt with non-cyclic IDs, and one fixed-head CAS. A crash yields old or complete new state - never partial accepted state (19 transaction tests, independent oracle checker, persistent importer fuzz).
6. Advance a native branch ref where authorized. Atomic lowercase-ASCII named refs with immutable origin records, verified mutable refs, direct-parent fast-forward CAS, deterministic bounded ancestry, and repo maintenance coordination. No merge, force-reset, tags, or pack-exchange path is exposed.
7. Retain deterministic receipts and state identity. Canonical transaction/receipt digests, observation digests, query responses, and restricted evidence capsules provide the evidence humans review to accept or reject the change.

What this walkthrough does not do

• No invented stable CLI - commands like sley doctor, sley ast, sley graph, sley plan, sley fix, sley lint, sley verify are legacy Sley 1.x and do not describe the active Sley 2 product.
• No Rust library calls presented as a stable end-user API.
• No live provider/shell/network/deployment authority is implied - policy roots and capability tokens are deterministic, bounded, and local.
• No SMP1 framing, JSON mapping, or clone-exchange is walked - those are designated future protocol layers.

Where to inspect each step

• State & storage: sley-store, sley-state-root, sley-repo - see store & repo
• Representation: sley-scb1 + oracle - SCB1.md
• Mutation descriptors & candidates: sley-mutate + S20-340/350/345 conformance corpora
• Validation: sley-check + sley-policy - S20-360 fourteen-phase validator
• Transactions & receipts: sley-txn - S20-390 independent oracle & five-boundary fault matrix
• Branches: sley-repo/refs.rs - S20-500 native branch refs
• Queries & capsules: sley-query - S20-310/320 restricted snapshot/query/capsule
• Execution: sley-vm - S20-260/270 restricted lowering & VM

Lifecycle diagram - machine acts, human governs

Next

Read the Sley 2 Technical Brief for representation, identity, checks, execution, authority, and the exact completion boundary - or consult docs/WORK_PACKAGES.md for every work package.

For the frozen human-readable lineage, see Sley 1.x Legacy.