Define quality
before deployment.
The proposed framework starts with a task-specific evaluation set and an agreed quality bar. Changes should be compared against that bar, with the evaluation context recorded.
A safety floor
under the model.
The proposed framework places a safety floor outside the model, with checks for safety drift on each build. Its scope and operating protocol require review before becoming a published commitment.
Framework draft. The detailed policy, enforcement design and operating protocol require review before this becomes a published commitment.
What is checked before promotion?
The intended protocol records task quality, out-of-scope behaviour and safety drift. Concrete checks and acceptance criteria belong in the reviewed protocol.
How are limits communicated?
Record where a model was evaluated, its known limitations, and the work it should decline. Keep those limits alongside the model version and its results.
Control the behaviour.
Understand the terms.
Define what the model should do, what it should know and what it should decline. Deployment choices, data responsibilities and operating controls belong in the agreement for the work.
By default models run on the Ertas platform. Model ownership and weights handover are available with a minimum engagement commitment; the terms must be agreed for each engagement.
A model record
you can examine.
Proposed model-card structure. Fields below describe what a record should contain; they are not claims about a deployed endpoint.
| Record | What to document |
|---|---|
| Identity | Base model, task, version and release date |
| Training | Approach, data provenance and permitted use |
| Evaluation | Held-out set, baseline, metric and acceptance criteria |
| Limits | Known failure modes and out-of-scope work |
| Operation | Deployment responsibilities and version history |