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.
- 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
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.
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.
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]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.