Evidence
Agentic AI evidence library
A credible agentic AI case study identifies the workflow, boundary, release, controls, failure tests, measured outcomes, limitations and customer-approved evidence behind every claim.
Case studies are useful only when their claims can survive diligence. A customer logo, a polished quote and an unqualified percentage do not explain the system boundary, measurement method or risk accepted. Trunnion does not publish placeholder customer stories. Named deployment pages will be added only after the evidence and publication rights exist.
What should every case study disclose?
| Evidence field | Minimum disclosure | Why it matters |
|---|---|---|
| Workflow | Trigger, decisions, tools and side effects | Defines what was actually automated |
| Boundary | Included systems, data and users | Prevents broad claims from a narrow pilot |
| Stage | Evaluation, pilot or production | Separates learning from operating proof |
| Release | Version, date and configuration | Makes the claim time-bound |
| Controls | Policy, approval, identity and audit design | Shows how authority was bounded |
| Tests | Ideal, denial, tamper and failure paths | Demonstrates behavior beyond a demo |
| Measures | Definition, denominator and observation window | Makes outcomes interpretable |
| Limitations | Known gaps, exclusions and residual risk | Prevents evidence from becoming advertising |
| Approval | Customer and Trunnion publication owner | Establishes permission and accountability |
If a field cannot be disclosed, the study should say so and narrow the conclusion.
Which deployment stages should not be conflated?
An internal prototype demonstrates feasibility. An evaluation measures behavior under a defined test plan. A pilot introduces representative users or data within a limited boundary. Limited production carries real consequence under restrictions. Scaled production adds operational history, support and change control.
Each stage supports different claims. A prototype can show an interaction pattern. It cannot establish production reliability, compliance or return on investment.
How should outcomes be measured?
Define the baseline and unit before collecting data. "Faster" is not a measure. "Median analyst handling time for eligible requests during a defined observation window" can be, if the exclusions and sampling method are retained.
Use a balanced evidence set:
- task success and quality under a reviewed rubric;
- denied and escaped unauthorized actions;
- percent of actions sent for approval and reviewer handling time;
- exceptions, retries, duplicate attempts and reconciliation work;
- audit-event coverage and verification status;
- human rework and escalation rate;
- infrastructure, model and operator consumption;
- incidents, near misses and unresolved limitations.
Report counts with rates. A zero-event claim without the number of opportunities and observation period is weak evidence.
What negative evidence belongs in the story?
Readers need to know what failed. Include denial tests, dependency outages, policy misconfiguration, reviewer backlog, model drift, malformed tool responses and evidence-store failure. Explain the expected safe state and what the system actually did.
A useful case study can conclude that a control or workflow was not ready. Publishing the limitation makes the evidence more trustworthy and shows where engineering effort is going.
How should customer confidentiality be protected?
Use an approved disclosure plan before drafting. Separate facts that are public, facts that can be generalized and facts that must remain private. Remove operational detail that could reveal mission, vulnerability, identity, geography or system topology.
An anonymized study still needs an evidence owner. "A federal customer" is not permission to imply authorization, certification, fielding or endorsement.
What will Trunnion publish when evidence is ready?
Future named studies will follow a stable structure: context, bounded workflow, architecture, controls, test design, observed outcomes, limitations, customer-approved statement, evidence date and related technical artifacts. Every metric will name its measurement basis.
Until then, technical evaluators can use the public reference audit specification, interactive verifier and comparison framework to build a diligence plan without relying on invented social proof.
Direct answers
Frequently asked questions
Why are there no named customer case studies here?
Trunnion will not publish a named customer, outcome or deployment detail without documented consent and substantiation. This page defines the evidence standard that future studies must meet.
What makes a case study auditable?
It states the exact system boundary, release, dates, measurement method, denominator, exclusions and evidence owner so a reviewer can reproduce the claim.
Can a pilot be described as production?
No. Discovery, prototype, evaluation, pilot, limited production and scaled production are different stages and should be labeled accurately.
Which metrics matter for governed agents?
Useful measures include task quality, exception rate, unauthorized-action rate, approval burden, investigation time, recovery behavior, evidence completeness and operating cost.
How should confidential deployments be discussed?
Publish only approved facts, aggregate where necessary, state what is withheld, and avoid hints that let readers infer protected mission, customer or architecture details.
What evidence can a buyer request privately?
Subject to authorization, buyers can request a reference architecture, control matrix, test plan, sample evidence package, limitation register and release-specific demonstration.
Reference desk
Primary sources
External standards remain authoritative for their own requirements and status. A Trunnion mapping does not create a certification or authorization.
