Sley 1.2.0 and the Machine-Native Turn

The decision behind this release

Sley 1.2.0 is the strongest version of the language Greyforge has built. It also marks the point where Greyforge is shifting current time and attention away from extending 1.x as its main research path.

That shift is not an obituary or a retirement. Sley 1.x remains open, usable, and eligible for future work by Greyforge or the community.

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 strongest public expression of that first idea so far.

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.

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.

Why give 2.x a clean research path?

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.

Giving 2.x primary research attention lets Greyforge test the machine-native thesis without binding it to 1.x compatibility. It does not prohibit Greyforge from returning to or upgrading 1.x when future evidence, use, or demand justifies that work.

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.

Sley 2.x starts with permission to revise the core constraints

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 immediate research question shifts from making programming languages friendlier to software agents toward what programming becomes when the agent handles more of the representation.