| Metric | Current | Candidate | Δ |
|---|---|---|---|
| Grounded answers | 88.0 | 92.2 | +4.2 |
| Tool recovery | 91.6 | 93.4 | +1.8 |
| Latency | 680 ms | 800 ms | +120 ms |
| Mandatory regressions | 0 | 0 | 0 |
Release gateGATE HOLD
Latency budget requires owner review.
Evaluation & Observability
Iris AI
by OKAI SolutionsSee what changed before you release.
An evaluation workbench for comparing prompt, model, retrieval and tool changes against a team’s own versioned test cases.
See how it works ↓- Used by
- AI engineering teams, QA engineers and technical product owners
- Inputs
- Versioned evaluation cases, reference answers, traces and candidate system configurations
- Produces
- A reproducible comparison report, failure clusters, cost and latency signals and a reviewable release decision
What happens when Iris AI is in the loop.
A prompt, model or retrieval change can improve a demo while quietly breaking cases that matter in production.
Iris runs both versions against the same dataset, groups failures and links every score back to the underlying trace.
The release owner sees what improved, what regressed and whether the candidate meets the agreed gate.
Inside Iris AI
The current and candidate systems face the same cases before a release owner sees the gate.
Acceptance targets
These are validation criteria for a scoped pilot. They are not presented as observed customer results.
Every run records dataset and system versions
Every seeded mandatory regression blocks release
Every failure links to its source trace
Latency and model usage are reported for every included request
Start with the workflow
Contact OKAI →