SpineSpecify, Verify, Compare
The most obvious use of Spine is to write a program and compile it to an executable. But the most compelling scenarios use Spine as a specification tool alongside your existing systems and teams, without changing your stack.
In each scenario below, the specification is the product. The executable is a byproduct: a reference implementation you can test against, compare with, and reason about.
Existing Systems
You already have something running.
Your system works, but nobody can prove why. Write a specification in Spine. The process itself reveals inconsistencies. The compiled executable becomes a digital twin you can test against.
Model what the system must do, not what it does. Encode regulations as an executable specification. Test existing systems against the rule spec. When regulations change, update the spec and re-verify.
Prove the new system does what the old one did. Specify legacy behavior in Spine before rewriting. The executable becomes the oracle — migration is complete when the new system matches the spec.
New Work
You're building something.
Write the spec once, build with the team you have. The Spine executable is the reference implementation. Your development team codes in their chosen stack and tests against it.
Agree on behavior, not just interfaces. Go beyond structural contracts like OpenAPI — specify preconditions, postconditions, and temporal constraints. Each team verifies independently.
The spec is the acceptance criterion. When outsourcing development, the Spine executable settles what was specified. The vendor delivers code; you compare it against the reference.
In every scenario, the specification is the product. The executable is a byproduct.