Eval framework outline — skeleton

Download the MarkdownSkeleton_Eval_Framework_Outline.md · 2.0 KB · from The artefact set §4

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)

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

5 · Adoption roadmap by MVP

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.

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