Implementations

This section is not part of the specification. Each page describes a particular piece of software: which conformance modules it claims, what it was checked against, and what it does not do. A page here can be wrong without the specification being wrong, which is why these pages are hand-authored and are not drift-checked against the corpus.

What an entry states

Field	Meaning
Modules claimed	The set of conformance modules the implementation states it implements, in the form the conformance clause requires
Corpus result	How it fares against the published vectors, including cases skipped because their module is not claimed
Status	Whether it is released, and what it is fit for
Not implemented	What it deliberately leaves out, so the omission is a statement rather than a discovery

A claim is only meaningful against something that can refuse it. /vectors/index.json reports the case count per module, so an entry claiming a module with zero cases is claiming something nothing yet checks — which is worth knowing, and is why the counts are published rather than described.

Entries

Implementation	Language	Status
Reference implementation	Rust	Scaffolding; no protocol logic
shenas	Python, Rust	Application; claims no module, publishes its floor partition

There are two, both are ours, and neither implements the protocol yet: the reference implementation is scaffolding, and shenas is the application it is being built for, which so far publishes only the floor partition SSP/1 asks an implementation to define. Two independent implementations are what make an interoperability claim mean anything, and SOVM/1 does not have them. Nothing on this site should be read as describing shipped software; the status page says what does exist.