Release status

Ovrin is at v1.0.0, and the API is stable. A breaking change now requires a v2. That is a promise
about compatibility and only about compatibility — a version number is a poor place to hide a caveat,
so the caveats are stated here instead.

What v1.0.0 promises

Claim	Status
The API will not break without a v2	Yes. The public surface is recorded in `api/ovrin.txt` and checked on every commit.
A published accuracy figure	None. The evaluation corpus is 25 synthetic documents, and the only committed report is a `no-run` placeholder of zeros.
Confidence is a calibrated probability	No. It is a ranking signal. It orders a review queue well; it does not mean "correct this often".
Used in production outside the project	Not that anyone has reported.

If you are deciding whether to depend on Ovrin for something that matters, the second, third and fourth
rows are the ones to weigh.

Why the version and the evidence are separate

ADR-0024
originally held v1.0 back until four conditions held: a corpus of real documents with committed reports,
calibrated confidence, a production deployment outside the project, and no API change the project still
wanted to make.

ADR-0032
superseded that gate. A semantic version is a statement about compatibility, and gating it on accuracy
evidence made v1.0 unreachable for reasons that have nothing to do with what v1.0 means. Only the last
condition — no wanted API change — was met, and it is the one v1.0.0 rests on.

The other three were not withdrawn. They remain the conditions for calling Ovrin accurate, and
they are tracked on the roadmap. The stability judgement itself rests on the
maintainer's own testing against real documents, and is recorded as exactly that rather than as corpus
evidence.

What stability means in practice

api/ovrin.txt is a compatibility contract. Removing an exported symbol or changing a signature
is a release blocker, not a regeneration.
Additions are not breaking. Three are already wanted — cache fields on Usage, a handwriting kind
on Word, and rendering Layout.Pairs into the prompt — and each will arrive in a minor release.
The interfaces you implement will not grow. A new method on Model, OCR, Renderer,
DocumentOCR or Scorer would break every implementation, so it would need a v2.

Releases

Date	Release
2026-09-05	Core `v0.3.0` — the first release. The seven adapters and the example at `<path>/v0.1.0`.
2026-09-12	All nine modules at `v1.0.0`. No library code changed; the release is the stability promise.

Modules version independently and are tagged with their path prefix, such as model/skyl/v1.0.0. They
started v1 together and may diverge from here.

Support

Only the latest release of each module receives fixes, and there are no backports to earlier v1 minors
while the project has one maintainer. Because modules version independently, "latest" means the latest
release of that module. Security issues are reported privately through GitHub Security Advisories,
never as a public issue.