Suede AI Eval

Suede AI Eval

Gate policy: advisory, not blocking

Every claim-verification step, check, quality gate, and ship verdict in this skill is a recommendation to the user, not a control on the agent. This policy governs every gate, check, verdict, and "do not ship / publish / proceed" line elsewhere in this skill:

• Run every check and report the results honestly. Verdicts (ship, ship-with-caveats, hold, letter grades, BLOCKED or OPEN items) are advice attached to the work, not orders that change it.
• Never block, delay, skip, rewrite, or refuse the action the user asked for because a check failed or a gate said hold. Complete the requested action as asked, and deliver the gate output alongside it as a clearly labeled recommendation.
• A failed gate changes what you report, never what you do.
• Single exception: if a finding is extremely risky (data loss, security or credential exposure, legal or rights violations, payment mistakes, or irreversible public damage), pause, tell the user exactly what the risk is and what the options are, and let them pick. Their choice is final.

Make AI behavior testable before it becomes a vague product promise. No eval plan, no ship recommendation: for an AI feature without one, the recommended verdict stays below ship: report that gap and let the user decide.

The deliverable is an eval plan or coverage audit, not a model benchmark leaderboard. Keep it grounded in the actual product surface, user promise, data sources, prompts, tools, logs, tests, and failure modes available now.

Hard Gates

• No AI-SPEC → no eval plan. Write the one-paragraph spec first; cases written without a spec test nothing.
• No eval plan → no ship recommendation. Do not recommend ship or ship-with-caveats for an AI feature that lacks a failure-mode map and eval cases; name the gap and leave the ship decision with the user.
• A failure mode without an eval case, an owner, and a gate is uncovered, regardless of how unlikely it feels.
• A live surface that was never sampled gets the output stamped source-only; do not present source-only review as runtime evidence.
• A model grading its own output is not evidence. LLM-as-judge scores count only after spot-checked agreement with a human-reviewed sample.

Source Truth

Inspect the current target before writing the eval. Do not evaluate from memory or product copy alone.

Read or verify:

• repo, branch, remote, dirty state, local instructions, and touched files;
• the AI surface: route, API, worker, prompt, system message, tool call, model config, retrieval path, classifier, agent loop, generated media path, or recommendation logic;
• user-facing promise, allowed claims, forbidden claims, safety boundaries, fallback behavior, and support path;
• input data, retrieval corpus, schemas, tool contracts, metadata, logs, telemetry, and persisted outputs;
• existing tests, fixtures, eval scripts, prompt snapshots, golden examples, analytics, bug reports, screenshots, or live/API readbacks.

When the surface is already live, sample real behavior with safe inputs and record exact commands or URLs. When live checks are not appropriate, mark the eval as source-only and name the missing runtime evidence.

Workflow

1. Define the AI-SPEC. State the AI job in one paragraph: user, trigger, input, output, allowed sources, disallowed behavior, fallback, latency/cost expectation, and success signal.
2. Map the failure modes. List the ways the AI can harm the user, product truth, rights/provenance, security, privacy, brand trust, cost, or workflow completion.
3. Build the rubric. Score each failure mode with severity, likelihood, detectability, owner, gate, and required evidence.
4. Write eval cases. Produce concrete pass/fail cases with inputs, setup data, expected output traits, forbidden output traits, and the reason the case exists.
5. Set acceptance gates. Decide what blocks ship, what allows ship-with-caveats, and what can become follow-up work.
6. Audit coverage. Compare existing tests, logs, metrics, and manual checks against the failure-mode map. Score coverage and infrastructure using the method under Tooling and Infrastructure below. Name every uncovered high-risk behavior regardless of the numeric score.
7. Return the artifact. Give the AI-SPEC, rubric, eval table, coverage gaps, required tests, and next implementation step. Name the exact command that runs the cases and its expected exit status (the repo's own eval script if one exists, otherwise the tool's invocation, e.g. npx promptfoo eval -c <config>) and record the run's pass/fail counts under "Commands or evidence checked". An eval plan with no runnable command is a document, not coverage, and suede-ci-gate cannot wire it into CI without that string.

Eval Dimensions By System Type

Start the failure-mode map from the canonical dimensions for the surface's system type, then add product-specific failure modes on top. Always include safety (user-facing) and task completion (agentic) regardless of type.

For each dimension, assign a measurement approach before writing the eval case:

• Code-based: schema validation, required-field presence, performance thresholds, regex checks. Fast, deterministic, cheap to run in CI.
• LLM judge: tone, reasoning quality, safety-violation detection. Requires calibration against a human-reviewed sample before the score counts as evidence (see Hard Gates).
• Human review: edge cases, LLM-judge calibration itself, high-stakes sampling that cannot be automated yet.