42 posts tagged with "ess"

Three releases about surfaces: the one this tool presents, and the one a specified component presents to a person at a terminal.

A conformance suite is worth what its assertions are worth. These releases are about three claims the model had no way to state, each found by an implementation that passed while being wrong.

The releases through 0.7.1 established that a specification can judge an implementation, and that the same pattern points at a running cluster. What neither could say is which artifact implements which component, and what it takes to run it. These two releases say it, as typed data, without acquiring the ability to do anything about it.

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.