Evaluate the Feature, Not the Demo

A demo asks whether one carefully chosen example can work.

A feature evaluation asks how often the product contract holds across the inputs, states and failures users will actually encounter.

Both have value. Confusing them is the problem.

1. The unit of evaluation is the feature

“Evaluate Gemma 4” is too broad for our application. “Evaluate this prompt” is too narrow.

The useful unit is something a user attempts:

summarize selected documentation
rewrite permission copy without changing authority
detect language and decide whether to translate
produce structured arguments for a read-only tool

Each feature includes input preparation, capability selection, model output, validation, fallback and UI behavior.

The model is one component in that system.

2. Start with a written contract

Before collecting examples, state what success means:

feature: summarize-selection
must:
  - preserve warnings and negation
  - distinguish browser and application responsibilities
  - remain grounded in selected text
must_not:
  - invent browser guarantees
  - expose uncaptured page content
may:
  - vary wording and bullet order
abstain_when:
  - selection contains insufficient prose

This contract determines fixtures and metrics. Without it, evaluation becomes a search for numbers that look impressive.

3. Cases need slices

An aggregate pass rate can hide a product-breaking subgroup.

For summarization, useful slices include:

• short, medium and near-limit inputs;
• prose, lists, tables and mixed code;
• warnings, negation and quantities;
• one language and mixed languages;
• clean content and prompt-injection-like text;
• available, downloadable and unavailable runtime states.

For language detection, length and ambiguity deserve separate slices. For rewriting, protected terminology and modal verbs matter.

A fixture should carry its slice labels:

{
  "id": "summary-warning-03",
  "feature": "summarize-selection",
  "slices": ["warning", "negation", "short"],
  "input": "...",
  "assertions": ["..."]
}

Now a regression can be localized.

4. Baselines stop us rewarding unnecessary AI

Every AI feature should compete with a simpler alternative.

Possible baselines include:

• show the original selection;
• extract the first sentence;
• use a deterministic template;
• apply a rule-based language threshold;
• ask the user to choose the language;
• disable the feature.

If a generated summary saves little time while occasionally dropping warnings, the original-text baseline may be better.

The relevant comparison is not “AI versus nothing.” It is “this feature path versus the best practical alternative.”

5. Repetition reveals instability

One run cannot characterize a probabilistic component. Even a most-predictable sampling mode should not be assumed identical across browser versions, model updates and hardware paths.

For case $i$ across $r$ repetitions, record:

Retain each output. Replacing failed runs with successful retries converts evaluation into selection.

6. Pair comparisons when the environment changes

To compare browser configurations, use the same fixture and decision rules:

fixture A → baseline configuration → result A₀
fixture A → new configuration      → result A₁

The most useful question is often not absolute score but changed outcome:

Review changed cases directly. A one-point aggregate improvement can conceal a severe regression in permission handling.

7. Release gates encode risk, not taste

A release gate should connect failure to consequence:

gates:
  - name: no_authority_regressions
    slices: [permission, approval, data-route]
    allowed_new_failures: 0
  - name: summary_quality
    minimum_pass_rate: 0.90
  - name: operational_availability
    minimum_supported_cases: 0.95

High-risk invariants can require zero known regressions. Lower-risk style preferences may tolerate variation and human review.

A gate does not prove universal safety. It prevents a known release from becoming worse on the cases we chose to protect.

8. Operational and behavioral matrices belong together

For every fixture run, preserve both:

This allows questions such as:

• Did quality fall only on cold runs?
• Did the new configuration become faster but less reliable?
• Are failures caused by unavailable APIs or rejected output?
• Does context pressure correlate with lost instructions?

Separating the matrices would discard those relationships.

9. Evaluation data has a lifecycle

Browser content may be private. A useful interaction is not automatically permissible evaluation data.

The harness needs policies for:

• explicit collection scope;
• content redaction;
• retention and deletion;
• access to exported traces;
• whether human corrections may be reused;
• separation of public fixtures from private incidents.

Synthetic and public fixtures should carry provenance too. They can be unrealistic or accidentally encode the expected answer in their wording.

Data quality is part of evaluation quality.

10. Prevent evaluator leakage

If a prompt contains the exact expected phrase only because the assertion searches for it, the case may test copying rather than understanding.

We should distinguish:

• instructions necessary for the feature;
• protected facts present in the source;
• evaluator-only expectations hidden from generation;
• reference answers used only for review.

The fixture runner should not place hidden rubric text into the model context.

This sounds elementary, but compact demo fixtures frequently leak their own solution.

11. A failure needs an investigation path

An evaluation report should lead back to evidence:

release gate failed
    ↓
slice: permission
    ↓
fixture: writer-permission-copy
    ↓
run and browser configuration
    ↓
prompt trace
    ↓
failed assertion and human rationale

A score without this path is difficult to improve and easy to game.

Browser AI Observatory already has correlation IDs, run envelopes and fixture events. Part IV extends those primitives into comparisons and gates rather than inventing a separate evaluation universe.

12. The first release gate should be small

Our initial seven fixtures are not a complete benchmark. They are a canonical smoke suite covering the Prompt API and six task APIs.

The first useful gate can require:

1. every required API state is classified;
2. no metrics-only trace retains input content;
3. all structural assertions pass;
4. every human rubric receives a decision;
5. no protected authority statement regresses;
6. changed browser configurations produce a comparison report.

This gate is modest enough to maintain and strong enough to catch failures the demo path hides.

Conclusion

A demo establishes possibility. An evaluation characterizes a feature contract over selected evidence.

Representative slices, simple baselines, repeated runs, paired comparisons and risk-based gates turn isolated outputs into engineering decisions. The evaluation remains incomplete, but its incompleteness is visible and actionable.

The next chapter handles a different source of incompleteness: sometimes the local capability is absent. Reliable browser AI must degrade deliberately without silently changing where user data goes.

Sources and further reading

1. NIST, Artificial Intelligence Risk Management Framework.
2. Chrome for Developers, Built-in AI APIs.
3. Chrome for Developers, The Prompt API.