Where it fits
Every verification tool has a boundary.
Most are discovered during adoption. Three sprints in, by the person who staked their credibility on the choice. Nobody hid them; nobody wrote them down either, because a limit is the one thing no one is asked to document. These are SODL’s, stated before you adopt rather than during.
The one-paragraph answer
SODL earns its place where a workflow crosses services or takes time to settle, and where the contract is a document you actually maintain. Where that is not the shape of your problem, an ordinary test framework is the right answer and SODL will not pretend otherwise.
The last item on the right is the one most likely to rule you out, and it follows most directly from the design: everything SODL does begins by reading a contract.
Good fit
- Workflows crossing several services
- Asynchronous state that settles later
- Contracts that change under you
- Release gates that must be defensible
Not this
- UI testing
- Load and performance testing
- Unit tests
- Systems with no published contract
Three places a verification model can come from
Not two. The familiar split is handwritten tests versus specification-driven tools, and it hides the distinction that matters.
Described by hand, executed faithfully. The model is real and it lives in your suite, where nothing can compare it against the document it was copied from.
Authored, negotiated, and verified against a provider. That is a deliberate design rather than an oversight, and it proves something derivation does not: that one named consumer’s needs are met. SODL does not model that relationship.
SODL is in this third group, not outside it. If you suspected this was another specification-driven tool, you were right about the family. The difference is how far into the document the reading goes.
What is conceded, before what is claimed
Specification-driven generators derive their requests from the document. They do not take an author’s word for the shape of a call, which is their design and it is the correct one. Operations can be chained through links declared in the document, so multi-operation sequences are not exclusive to derivation. And which operations were exercised can already be counted, so an operation-level denominator exists without deriving anything further.
What is left when the reading stops at shapes
- Which field carries an entity’s identity
- How entities correlate across operations
- Which states a thing can occupy, and which of them a scenario can wait for
- Which principal is permitted to invoke what
None of that is absent from the contract. It is simply not extracted into anything a scenario can be checked against, so it gets re-typed by hand into the suite, where nothing can check it against the document it came from.
Two kinds of boundary, never conflated
A boundary that will not move is a consequence of what SODL is; no release changes it. A boundary with a date is not built, or not built yet. Which one it is, is stated. Confusing them is how a permanent limit gets read as a roadmap item, and a reader who cannot tell them apart cannot plan.
It verifies systems through their APIs. No browser, no selector, no screenshot diffing. This will not move.
It answers is this correct, not how fast, at what concurrency. This will not move.
It runs against real, running services. Your unit tests keep their job. This will not move.
Outside it by construction. Everything SODL does begins by reading one. This will not move, and it is the boundary most likely to rule you out.
Two lists, because we read it and we claim it are different promises
Conflating them is how adoptions go wrong mid-flight. SODL only claims a format when every verification-relevant element is fully modelled, so there are no surprises later. A format it merely reads is accepted and normalised, and anything beyond the modelled subset becomes an explicit representation gap rather than a guess.
Claimed gRPC / protobuf, OpenAPI 3.0, Swagger 2.0
every verification-relevant element fully modelled
Also read OpenAPI 3.1
accepted and normalised; constructs beyond the modelled
subset become explicit representation gaps, never guesses
Refused Swagger 1.x — a multi-file 2011-era format that cannot
be translated from a single document; the error names
convertersExactly what is true today, stated 2 August 2026
SODL is pre-V1, distributed as an internal release with an anonymous install script. Deriving, proving, coverage, drift and evidence all work and can be demonstrated end to end. What follows separates the things that are decisions from the things that are simply not built yet, because a reader who cannot tell those apart cannot plan either.
The binary is free to download and run: no account, no licence key, no seat count, nothing to sign. The source is not public, and SODL is not open source. That is where it stands today rather than a promise about tomorrow, and if it changes, or if a paid tier arrives, it will be said on this page with a date beside it.
Async, meaning AsyncAPI-declared correlation, server-streaming and inbound webhooks, is deliberately out of V1. It is one missing concept, the system emits to you, and it is being treated as a single piece of work rather than three patches. parallel is reserved and refused honestly today, because making it work touches evidence ordering.
Non-JSON response bodies fail at decode. Walking list and search response bodies is unbuilt, which leaves some collection operations unobservable. Scenario-corpus analysis is designed and not built.
This page states the boundaries that have been found. A boundary nobody has hit yet is not on it, and pre-V1 means the list is still growing.
SODL has not yet been validated on a deployment outside this project’s own repository. That is a deliberate bar rather than an oversight, because a tool whose argument is prove it should not declare itself proven on its own fixtures. It is also, plainly, unfinished. If you run it on your system and it asserts something you cannot reproduce, that is the most useful thing you can send back, and it is more useful than a feature request.