Model governance
A scientific model is more than its weights: it is the activation specs, the operator types, the derivative orders it claims, and the numerical guarantees attached to its outputs. Governance means tracking all of these through the model's life.
A governance lifecycle
What to record at each stage
| Stage | Record |
|---|---|
| Specify | activation names + ActivationSpec metadata, operator tags, max derivative order |
| Build | backend + version, dtype, seeds |
| Verify | cross-backend parity results, enclosure tests vs. dense grid + random sample |
| Certify | certificate JSON + digest, theorem_prover_verified status |
| Release | semantic version, changelog entry, stability-matrix snapshot |
| Audit | the exact commands to reproduce every published number |
Roles and sign-off
- Author produces the model and its certificates.
- Reviewer independently re-runs the evaluation gates and inspects the exactness labels.
- Approver signs the release only when gates pass and scope claims match the scope boundaries.
Make the exactness label a required field
In any internal model card, treat the exactness category (closed-form / autodiff-exact / numerical) as a mandatory field per claimed quantity. A model card that says "exact" without a category is incomplete.
Tie-in to omnibias features
- The certificate format is your immutable governance record for a bounded quantity.
- The evaluation gates are the verify stage, automated.
- The stability matrix is the release-stage snapshot of what each backend supports at each order.