Define good before optimizing an AI workflow

This is not a tutorial on writing better prompts. It is a record of how a product manager can turn “the experience feels better” into judgments that are testable, discussable, and reproducible when there is no single correct output.

01 / WHY

Why evaluation is product work—not only engineering work

AI outputs are probabilistic, and many tasks have no single reference answer. If “quality” remains a feeling, teams are left reviewing a few demos, chasing an aggregate score, or learning from failures in production. The hard part of evaluation is translating user value, product boundaries, and risk into operational criteria. That is product judgment.

01

Define behavior

What must happen, what must never happen, and what is merely a difference in expression.

02

Design evidence

Which samples represent use, which metrics diagnose, and which regressions must block release.

03

Make the call

A judge supplies signals; the product owner still owns trade-offs and the release decision.

02 / LOCATE

Locate the problem before changing it

I fix the optimization order as Contract → Workflow → Prompt. The further left a concern sits, the more deterministic it is—and the less it should rely on a model “getting the idea.”

01

Contract

Freeze inputs, outputs, schema, error semantics, and primary/fallback parity. Elegant prose is irrelevant if the product cannot consume it.

02

Workflow

Put routing, validation, retries, aggregation, and fallback into observable nodes. Express deterministic rules structurally.

03

Prompt

Let prompts handle semantic judgment: what counts as an action, what matters, and which uncertainties must remain.

Anti-pattern: append a sentence to the prompt for every bad output until no one can attribute—or safely remove—anything.

03 / MEASURE

An evaluation system must answer three different questions

Evaluation is not one score. It is a set of cross-checking evidence. Hard failures cannot disappear inside an average, and semantic gains cannot justify unreliable execution.

P0 Gate

Contract & hard rules

JSON / schema / evidence / empty results / routing

Deterministic pass or fail
Quality

Semantic quality

Faithfulness, coverage, structure, specificity, readability

Rubric + model judge + human calibration
Runtime

Execution & traces

Success, fallback, latency, tokens, repeatability

Tracked separately from semantic score

Two dataset tiers keep optimization from contaminating acceptance

Tier‑1 · Core regression

Small, slow-changing, and strictly frozen. It asks only: did this change break a floor we already protected?

Tier‑2 · Campaign set

Created around one weakness. It shapes a hypothesis, supports slices, and permits targeted iteration within the campaign.

Turn one optimization into an attributable campaign

  1. 01Freeze contract and baseline
  2. 02Freeze both dataset tiers
  3. 03State one primary hypothesis
  4. 04Make the smallest candidate change
  5. 05Repeat runs and three-layer evaluation
  6. 06Human-sign the verdict

04 / BUILD

The work underneath the method

The Playbook was not written first and illustrated later. It was distilled backward from auditing, curating data, iterating candidates, and blind-reviewing a real set of meeting AI workflows.

6

execution SOPs

Contract, dataset, candidate, evaluation, reporting, and blind review

64 / 64

LLM nodes

Evidence guards and root status constraints applied

134 / 165

nodes / edges

Graph structure held constant to isolate the variable

20 × 2

frozen cases × runs

Candidate cleared the Contract P0 gate twice

05 / DECIDE

A real decision—not just an attractive win rate

In a blind A/B on 20 frozen cases, the candidate won 17 of 19 decisive cases. More importantly, the same review surfaced two long-context cases where the baseline was better.

89.5%

decisive candidate win rate

17 wins / 2 losses / 1 tie

0 / 20

candidate P0 defects

baseline: 16 / 20

4.95 / 5

candidate faithfulness & evidence

baseline: 2.60 / 5

06 / TOOL

Why Dify Workflow

Dify was not chosen because a visual canvas automatically improves quality. Nodes, routes, variables, fallbacks, and an exportable DSL give product hypotheses an inspectable carrier. The team can discuss which guarantees belong in code, which judgments belong to models, and where information disappears. It is a useful test bench; evaluation discipline still has to be built around it.

07 / REUSE

Take the method with you

The public edition removes internal business, data, and environment details while keeping a reusable operating skeleton: two dataset tiers, three evaluation layers, single-variable campaigns, blind review, and explicit claim boundaries.

  • Five-step flow and six-SOP index
  • Dataset and campaign folder structures
  • Release gates and verdict template
  • Checklist of domain contracts to replace
Download the public Playbook ↓