# Eval framework outline — skeleton

*Headings and field lists only. Re-typed from the structure used on a sovereign OSINT platform built
for a defence innovation challenge; no content from that or any other project.*

**Header block:** product · version · date · owner (by role) · the success-metrics document this is
deliberately **not** · the gate script that encodes the floors

## 1 · What "eval" means here, and why it is a separate document
- Eval measures the model's behaviour on fixed cases; metrics measure the product's outcome for users
- Why the two are reviewed by different gates (product review vs sign-off gate)
- What is in scope: the capabilities under eval, by name

## 2 · Current state (audit)
| Capability | Cases today | Floor today | Gate today (manual / scripted / in CI) | Gap |
|---|---|---|---|---|

## 3 · Principles
- Floors are pinned before the build that must clear them
- A floor is encoded in code and run before every sign-off; a reading review does not replace it
- Measured and projected figures are never blurred
- Every case has a source, an expected behaviour and a reason it exists (story, risk or incident)

## 4 · Candidate frameworks considered
| Framework | What it would give | Constraint it fails or passes (e.g. air gap, licence) | Decision |
|---|---|---|---|

## 5 · Adoption roadmap by MVP
| MVP | Capability under eval | Cases added | Floor | Gate location |
|---|---|---|---|---|

## 6 · Near-term action for the current MVP
- The one change to make now, who owns it (role), and how it is verified

## 7 · Guardrail additions
*Cases that exist to prove the system does **not** do something.*

| Case ID | Input class | Expected behaviour (abstain / refuse / cite) | Source (negative persona, risk ID) |
|---|---|---|---|

## 8 · Maintenance
- When cases are added (new story, new incident, new risk)
- When a floor may be raised, and the rule that it is never lowered without a recorded decision
- Where results are logged and how long they are kept