9 posts tagged with "ess"

Release 0.7.0-ess-wave-7 is the wave where the machinery built over six releases stops pointing at itself. It opens with bookkeeping — every generated artifact now carries the digest of the model slice it derives from, and the semantic diff learns four more construct families — and it ends with the demonstration all of that bookkeeping was for: one application specification, synthesised to Rust and to Go, two binaries built and started in the gate, writing one startup record, answering seven HTTP exchanges identically, and publishing the same contract byte for byte. Nothing below is asserted from memory: every output was produced by running the released code, and the block that was not run for this post says which committed file it is.

A release with no new capability. Everything here takes a claim the repository was already making and makes it mechanical — enforced by something that fails, rather than by a doc comment that asserts.

Release 0.6.0-ess-wave-6 adds one verb to the CLI. ess synthesize turns a compiled specification into a plan and a Rust workspace: the types, the states, the ports — the part of an implementation that was never anyone's to write — plus a typed list of exactly what remains. The specification that already writes its documentation, its contracts and its tests now writes code, and the claim that matters is executed rather than asserted: the generated system passes the conformance suite the specification generated two waves earlier, before any of this code existed.

This post is a tutorial, run against the normative example that ships in the repository, so every output below is reproducible — and checked by tests, not pasted from memory.

Release 0.5.0-ess-wave-5 adds two verbs to the CLI. ess diff answers what actually moved between two revisions of a specification — as typed changes over the compiled models, not as text. ess impact answers the question that makes the first one worth asking: which verification results does that movement invalidate, and by exactly what path.

This post is a tutorial on both, run against a fixture that ships in the repository, so every output below is reproducible — and checked by tests, not pasted from memory.

Historical release note. ESS now publishes a standalone conformance report; workflow consumers translate that report at their own boundary.

This is the release where a specification first generated its own conformance suite, ran it against an implementation, and produced a report a workflow consumer could translate into its own evidence vocabulary.

Both halves are proven, which matters more than either alone:

• a correct implementation passes 27 of 27 scenarios and the task completes;
• the same implementation with one fault injected fails the scenario that exists to catch it, and the engine refuses to let the task complete, naming the principle that refused.

Wave 4 was going to make the specification judge generated code. Before that could start, four independent reviews opened twenty gates, and this release closes them.

It is not a feature wave. What a user notices is mostly things this repository used to accept and now refuses.

"One source of truth" is a claim until something is actually generated from it. This release generates four things, commits them, and fails CI if they drift.

A specification is only worth compiling if the compiled form can hold fewer wrong things than the source did. This release resolves a specification into an IR that cannot hold a dangling reference — not "is checked for", cannot hold.

Historical release note. ESS later became this standalone repository; references to the former combined repository describe the milestone at the time, not the current dependency boundary.

This release started ESS, which specifies what software must exist, inside the repository that originally hosted it.

The join is the point. A task can be blocked until something proves a specification is satisfied — so the two halves meet at evidence rather than at an integration.