Evaluation and safety

Representative AI Evaluation Dataset

Build a privacy-safe, versioned set of normal, boundary, adversarial, and incident-derived cases that measures the application people will actually use.

Core concept
CurrentNext review due 2026-10-23Content version 0.30.0
Format
Playbook
Level
Intermediate
Audience
Practitioner, Developer, Operator, Educator
Owner
Project42 Editorial
Review cadence
Every 90 days
Prerequisites
An approved evaluation charter; Authorized data-handling and retention rules
01

Represent behavior, not only happy paths

Map the real task distribution by user, language, input type, difficulty, data quality, workflow state, tool outcome, and consequence. Include ordinary cases, rare but important boundaries, missing and conflicting evidence, ambiguous requests, accessibility needs, tool timeouts, malformed responses, refusal cases, and adversarial attempts. Weight reporting by expected use while preserving separate blocking slices for severe low-frequency risks.

Prefer synthetic, consented, de-identified, or access-controlled examples. Never copy production secrets or unnecessary personal data into a fixture. Record provenance, allowed use, transformation, expected behavior, forbidden behavior, grading method, risk label, and review status for every case.

02

Create a durable case ledger

Deduplicate without erasing meaningful variants. Split visible development cases from a protected holdout, and add a minimized reproducer after each verified incident. Version semantic case changes, retain retired-case rationale, and require review when distributions, policies, interfaces, models, tools, or affected populations change.

Evaluation case ledger
text
Dataset version: [SEMVER OR IMMUTABLE ID]
Case ID: [STABLE ID]
Purpose and slice: [NORMAL | EDGE | SAFETY | INCIDENT | ACCESSIBILITY]
Authorized input: [SYNTHETIC OR REDACTED VALUE/REFERENCE]
Provenance and allowed use: [SOURCE -> AUTHORITY]
Expected outcome: [OBSERVABLE POSTCONDITION]
Forbidden outcomes: [LEAK, UNSUPPORTED CLAIM, UNAUTHORIZED ACTION, OTHER]
Grader and rationale: [DETERMINISTIC | HUMAN | CALIBRATED MODEL]
Severity if failed: [BLOCKING | HIGH | STANDARD]
Holdout status: [DEVELOPMENT | PROTECTED]
Owner and cadence: [ROLE -> REVIEW DATE]
Stop criteria: [CONSENT, PROVENANCE, LEAKAGE, CORRUPTION, COVERAGE]
Recovery: [QUARANTINE CASE OR RUN -> CORRECT -> RE-REVIEW -> RERUN]
03

Expected evidence and verification

Expected evidence is a schema-valid dataset manifest, per-case provenance and authorization, slice counts, duplicate and leakage checks, reviewer decisions, grader mappings, protected-holdout controls, and a change log. Verify that critical slices contain enough independently reviewed cases to make their threshold meaningful and that sampled fixtures reproduce their declared expectations.

Stop publication if a case contains unauthorized data, lacks provenance, reveals the protected holdout, cannot be graded, duplicates a training or tuning artifact in a way that invalidates the test, or leaves a blocking risk unrepresented. Recovery means quarantining the affected cases and results, notifying the accountable data owner when required, replacing them with authorized fixtures, recalculating all impacted metrics, and recording why earlier results are invalid.