The Three-Step Process

What counts as "good" is not solely on your system; it depends on your product's use cases and why you are evaluating it as well.

To develop a well-rounded definition, we recommend a three-step process to help ensure relevance, coverage, and agreement:

1Reflect on purpose

Why are you evaluating?

• Improve the system
• Compare products
• Support a decision

What is the product for?

• Mission
• Intended users
• Existing requirements

↓

2Expand for coverage

Dimensions

• Functionality
• Safety
• Robustness
• Reliability

Granularity

• End-to-end
• Subsystem
• Component

Perspectives

• Business
• System
• Operational

↓

3Agree the list

Your definition of “good”A short list of qualities the product must show, agreed with your stakeholders

---

Step 1: Reflect on purpose

"Good" is not a property of the system alone. It relies on two aspects:

1a. Why are you evaluating?

Although non-exhaustive, evaluation purposes generally fall into three broad categories, each with a different emphasis.

Explore below to see which one best matches your situation:

Improve the systemWhat do I fix next?

You are deep in development. The system mostly works, but something is off and you need to know which part to fix.

Overall Goal

Identify what is lacking or does not meet the desired standard.

Areas of Emphasis

Functional aspects and user experience.

Outcome

System can meet the standard and deliver the intended outcomes for users.

Compare productsWhich one do we pick?

You have a few options on the table, Model A, Model B, and Model C, and you need to choose between them.

Overall Goal

Choose between models, vendors or configurations.

Areas of Emphasis

Functional and operational aspects that matter to the product's users and stakeholders.

Outcome

The option chosen is the best fit for the product's intended use and context.

Support a decisionAre we ready to ship?

The big red launch button is there, but the question of whether the system is good enough to move forward remains.

Overall Goal

Give relevant stakeholders concrete evidence for a decision such as "ready to launch?".

Areas of Emphasis

Functional, safety, reliability and operational aspects that matter to the product's users and stakeholders.

Outcome

Every stakeholder, including non-technical ones, can make an informed decision about whether the system is ready to ship.

You can have more than one purpose

The above purposes are not mutually exclusive; combine them if necessary.

1b. What is the product for?

Your evaluation should reflect what your product intends to achieve. While this sounds straightforward, you first need to understand the context in which your product intends to operate.

Write down:

• The product's mission, in one sentence. What job does it accomplish, and for whom?
• Its intended users. What does a successful interaction look like from their side?
• Any existing requirements or specifications. Expectations that are inherited from the product's users and operational context, rather than defined from scratch, such as service standards, policy constraints or security requirements.

What if I cannot answer these yet?

That is a useful finding in itself. If your team cannot clearly articulate the product's purpose, work with the product owner to establish a shared understanding before proceeding with the evaluation, as subsequent steps depend on it.

If no written requirements exist, note this as well. The qualities identified in this chapter can serve as a starting point for defining them.

Step 2: Expand the list for coverage

While Step 1 lays the groundwork for the initial list of specifications, Step 2 helps identify potentially overlooked specifications by checking for blind spots through three lenses: dimensions, granularity and perspectives.

Review the list generated in Step 1 through each lens, and add any that is missing:

2a. Look across dimensions

Dimensions are different qualities along which you judge a system for. Here are some common ones to consider:

Functionality

Does it do its intended job, and how well?

Safety

Does it avoid causing unacceptable harm or breaking hard constraints?

Robustness

Does it keep performing under messy, unusual or adversarial input?

Reliability

Does it perform consistently, at the scale and availability you need?

For more depth on non-functional dimensions

Our Responsible AI team has compiled a comprehensive guide on non-functional dimensions, including fairness and privacy. You can find more information, starting from the safety page of the Responsible AI playbook.

2b. Look across levels of granularity

"Good" can be defined at different levels of detail. How granular you need to be depends on your purpose in Step 1, so that you understand where exactly to intervene.

The suggested tiers below illustrate the different levels and what "good" might look like at each:

End-to-endThe final output the user sees“The chatbot’s answer is accurate.”

SubsystemA stage in the pipeline“Retrieval surfaces the relevant scheme documents.”

ComponentA single model, prompt or rule“The reranker puts the most relevant passages first.”

"Good" might not be the same at every level

A system that might be "good" at a high level might not be "good" at a lower level, and vice versa. For example, while your system might produce a "good" output overall, it might fail to meet specific requirements on a component level.

Consider the implications of choosing each level of granularity carefully, ensuring that it aligns with what you have established in Step 1.

2c. Look from different perspectives

"Good" also depends on who is asking for its definition. Each perspective brings its own question, and its own evidence:

Business“Is the product worth running?”Example signals

• Staff-hours saved
• User satisfaction

System“Does it do its task well, in technical terms?”Example signals

• Task completion rate
• Accuracy
• Output quality

Operational“Does it run smoothly in service?”Example signals

• Response time
• Error rates
• System health

Optional: Additional perspectives to consider

Public-sector products often answer to more than the three introduced above.

Depending on your context, also consider:

• Security: Resilience against adversarial threats.
• Compliance: Legal obligations, including fairness requirements.
• Societal: The broader public outcomes the product is meant to serve.

Here's a simple test: if the perspective considered covers a stakeholder who has a say in the product's direction, it belongs on your list.

Step 3: Agree on the list of what matters

From Steps 1 and 2, you should now have a collection of specifications that could define what "good" looks like for your product. The next step is to consolidate these into a clear, agreed-upon list.

As you refine your list, consider the following:

• Be specific. Use short, concrete descriptions of each specification, such as "factually accurate" or "declines out-of-scope requests", rather than broad terms like "high quality".
• Remove overlaps and reconcile differences. Combine specifications that describe the same quality, and surface any conflicting expectations. Different stakeholders may have different ideas of what matters.
• Check for completeness. Revisit your evaluation purpose, relevant perspectives and existing requirements. Aim for a manageable list without leaving out anything important.
• Reach agreement. Review the list with all relevant stakeholders to ensure a shared understanding of what each specification means and why it matters.

Common pitfalls

As you refine on and check your list, watch out for these recurring mistakes:

• Letting ease of measurement shape the list. Write down what matters, even if you cannot yet see how to measure it; we will address that in Judgement Design.
• Leaving "quality" undefined. Vague specifications only postpone disagreements, instead of resolving them. Make sure each specification is concrete enough to be understood and agreed upon.
• Copying another team's list. Use another team's list only as a starting point; their purposes and stakeholders ultimately differ from yours.
• Defining "good" by yourself. A list without agreement across all relevant stakeholders will make the evaluation exercise less meaningful and less credible.

What you should have by the end of this chapter

An agreed-upon list of specifications that define what "good" means for your product.

This list is the entire output of the chapter, by design: you do not need any judgements, metrics or datasets yet; those come in the chapters that follow.

---

To consolidate your understanding of the three-step process, head over to Worked Examples to see how it is applied in practice.