Everything Ovrin exports lives in one package at the module root. Provider implementations live in
their own modules, so the surface here is the whole contract: what you call, what you get back, and
what you implement if you are writing an adapter.
Start here
If you are extracting a document for the first time, three pages cover it:
- Extract[T] — the entry point
- Client — how you configure providers and limits
- Result[T] — what comes back, and how to read it
Core API
| Page | What it covers |
|---|---|
| Extract[T] | The generic entry point, its options, and its two failure channels. |
| Client | New, provider options, and per-call overrides. |
| Result[T] | Typed data alongside validation state, confidence, and review flags. |
| FieldResult | One field and the evidence for it — presence, signals, provenance, candidates. |
The provider seams
Three small interfaces, and no vendor is privileged. Implement one to add a provider; the core never
learns its name.
| Page | Seam |
|---|---|
| Model | Turns document content plus a JSON schema into structured output. |
| OCR | Reads a rasterised page into words, lines, and positions. |
| Renderer | Rasterises a page for OCR or vision. Optional — most extractions never need one. |
Schema and rules
| Page | What it covers |
|---|---|
| Tag grammar | The ovrin:"…" struct tag — descriptions and the closed rule vocabulary. |
| Validation rules | What each rule checks and what a failure does. |
| Provider matrix | What each provider supports, rejects, and silently ignores. |
A note on stability
Ovrin is pre-v1 and no release is tagged. The API will change before v1.0. The upstream repository
keeps a generated record of the public surface in api/ovrin.txt, so every change to it is a visible
line in a diff that somebody had to intend.