A Sley 2 program lives as typed semantic state: program form SSMC1, encoding SCB1, machine interface SMP1. Agents read it through bounded queries and change it by proposing typed mutations, and a deterministic kernel checks every proposal before anything commits.
Agents can write those changes the way they already write code. A typed Python-dialect file, a compact familiar syntax or an AF1 JSON frame compiles into proposed changes to the same graph. Sley stores, validates and versions the graph, and generates diagnostics, receipts, reports and capsules from it on demand.
Install & quickstart
Install sley and sley-agent
Sley 2.1.7 ships static (musl) sley and sley-agent binaries for Linux x86_64 with no runtime dependencies; the demo needs Python 3. Download sley-2.1.7-linux-x86_64.tar.gz and SHA256SUMS from the v2.1.7 release page. Use the checksum file from that same release; --ignore-missing checks only yours (SHA-256 a44b76e070228e2924c7efe16319d5339b233abf1e45986431c59a4c88460923):
sha256sum -c --ignore-missing SHA256SUMS # prints "sley-2.1.7-linux-x86_64.tar.gz: OK"
tar xzf sley-2.1.7-linux-x86_64.tar.gz
cd sley-2.1.7-linux-x86_64
./bin/sley version
./bin/sley-agent help
python3 demo/run_demo.py # the release demo; reports "result": "PASS"
Or build from source (Rust toolchain pinned by the repository; Python 3 for the demo). In a source checkout the demo lives under bench/release/:
git clone --branch v2.1.7 --depth 1 https://github.com/sley-lang/sley.git && cd sley && cargo build --release -p sley-cli -p sley-agent
./target/release/sley version
./target/release/sley-agent help
python3 bench/release/run_demo.py --sley target/release/sley --fixture conformance/release-demo/v1/demo.json
In two empty directories, the demo imports a small program, runs a root query, executes a function and reads back its stored report, branches, exports, clones into the second directory, runs a GC dry run, and checks that the clone answers byte for byte. "result": "PASS" means every answer matched the fixture.
Concepts explains the model, and the Quickstart adds sley serve over JSON lines, a Python client and the test gates.
On macOS, Windows or another platform, play Sley Arena in your browser: every Arena bot is a Sley program, compiled and tested right on the page.
Write → test → call
Write Sley like Python
Since 2.1.1, sley-agent try --familiar compiles typed Python into Sley's program graph. Functions take type hints (int, bool, str, list[int] and @dataclass records), and each def test_*(): function of assert lines becomes a test. Integers are 64-bit, and overflow traps.
Put the release binaries on your PATH (export PATH="$PWD/bin:$PATH" in the unpacked archive), then save this as gcd.py in a new directory:
gcd.py
def gcd(a: int, b: int) -> int:
while b != 0:
a, b = b, a % b
return a
def test_gcd():
assert gcd(12, 18) == 6
assert gcd(7, 5) == 1
assert gcd(0, 9) == 9
try compiles the file, validates the candidate and runs the three tests, printing c1: 3 passed (advisory) d1@r1. call runs gcd in the deterministic VM, and submit writes the tested candidate to final_candidate.hex. Rust hosts can compile and run the same source in memory, natively or in WebAssembly, with the sley_agent::embed API (embedding guide). Larger programs live in sley-lang/examples.
Author → test → submit
Write an AF1-X frame with sley-agent
Agents that prefer structured input write AF1-X JSON frames. Put the unpacked release binaries on your PATH before changing directories:
export PATH="$PWD/bin:$PATH"
For a source build, run export PATH="$PWD/target/release:$PATH" from the checkout root instead. Start in a directory with no demo workspace or area.json.
sley-agent help ships a checked area function as an AF1-X JSON authoring frame. Save it, edit the function and tests, and let the kernel validate the candidate. AF1 is input; typed semantic state stays canonical.
sley-agent init demo && cd demo
sley-agent help | awk '/^```json/{f=1;next} /^```/{if(f)exit} f' > ../area.json
# Review area.json: the AF1-X frame defines a function and three tests.
# Edit this frame to author your program, then validate it:
sley-agent try ../area.json
# For the guide's first successful candidate (c1):
sley-agent view area --after c1
sley-agent call area 3 4 --on c1
sley-agent submit c1
The unchanged example prints c1: 3 passed (advisory) d1@r1; the call returns {"Ok":12}. Use whatever handle your try prints, and fix any refusal before submitting.
sley-agent submit c1 writes final_candidate.hex. Test results here are advisory. In this release, sley-agent commit c1 refuses candidates selecting TestCases until authoritative native test evidence is available, so submitting this tested example does not change the accepted head.
Released Quickstart · sley-agent help prints the shipped example; sley-agent help afx covers compact authoring, and sley-agent help af1 and sley-agent help tests the frame and test references.
Self-hosted since 2.1.0
Sley builds Sley
Sley's semantic toolchain is a Sley program: decoder, type and graph checker, operation judge, lowerer, fingerprints and package builder. On a pinned host with no compiler inside, it rebuilds its own executable closure from its canonical graph to a byte-identical fixed point, without the Rust seed compiler.
The Rust seed builds C1, C1 builds C2, and C2 builds C3, the last two in an empty bubblewrap sandbox with the seed absent. All three are byte-identical. A typed change to the toolchain, rebuilt by the previous Sley toolchain, matches the seed's build exactly, and a fake builder that returns the old image is rejected.
Self-rebuild bundle: sley-2.1.0-selfhost-linux-x86_64.tar.gz, from the 2.1.0 release, repeats the build from its contents alone (the static sley-host, the toolchain image, the canonical graph and rebuild.sh). It needs bubblewrap.
tar xzf sley-2.1.0-selfhost-linux-x86_64.tar.gz
cd sley-2.1.0-selfhost-linux-x86_64
sha256sum -c SHA256SUMS
./rebuild.sh # about ten minutes; prints "fixed point: the rebuilt toolchain is byte-identical"
sley is a thin CLI for machines. Every command writes machine-readable output, and a CLI failure writes one JSON object to standard error. sley serve --json speaks SMP1 as JSON lines, one frame per line; without --json it speaks binary frames.
sley version print CLI and protocol identity
sley hello [--json] print the hello this endpoint offers
sley methods print the method table
sley frame decode|encode convert SMP1 frames: binary <-> JSON lines
sley serve --repository <dir> [--json] [--batch] [--report <file>]
A client's first frame must be a hello. Kernel failures travel inside failed answers as stable codes, separate from CLI failures.
Exit codes
sley process exit codes
Exit
Symbol
Meaning
0
-
Ran to end of input and answered every frame
2
CLI_USAGE_INVALID
Unknown command, flag, or value
3
CLI_INPUT_INVALID
Malformed or truncated input frame
4
CLI_IO_FAILURE
Read, write, or flush failure
5
CLI_HANDSHAKE_REQUIRED
The first frame was not a hello
Representation - SSMC1 / SCB1 / SMP1
SSMC1 (Sley Semantic Machine Code) is the only canonical program form: a typed, immutable graph of 18 entity kinds, including Function, Block, Operation, TypeDef, Contract and TestCase.
SCB1 (Sley Canonical Binary) is the only canonical byte encoding. It rejects malformed or non-minimal input rather than normalizing it. Hashes are domain-separated BLAKE3.
An independent Python oracle reproduces the Rust kernel's SCB1 bytes exactly across the conformance corpora.
SMP1 (Sley Machine Protocol) owns framing, version negotiation, sessions, bounds and cancellation. A JSON bridge maps each frame to one non-canonical JSON line.
Identity and storage
Every identity in Sley is exact, content-derived and domain-separated.
EntityId: stable logical identity. ObjectId: one immutable version's canonical bytes.
StateRoot: the complete semantic state, independent of history. The same state has the same root however it was reached.
TransactionId: one commit bound to its parent. SchemaEpochId: the rules that decode and judge a state.
An immutable, content-addressed object store. Pack import rebuilds exact roots and detects corruption before any ref moves.
A verified, deterministic StateRoot is the starting state.
A proposal is a candidate of ordered typed mutations over a base root, built from generated descriptors for every entity kind and field. Preconditions make stale edits fail.
Validation runs fourteen ordered phases, from canonical frame and stale-base checks through identity, graph, types, control flow, effects, policy, contracts, test planning and resources to the final result digest.
The transaction revalidates at commit time, stages and verifies objects, syncs a receipt, then compare-and-swaps the head.
The result is a new StateRoot and a canonical receipt binding parent, new root and validation evidence.
A crash at any point leaves the old state or the complete new one.
Semantic checks - deterministic judgment
Deterministic type checking, control-flow and value-use validation, exact effect closure, and contract checking.
Effects are part of a function's type, so every side effect shows up along the call chain.
An invalid result has a passed prefix, exactly one failed phase with a decision such as TYPE_ERROR, STALE_ROOT or CAPABILITY_DENIED, and a not-run suffix.
Validity is decided by the deterministic kernel alone.
Execution - deterministic VM
The same state and inputs produce the same observations, byte for byte, on every machine.
Functions lower to bytecode and run under explicit fuel, value, output and cancellation limits. Programs whose values all fit a machine word run on plain 64-bit registers.
Each run yields a canonical observation digest and a stored report, readable by ID.
Bytecode and caches are derived state keyed by root and profile. Programs that need the EFFECT/CAP E7 opcodes get a clean, deterministic refusal.
Authority - policy roots and capability tokens
A protected policy root is versioned apart from the program. A candidate binds the policy root it is judged under and can never modify it in the same transaction.
Capability tokens are narrow grants bound to a root, an effect, a scope, an adapter and a budget.
Adapters are the only way out to the host, and each one is bounded and typed.
Versioned state - repository, branches, merge, exchange
A content-addressed object store plus refs, independent of Git.
Branches are atomic named refs that advance by compare-and-swap from their direct parent.
Compare diffs two states semantically: which entities changed and what they affect.
Merge is deterministic: disjoint changes merge, and ambiguous ones become explicit conflict objects. Exchange exports a repository to a pack and clones it elsewhere; GC preserves every retained root.
An SMP1 conversation opens with a hello handshake; session.open trades its deterministic identity for a session. Root-bound handles go stale when the head advances.
Root-backed queries answer typed questions against a specific verified root, each with an exact query ID.
Every response reports what it returned and omitted under hard limits, and one that will not fit fails with PROTOCOL_LIMIT_EXCEEDED.
Context capsules package one query's answer as a deterministic evidence envelope. Every failure has a stable numeric code and symbol.
Release status
What ships in 2.1.7, how it is built, and what's next
In Sley 2.1
Typed Python-dialect authoring with pytest-style tests, a familiar syntax and AF1-X frames
Self-hosted toolchain; BOOTSTRAP_PROFILE_3, HOST_ABI_V3, EXEC_PACKAGE_V3 and the pinned sley-host
SSMC1 (18 entity kinds), SCB1 with a byte-identical oracle, SMP1 with a JSON bridge
14-phase validation, atomic commit with receipts, repository, deterministic VM, policy and capability
Sley