Sley 1.2.0 / Architectural Transition
Sley 1.2.0: The Last Sley Built for Humans
Sley 1.2.0 completes the original agent-first, human-readable language.
Greyforge is freezing that line and beginning a clean architectural break around a harder thesis: more software will be written, transformed, inspected, and exchanged by machines.
Machine Facts
Public source note- Sley 1.2.0 is the culmination of the original agent-native, human-readable Sley architecture.
- Greyforge Labs is freezing active feature development of the Sley 1.x design after 1.2.0.
- Sley 1.x remains public under Apache-2.0 and remains suitable where people and agents need to work directly on the same readable source.
- Greyforge welcomes outside adoption, experimentation, forks, and community stewardship of the human-readable line without promising a formal governance or support program.
- Sley 2.x is a clean architectural break rather than an ordinary incremental upgrade.
- Sley 2.x removes human readability of the canonical raw program representation as a mandatory design constraint.
- Human governance remains required in Sley 2.x. The change concerns who must directly consume raw code, not who controls objectives, policy, risk, deployment, or acceptance.
- Compatibility between Sley 1.x and 2.x is not promised.
- Reuse of Sley 1.x code and architecture is allowed but not required.
- Lessons, tests, evidence, failure modes, and successful concepts from 1.x remain research assets even where implementation code does not survive.
- The canonical public release is the v1.2.0 GitHub pre-release, published August 27, 2026 from commit d281cd1.
- The supported artifact is sley-1.2.0-linux-x86_64.tar.gz with SHA-256 2765aa5adb09f2ef071b5c97d2726951193b0ac97ddddb9e91e26c5562261838.
- The release records 38 targets, 99 schemas, 187 of 187 contract fixtures, 264 of 264 declared integration checks, 11 of 11 release-packet checks, and 4 of 4 public-release checks.
- The artifact boundary is Linux x86_64 with unsigned provenance. It is a release candidate, not a production-promotion claim.
The strange part of this release
This is a strange release to publish. Sley 1.2.0 is the strongest version of the language Greyforge has built, and it is also where active development of that architecture stops.
That does not make 1.2.0 an obituary. It makes the release more important.
Sley 1.x began with a precise idea: software agents should work through structure, authority, verification, and evidence, but people should still be able to open the canonical source and understand it. That premise produced a self-hosted compiler, deterministic structural tooling, bounded change transactions, explicit review surfaces, worker and adapter contracts, and a public proof trail.
Sley 1.2.0 is the finished form of that first idea.
If your requirement is agent-first software that people can still read and manipulate directly, 1.2.0 may be the version of Sley you want.
Release / Proven Today
Sley 1.2.0
A self-hosted structural programming language release candidate for compiler-mediated, human-reviewed software change.
Verified release status
Public GitHub pre-release. Linux x86_64. Unsigned provenance. 38 targets passed. Not production promoted.
- Repository-local validation profiles with machine-readable reports
- A bounded change lifecycle from inspection and planning through authority, apply, review, recovery, and seal
- Persistent local worker sessions with Python and Node clients
- Stable report contracts for selected operational surfaces
- Controlled replay and evidence registries that separate observed state from permission to act
Active Greyforge feature development moves to the 2.x architecture. Sley 1.2.0 remains available as the open human-readable line.
Sley 1.2.0 is not a failed experiment
The release candidate gives the original architecture a serious public boundary. It ships a supported Linux x86_64 archive with checksum, manifest, unsigned provenance, SPDX 2.3 SBOM, license inventory, toolchain diagnostics, and release verification material.
The proof inventory is public: 99 schemas, 187 contract fixtures, 264 declared integration checks, 38 release targets, 11 release-packet checks, and 4 public release checks. Those counts do not make a universal production claim. They make the release inspectable.
The source remains readable. A Sley module still looks like a program a person can follow:
module app.compute
task classify -> Text {
take score: Int
return if score >= 90 { "excellent" } else { "steady" }
}
task main -> Text {
bind score = 40 + 55
return call classify(score)
}But the workflow around that source is structural. Tools can query calls, inspect diagnostics, prepare narrow candidate changes, check authority, and produce verification evidence without treating a broad text rewrite as the only unit of work.
The original thesis contained a contradiction
Sley was designed to be agent-native. It was also designed around human-readable source.
Those goals are compatible. They are not identical.
A readable language carries valuable conventions for people: names that scan well, visual source organization, familiar syntax, stable formatting, textual redundancy, and compatibility expectations. These qualities help mixed teams reason about a shared artifact. They also shape every compiler and tooling decision around the assumption that the canonical representation must remain a comfortable human interface.
An autonomous software agent can value a different set of properties. It may care more about exact semantic identity than line layout. It may need a bounded subgraph instead of a whole file. It may prefer directly addressable entities over repeated reconstruction from names and surrounding text. It may benefit when a transformation is expressed as a typed operation instead of a patch.
If one machine generates a program, another reviews its structure, a compiler verifies it, another machine changes it, and a person consumes the behavior and evidence, why must the intermediate representation still look like something a person would enjoy typing?
Sley 1.x proved enough of the agent-native thesis to expose that question.
Architectural progression
01
Conventional languages
Human-first source
02
Agent-assisted programming
Human-first + autonomous tooling
03
Sley 1.x
Agent-first + human-readable
04
Sley 2.x
Machine-native + human-governed
What happens when the programmer is no longer human?
Programming languages have historically been interfaces between humans and machines. Sley 2.x begins from the possibility that the dominant interface will increasingly be machine-to-machine.
That is a thesis about direction, not a claim that people have stopped writing or reading code. Greyforge expects a growing share of software engineering to involve machines generating implementation, inspecting it, modifying it, testing it, proving transformations, exchanging implementation context, and maintaining systems across sessions.
Under that assumption, the language should be free to optimize for machine cognition and machine transformation.
Semantic density
Represent the same intent with less irrelevant representational overhead.
Deterministic interpretation
Reduce cases where meaning must be reconstructed from convention or surface presentation.
Mutation locality
Change the smallest semantic unit that satisfies the objective instead of rewriting a broad textual region.
Context efficiency
Minimize how much representation must enter an agent context to understand one bounded component.
Structural addressability
Make program entities directly targetable without repeatedly rediscovering them from raw text.
Machine-to-machine transfer
Treat handoff between software agents as a first-class programming-language concern.
Verification
Make semantics, changes, authority, and resulting evidence easier for machines to validate.
Representation freedom
Permit sound architectural choices even when their raw form is less pleasant for people to author directly.
These are design targets. They are not implementation claims, a public syntax proposal, or a benchmark result. This Chronicle does not declare that Sley 2.x must be binary, graph-based, compressed, bytecode-like, or any other prematurely fixed mechanism.
The commitment is more fundamental: human readability of the canonical raw representation is optional.
Architecture Comparison
Two optimization targets
| Dimension | Sley 1.2.0 | Sley 2.x |
|---|---|---|
| Primary software consumer | Agents + humans | Agents / compilers |
| Human-readable raw source | Required | Optional |
| Human authorship | Supported directly | Not an optimization target |
| Agent authorship | First-class | Dominant assumption |
| Human governance | Required | Required |
| Human raw-code review | Normal | Potentially exceptional |
| Machine-to-machine transfer | Important | Foundational |
| Semantic density | Balanced with readability | May outrank readability |
| Compatibility constraints | Existing 1.x contract | Clean-slate permitted |
| Design goal | Agent-first, human-readable | Machine-native software engineering |
Humans do not disappear. They stop being the parser.
Sley 2.x is not anti-human. It is anti-human-readability-as-an-architectural-constraint.
People still own objectives, requirements, constraints, authority, policy, evaluation, risk decisions, deployment decisions, and acceptance. What changes is the assumption that people must continuously consume the same canonical representation that machines use to create and transform software.
Sley 1.x
Sley 2.x thesis
Human control moves upward
Raw-code review has often been used as a proxy for control. A machine-native system can instead give people precise projections of intent, impact, policy, risk, provenance, and verified outcome while keeping authority explicit.
Architectural Firewall
The Machine-Native Invariant
No Sley 2.x design decision should be rejected solely because its raw representation is inconvenient for humans.
The invariant does not prohibit human-readable projections, generated explanations, inspectors, visualizers, debugging interfaces, structured reports, decompilation views, development dashboards, or audit artifacts.
It prohibits making direct human readability of the canonical machine representation mandatory.
Why not just evolve 1.2.0?
Because compatibility can become an invisible design authority.
If Sley 2.x had to preserve an architecture built around a human-readable invariant, that requirement could quietly recreate the original constraint inside the new system. Every representation, identity rule, mutation primitive, context surface, and verification path would have to justify itself against a contract designed for a different optimization target.
The clean break leaves 2.x free to discover what a machine-native programming system requires instead of beginning with the shape of a conventional human language and attaching agent features afterward.
A rewrite does not mean starting from zero
Sley 1.x produced more than implementation code. Its assets fall into three classes.
Class A
Principles likely to survive
Deterministic semantics, explicit authority, verification, evidence-producing execution, structured transformations, bounded mutation, compiler ownership of meaning, agent-oriented inspection, and reproducibility.
Class B
Research assets
Test corpora, benchmark methods, adversarial fixtures, failure cases, claim evidence, prior-art research, design notes, language experiments, performance data, controlled workflow results, and translator research.
Class C
Details that must earn survival
Parser design, syntax, file format, internal tree layout, command surface, compiler internals, module system, textual conventions, and compatibility behavior.
Architecture should survive because it remains correct, not because it was expensive to build.
Reuse is welcome. Compatibility is not sacred.
The community inherits the human-readable line
Sley 1.2.0 now belongs to the people who still need it.
That statement is an invitation, not a dismissal. Sley 1.x solves a different and legitimate problem. The repository is not being erased. The source remains available under Apache-2.0. Developers can use it, study it, extend it, fork it, and carry the human-readable line in directions Greyforge will not.
Greyforge is freezing active development of the 1.x architecture and inviting the open-source community to carry the human-readable Sley line wherever it proves useful.
That invitation does not imply a new foundation, governance board, maintainer service level, security-support period, or compatibility promise. It means the work remains open and useful even as Greyforge's research target changes.
The finished form of Sley's first idea
The original Sley thesis was:
Agent First, but Human Readable.
The new Chronicle-level thesis is:
Machine Native. Human Governed.
The second line does not automatically replace existing Sley branding. It describes the architectural transition.
Sley 1.2.0 is the artifact produced when Greyforge pushed the original thesis as far as it currently intends to push it. It should be judged on that problem, not retroactively condemned for failing to solve a different one.
Sley 2.x starts with a blank sheet of paper
There is no public feature roadmap in this Chronicle.
Sley 2.x may reuse substantial 1.x code. It may reuse almost none. Neither outcome is a measure of success or failure. Architectural correctness outranks reuse percentage.
The new line is not required to preserve source compatibility, compiler architecture, human-readable syntax, or textual conventions. It should inherit proven lessons wherever they remain relevant and discard assumptions that no longer serve the new problem.
The evaluation target changes as well. Sley 2.x should ultimately be assessed by the quality of agentic software engineering it enables: semantic precision, bounded transformation, context efficiency, reproducibility, verification, authority control, and reliable machine-to-machine exchange.
Until Greyforge publishes a dedicated Sley 2.x technical surface, this Chronicle is the canonical public waypoint for the 2.x direction. Future public records will link forward from here when their evidence and publication gates pass.
The question is no longer how to make programming languages friendlier to software agents. The question is what programming becomes when the agent is the programmer.
Sley 1.2.0 is not being discarded. It is being completed.
It remains Greyforge's answer to the world where people and agents share the code.
Sley 2.x is being built for the world where people define the objective and machines increasingly handle the representation required to reach it.
1.2.0 made programming agent-first. 2.x asks what happens when programming itself becomes machine-native.