Sley

How Sley works

How agents change Sley programs

From a verified state through a proposed change and a validated transaction to a new verified state, in seven checked steps. Sley 2.1.7.

Install SleyTry it in your browserWrite Sley like Python

The model, then hands-on

Learn the model here. Run it with the Quickstart.

The Sley kernel runs the lifecycle below, and sley serve exposes each step as an SMP1 method, in binary frames or, with --json, JSON lines. The sley CLI is a thin wrapper; the kernel makes every decision.

To install sley and run the release demo, follow the Quickstart or the install steps. To write a first program, start with Sley's Python dialect. Source: github.com/sley-lang/sley (Apache-2.0).

The governed lifecycle

State → Proposal → Validation → Transaction → Verified State

Every Sley 2 change takes this path, whether the agent wrote a Python-dialect file, a familiar-syntax file or an AF1 frame. State moves only at the commit, after validation, and the commit leaves a receipt.

  1. Begin from a verified state root. Use an immutable, deterministic StateRoot derived from SCB1 canonical bytes. The root ignores history: the same state has the same root however it was reached, and a clone reproduces it exactly.
  2. Ask for bounded context. Run root-backed typed queries (query.root and friends) or request a context capsule. Every response carries an exact query ID and reports what it returned, omitted or truncated; a response that will not fit fails with PROTOCOL_LIMIT_EXCEEDED. Indexes are derived caches and never grant authority.
  3. Construct a proposal-only mutation candidate. A candidate (candidate.create) holds ordered typed mutations over the base root, built from generated descriptors for every entity kind and field. Preconditions such as "this entity is still at version X" make stale edits fail. The candidate cannot grant itself authority or change the rules that judge it.
  4. Run deterministic validation. The fourteen-phase validator (candidate.validate) runs in order: canonical frame, schema and limits, stale base and preconditions, identity, graph and references, types, control flow, effects, protected capability and policy, contracts, test planning, resource analysis, candidate-root construction, and the final result digest. A refusal names one failed phase and a stable decision.
  5. Commit through the atomic transaction boundary. commit revalidates, stages and verifies immutable objects, writes and syncs a receipt, syncs directories, and only then compare-and-swaps the head. A crash yields the old state or the complete new one.
  6. Branch, compare, merge, and exchange. Named branches advance by compare-and-swap from their direct parent. Compare is semantic. Merge is deterministic and turns ambiguity into explicit conflict objects. Exchange exports a pack that clones to exact roots.
  7. Retain deterministic receipts and evidence. Canonical transactions and receipts, observation digests from the deterministic VM (execute, report) and query capsules are the evidence for accepting or rejecting the change.

Good to know

  • The Sley 2 CLI is version, hello, methods, frame and serve. Commands like sley doctor or sley lint belong to Sley 1.x.
  • Frame bodies, the handshake and the JSON bridge: see the Quickstart and the SMP1 spec in the docs index.
  • Host access runs through bounded, typed adapters.
  • Since 2.1.0, the semantic toolchain is itself a Sley program that rebuilds itself. See the self-hosting record.

Which component owns each step

  • State & storage: sley-store, sley-state-root, sley-id
  • Representation: sley-scb1, sley-ssmc, sley-schema + the independent Python oracle
  • Queries & capsules: sley-query
  • Mutation candidates: sley-mutate
  • Validation: sley-check + sley-policy
  • Transactions & receipts: sley-txn
  • Branches, compare, merge, exchange, GC: sley-repo
  • Execution: sley-vm; host adapters: sley-adapter
  • Protocol & CLI: sley-protocol, sley-json-bridge, sley-cli (thin wrapper, no semantic rules)
  • Self-hosted toolchain: sley-selfhost; pinned host: sley-host

The lifecycle at a glance

Verified State→ Proposal→ Validation→ Transaction→ New Verified State

Bounded queries and capsules inform the proposal. Policy roots and capability tokens gate validation. Atomic commit and branch compare-and-swap publish the result, and receipts, reports and capsules are the evidence agents keep.

Next

Run it: the Quickstart goes from install to a passing release demo and a hand-driven sley serve session.

The docs cover the Python dialect, representation, identity, checks, execution, authority and release status; Concepts has the full model and glossary.

The human-readable 1.x line: Sley 1.x Legacy.