AI-300: Choosing Quality, Safety, and Custom Evaluation Gates

Introduction

Choose quality, safety, and custom evaluation gates by naming the failures a release must detect. Use groundedness for support from supplied evidence, relevance for answering the request, coherence for logical flow, and fluency for readable language. Evaluate safety risks separately, and add deterministic or domain-specific checks where general quality scores cannot express an application requirement.

Turn those measurements into decisions before running the candidate: define required evidence, score interpretation, acceptance criteria, blocking failures and the action taken when a result is missing or disputed. A release gate should be able to hold an incomplete evaluation, reject a confirmed critical failure, or request a targeted revision. An attractive average alone should not authorize promotion.

What Is an Evaluation Gate?

An evaluator produces a measurement; a gate is the application's policy for acting on evidence. The same metric might inform diagnosis in one application and block a release in another. Recommend documenting each gate's purpose, evaluator/version, required inputs, score direction, criterion, owner and failure action.

Begin with the dataset and mapping contract from AI-300: Preparing Evaluation Datasets and Field Mappings. Foundry's input requirements depend on the evaluation scenario and selected evaluators. In target evaluation, Foundry generates the response and ignores any response already stored in the input row. Confirm that the evaluator consumes the intended output before interpreting its score.

This article assumes those inputs are prepared. It addresses evaluator selection and release judgment, rather than rebuilding dataset schemas or designing a production monitoring system.

Why Separate Quality from Risk?

A response can be fluent, coherent and relevant while making an unsupported claim. It can accurately repeat source material while failing to answer the current request. It can also satisfy an output format and still violate the application's safety requirements. Distinguishing these outcomes makes the failure actionable.

Use a failure-to-signal map rather than choosing every available evaluator:

The action column is a proposed release policy, not an automatic Foundry remediation feature. Validate the failure itself before choosing which component to change.

Core Concepts for Choosing Evaluators

Built-in quality and safety signals

Foundry's built-in catalog distinguishes groundedness and relevance from coherence and fluency. Its standard Groundedness evaluator uses model judgment on a 1–5 scale. Groundedness Pro is a separate preview evaluator with binary output, not an interchangeable score format.

The risk catalog includes harmful-content categories and more application-specific concerns such as indirect attacks, prohibited actions and sensitive-data leakage. Select risks relevant to the application's allowed behavior; a quality score does not establish that those risks were tested.

Keep each evaluator's scale and direction explicit. Do not apply one “higher is better” rule to every quality score, risk severity, error flag and binary result. Also distinguish a rating from a probability: a model-generated score should not be described as a calibrated chance that an answer is safe or correct.

Deterministic, model-judged and custom checks

Use deterministic checks when the criterion has a clear mechanical definition: required fields, allowed values or a response-length contract, for example. These checks are easier to audit against their specified rule, but passing them says only that the rule was satisfied. Valid structure does not prove a supported answer.

Use a model judge when the criterion requires a semantic judgment, such as whether the answer addresses the question or is supported by context. Define the rubric and inputs precisely, and retain the rationale where available so reviewers can inspect disagreements.

Current Foundry custom evaluators are preview and offer three approaches:

The endpoint approach introduces a service dependency whose authentication, reachability and failures need review. Do not treat outsourcing the computation as outsourcing responsibility for the rubric.

Calibrate the judge as well as the application

Recommend checking evaluator behavior against a small reviewed calibration set with clear passes, clear failures and borderline cases. Include fluent unsupported answers, faithful but irrelevant answers and appropriate refusals. Compare judge decisions with qualified review rather than accepting the judge's own explanation as proof.

Investigate false positives and false negatives separately. A false safety alarm can block useful behavior; a missed harmful response can let a serious failure through. A relevance judge that rewards verbosity may also obscure incomplete answers. These are evaluator failure modes to investigate, not claims that a particular deployed judge exhibits them.

Version the judge configuration, model reference, rubric and acceptance policy alongside application evaluation evidence. If those change, reassess comparability with the baseline. Repeating a disputed case can reveal variation, but repeatedly running it until it passes is not a defensible acceptance rule.

Turn Signals into Release Decisions

Define the policy before inspecting results

Recommend this order of decisions:

