Trellis
Decision 5 of 5
  1. 01The model plans; the pipeline writes the SQL
  2. 02Checks decide what gets published
  3. 03Spend is reserved before a run starts
  4. 04The backend authors the screen
  5. 05Evaluation is sealed, and a failure counts

Decision 05 of 05 · 2 min read

Evaluation is sealed, and a failure counts

How do you know it's accurate, and how accurate?

Test sets have separate jobs and never mix.

The three kinds of test set
SetUsed forWhat a result there shows
DevelopmentBuilding and testing the pipelineExpected answers come from a plain-Python reference calculation that shares no code with the pipeline
ValidationChoosing the model, prompt and rulesSelection evidence only
Sealed finalJudging one candidate, onceAn independent result: written and sealed before the tuning it judges, kept outside the repository, run once

The pass bar was set before any evaluated run: at least 95% correct, no unsafe answers, the live guard-rail suite passing, and every run within its caps. “Unsafe” here means publishing an answer when the expected outcome was a refusal, a question back, no answer or unavailable; an answer with wrong values counts against accuracy instead. The first candidate missed it by one question, and that result stands in the record. The fix was judged on a new sealed set.

Custody was single-person: an AI model drafted the sealed sets from an agreed plan, and one person reviewed, sealed and ran them. The seal proves the files were not changed, not that the expected answers are right. Both sealed sets are now used up.

The trade-off

A sealed set can be used once. Every candidate change that wants an independent result needs a new set written before the tuning it judges.

What was shown

  • Live evalThe first candidate scored 34 of 36 on its sealed test, one short of the bar, with no unsafe answers.
  • Live evalThe revised candidate scored 36 of 36 on a fresh sealed test, with no unsafe answers, for an estimated USD 0.217 in model and query cost.
  • Live evalOn that test a question took 19 s at the median and 73 s at most, within a 120 s cap.
  • Live evalWrite requests and restricted tables are refused before BigQuery is called: no dry run, no job.
  • LimitCustody was one person: an AI model drafted the sealed sets from an agreed plan, and one person reviewed, sealed and ran them. That is weaker independence than a separate custodian.
  • LimitA seal proves the files were not changed, not that the expected answers are right.
  • LimitBoth sealed sets are now used up; the next independent result needs a new one.