Build checks · experimental
Annotation workflow
Human-validated truth returns to the repo — through a record, not a UI.
The governance for returning reviewed truth to your repo ships today; a polished
annotation UI is experimental. The contract is
the point: an annotation import counts as an authority input only when it carries
a non-empty
validation_record — a reviewer’s signature, not a tool’s say-so.
Labeling a batch should not, by itself, make a gate look justified. So an annotation is evidence until a host reviewer validates it; the validated result then returns to the repo as host-owned truth, where it can back a check.
What an annotation can and cannot do
| Without a validation record | With a host validation record |
|---|---|
| An annotation import is informational evidence — recorded and usable, but it authorizes nothing. | The reviewer’s signed record turns the labels into an authority input the host owns — and only then can a reference metric rely on them. |
The UI is experimental; the rule is not
Whatever interface collects labels — script, notebook, or a future panel — the library enforces
the same gate: no
validation_record, no authority. Treat any annotation UI as
experimental and reported as such, never as a shipped product.
Status lives on the roadmap register.