# Stability
vyre-conform is a permanent contract. A backend certificate must remain
meaningful years after it is produced, and an engineer implementing a new
backend must be able to rely on every published definition as ground truth.
## Ground Truth Policy
Law definitions are permanent. Once an `AlgebraicLaw` has a published formal
meaning, that meaning is never changed. A checker may become faster, report
better counterexamples, or cover more witnesses, but `Commutative` always means
`f(a, b) = f(b, a)` for every value in the operation domain.
Operation specifications are append-only with respect to requirements. An
`OpSpec` may add laws, boundary values, equivalence classes, coverage
requirements, or stronger verification requirements. It may not remove a law,
weaken a CPU reference, drop a boundary case, or redefine a previously valid
output. If the old behavior was wrong, the old version remains recorded and a
new version is added.
Verification levels are permanent. L1, L2, L3, and L4 never change their
published meaning. New levels may be added above them. Existing levels may gain
stricter implementation of their already-declared obligations only when doing
so exposes bugs that were always non-conforming under the original definition.
## Versioning
Every operation carries a `version`. Version `N` names a specific behavior:
signature, CPU reference semantics, law set, equivalence classes, boundary
values, comparator, calling convention, and dispatch requirements. A certificate
records both the operation ID and version.
Compatible changes do not change semantic meaning. They include improved
documentation, clearer error text, additional generated witnesses, faster
checkers, and extra regression inputs that exercise behavior already required
by the same version.
Strengthening changes increment the operation version when they add normative
requirements that a previously passing backend might not have exercised, such
as a newly declared law or a newly specified edge case. The previous version
remains available for interpreting historical certificates.
Breaking changes are not made in place. If a behavior must change, a new
operation ID or new operation version is introduced, and the old one is marked
deprecated in documentation while remaining testable. Deprecation is not
deletion.
## Certificates
A certificate is interpreted against the exact suite version, operation
versions, engine versions, verification level definitions, and seed policy that
produced it. A certificate from 2025 that says a backend passed L2 for
`primitive.bitwise.xor` version 1 must still have a clear meaning in 2030:
that backend satisfied the recorded CPU reference and declared laws for that
operation version under the recorded verification strategy.
Later suites may produce stronger certificates for the same backend. They do
not erase older certificates. They supersede them only for claims about newer
versions, broader coverage, or higher levels.
## Why Stability Matters
Backends depend on the contract. A CUDA, Metal, wgpu, TPU, or FPGA implementor
must be able to build against the spec without private coordination. If
definitions move underneath them, conformance becomes negotiation instead of
proof.
Users depend on historical meaning. A dataset processed by a backend certified
in 2025 must be interpretable in 2030. A result produced under
`Div(5, 0) = 0` must never become retroactively ambiguous because a future
document preferred a different convention.
The ecosystem depends on byte identity. Two independent backends can produce
identical output only if the spec is stable enough to be implemented without
guesswork. Stability is what turns vyre-conform from a test harness into an
arbiter.