How to Evaluate an AI Product Against a Domain Expert’s Standards

Domain expert AI evaluation should test whether the product makes the right decision from the available evidence. A fluent answer can still skip a required question or recommend an unsuitable next step. Write the expected behaviour before reviewing the generated answer so attractive wording cannot redefine success afterwards.

Start with one task the product is permitted to handle. Use fictional or approved examples, including incomplete information and cases that should leave the automated path. Do not use a broad claim such as helpfulness as the only scoring criterion.

Turn expert judgment into a scoring rubric

Criterion	Pass evidence	Failure example
Relevant evidence	Uses facts present in the input	Invents a missing constraint
Decision quality	Applies the stated domain rule	Chooses an incompatible next step
Clarification	Asks for the fact needed to proceed	Guesses an essential input
Boundary	Stops or routes the excluded case	Continues outside the supported task
Communication	User can understand the next action	Correct answer is unusably vague

Define a concrete example for every failure. Mark critical failures separately. If inventing an essential constraint makes the output unusable, excellent tone should not compensate for it in an average score.

Build paired cases and calibrate reviewers

Create two inputs that differ in one fact controlling the decision. For example, one request includes a confirmed delivery date while the other includes an unresolved date range. If the expert expects a question in the second case, the evaluation should reject a confident invented date.

Have two practitioners score a small shared set independently. Compare disagreements before testing a large batch. If they disagree about the correct next action, clarify the rule or preserve the ambiguity in the expected outcome. A model cannot be meaningfully scored against a standard the reviewers have not agreed on.

Separate development cases from a fresh check

Keep one set for improving instructions and a separate set for checking the resulting product. Changing a prompt to pass every visible example can produce a narrow fit without demonstrating that the rule generalizes.

In an illustrative evaluation, 24 of 30 development cases pass and eight of ten fresh cases pass. Both rates are 80 percent, but report the counts and the failure categories. If two fresh failures cross a critical boundary, the common percentage hides the release decision. Do not describe these small fictional samples as a performance benchmark.

Review the product change with the same evidence

Case identifier and input version
Expected next action
Permitted alternative answers
Critical boundary
Output and model or product version
Criterion results
Reviewer disagreement and resolution
Change proposed
Result after rerunning unchanged cases

When a failure is found, identify whether it comes from missing input, retrieval, instructions, the model output or the interface acting on that output. Fixing a prompt will not resolve an interface that sends the wrong project context.

Rerun the unchanged cases after a change and inspect newly failing cases as well as the one you intended to fix. The deliverable is a reusable quality standard and a record of observed behaviour. It gives the founder a way to discuss quality without relying on whether the latest demonstration sounded convincing.

Bring three acceptable outputs and three failures you would reject. We can turn those judgments into a practical evaluation rubric. Discuss the first release with Adamant Code.