# Know what changed before your AI goes live.

AI evaluation & assurance

Test unsupported answers, prompt injection, data leakage and tool misuse before approving a release.

## A release decision with evidence

Illustrative workflow.

- Grounding: Claims supported by permitted sources
- Action safety: Unauthorised tool calls rejected
- Regression: Candidate compared with the current release



## A better demo is not a release criterion

Build a versioned evaluation set from real tasks, difficult cases and expected refusals. Compare changes to prompts, models and retrieval against the same evidence.

Illustrative scenario, not a customer case study.

An Australian business needs evidence that a proposed assistant improves a specific operational task.

Build a versioned set of representative, difficult and unsupported requests. Separate development examples from held-out checks and record expected behaviour before tuning.

Verification: Report performance by task and failure severity, including refusals and escalation, rather than one average score.

## What needs attention in your system?

Select the areas you want to discuss. The HTML page can download your selections.

- [ ] Representative tasks: Build an evaluation set that includes ordinary requests, difficult cases and expected refusals.
- [ ] Regression comparisons: Compare model, prompt and retrieval changes against the same versioned inputs and acceptance criteria.
- [ ] Operational evidence: Review traces, cost, latency and failure behaviour alongside answer quality before approving a release.
- [ ] Tool behaviour: Exercise denied permissions, malformed inputs and interrupted actions as part of the evaluation.
- [ ] Adversarial inputs: Test hostile document instructions and requests that try to cross the application’s trust boundaries.
- [ ] Release comparison: Retain model, prompt, source and configuration versions so an unexpected result can be investigated.

## Look beyond the average score.

### Representative tasks

Build an evaluation set that includes ordinary requests, difficult cases and expected refusals.

### Regression comparisons

Compare model, prompt and retrieval changes against the same versioned inputs and acceptance criteria.

### Operational evidence

Review traces, cost, latency and failure behaviour alongside answer quality before approving a release.

### Tool behaviour

Exercise denied permissions, malformed inputs and interrupted actions as part of the evaluation.

### Adversarial inputs

Test hostile document instructions and requests that try to cross the application’s trust boundaries.

### Release comparison

Retain model, prompt, source and configuration versions so an unexpected result can be investigated.

## Release confidence comes from the difficult cases

### Judge a handful of good answers

Selected examples miss harmful regressions, missing citations and cost changes under realistic traffic.

### Review an explicit release record

Keep task results, failures, latency and cost together. Record who accepted the remaining limitations and the rollback trigger.

## Can a single score decide whether a model is ready?

Usually not. Separate task quality, access control, action safety, response time and cost. A critical permission failure must not disappear inside an average score.

## Read the engineering behind it

- [A better demo is not an evaluation dataset](https://cobnex.com.au/blog/ai-evaluation-datasets-architecture-decision-guide)
- [Find the development example hiding in the test set](https://cobnex.com.au/blog/ai-evaluation-datasets-failure-testing-walkthrough)
- [Investigate disagreement between human evaluators](https://cobnex.com.au/blog/ai-evaluation-datasets-operations-runbook)