1. Check execution completeness: required records, evaluators and mappings produced usable results. Hold the decision if evidence is absent or invalid.
2. Check hard application contracts and explicitly blocking risks. A confirmed critical failure blocks release even when average quality improves.
3. Check quality floors and regression limits for the overall set and important query groups. Investigate a weak group instead of hiding it in the aggregate.
4. Review custom criteria and judge disagreements. Resolve material uncertainty or keep the decision on hold.
5. Authorize promotion only when the required evidence and review conditions are met. Preserve the accepted baseline for comparison and recovery.

Choose numerical thresholds from the application's risk tolerance and reviewed examples. There is no universal groundedness floor, permitted safety-failure rate or domain score that establishes production readiness for every system. Record the denominator and missing records with any pass rate.

Use a concrete failure example

Consider a hypothetical support assistant answering from approved device instructions. Suppose the candidate writes a polished answer that recommends an undocumented replacement procedure. Groundedness evidence matters even if fluency is excellent. The proposed action is to hold promotion, inspect the claimed support and revise the application if the claim is unsupported.

Now suppose a response accurately repeats instructions for a different device. Groundedness alone may look satisfactory while relevance fails. Or suppose the answer is relevant but omits a mandatory escalation field: a deterministic contract check can identify a different failure. These examples demonstrate why the gates should remain independently visible rather than collapse into one weighted quality number.

For a risk flag on an ambiguous test item, preserve the item, flag and reviewer disposition. A disputed judge result needs adjudication; it should not be silently removed to improve the pass rate. No actual scores or run outcomes are claimed in this example.

Automate evidence collection and explicit outcomes

Recommend implementing evaluation comparisons in the application's validation process with frozen input identities and recorded candidate, baseline and evaluator revisions. Collect per-item scores, execution status, exceptions and skipped results. Apply the agreed policy to produce a release recommendation, revision request or hold, with the failing cases attached for review.

Check evaluation level as well as run completion. The built-in reference says conversation-level runs skip turn-only evaluators. A completed run therefore does not establish that every intended criterion ran. The custom-evaluator documentation also says code errors or timeouts can produce a numeric zero with an error marker; inspect status rather than treating that number solely as measured application quality.

Keep pipeline behavior application-owned. Registering an evaluator or obtaining results does not create a complete approval process. Define who may approve, how a blocking result is handled, and what evidence must be rerun after a targeted change.

Preview Boundaries and Technical Value

The current references mark custom evaluators and selected built-ins as preview. Microsoft states that preview items have no SLA and are not recommended for production workloads. Groundedness Pro, Response Completeness and rubric evaluation are examples that require this qualification; do not present their availability as universal production support.

Keep preview experimentation within an authorized validation scope. For a required production control, select a supported implementation and review its service terms and operational dependencies. A deterministic application check implemented outside the preview feature is a separate implementation decision, not a claim that preview registration becomes generally available.

Evaluation authors define the signal; application owners connect failures to remedies; reviewers assess disputed evidence; release owners apply the approved policy. Making these responsibilities visible gives the gate technical value: the team can explain why a candidate was accepted or which change should be tested next.

Common Learning Challenges

• Treating groundedness as factual truth independent of the supplied context.
• Letting fluent language compensate for a risk or contract failure.
• Selecting a custom judge before determining whether a simple deterministic rule is sufficient.
• Comparing results after changing the evaluator or rubric without recording the change.
• Counting missing, skipped or failed evaluations as successful coverage.
• Assuming a registered evaluator automatically blocks application deployment.
• Using preview labels inconsistently across experiments and production recommendations.

Production sampling, alert ownership and ongoing quality investigation belong in AI-300: Monitoring Generative AI Quality, Latency, and Cost Drivers. A pre-release evaluation decision is one source of operating evidence, not a substitute for that monitoring design.

Conclusion

Choose evaluators from the failures that matter, then define how evidence changes the release decision. Keep quality dimensions, risk checks and application-specific criteria distinct; calibrate model judges and inspect execution failures. A useful gate produces an explainable action with complete evidence, not merely a favorable score.

Authoritative Sources

• Evaluation dataset schema in Microsoft Foundry
• Built-in evaluators reference
• Custom evaluators (preview)

Related Reading

• AI-300: Preparing Evaluation Datasets and Field Mappings
• AI-300: Monitoring Generative AI Quality, Latency, and Cost Drivers