The patterns of evaluation → API to Architecture

1. Evals as a named pattern

Everything you read in this course is a pattern. The eval set as a sample of reality. The shadow eval as a real-traffic check. The continuous gate that runs on every change. The drift detection that keeps the set honest.

These aren't tricks. They're named primitives in the design space of AI systems. Once you know them, you start to see them everywhere — in every well-built AI feature you read about, every architecture talk that's actually saying something, every team that has shipped twice and isn't apologizing for it.

2. What [[api-to-architecture]] adds

[[api-to-architecture]] is the design-pattern catalog for the AI era. Evaluation is one of the patterns in that catalog, sitting alongside retrieval, tool use, agent loops, structured output, and a dozen others.

What you got in this course is the standalone view of evals. What the catalog adds is the integration view: where evals fit in a system that also has retrieval and tool calls and agent orchestration, what trade-offs you make when you compose them, what the shape of the whole system looks like when each primitive is doing its job.

If you've finished this course and the way it framed evals made sense, the catalog is the next move.