Evidence state: Framework. Methodology framework only. No completed HoopAI benchmark, customer result, model comparison, or empirical performance finding is reported. Illustrative examples are not observed results.
Protocol state. This is an unexecuted adversarial-testing plan. No completed HoopAI hallucination study, safety result, customer deployment finding, or comparative model claim is presented.
The method treats unsupported behavior as a property of a configured workflow under a defined evidence boundary, not as a permanent trait of one model.
Every conclusion must remain tied to the tested task, evidence conditions, and system version.
Replace the label with observable events
The word hallucination can hide several failures. A test needs events that reviewers can locate in an output, citation, proposed action, or changed record.
An unsupported event may be an invented entity, altered number, false attribution, nonexistent policy, fabricated meeting outcome, or confidence that exceeds the available evidence.
A workflow can also fail by selecting the wrong account, using a stale source, merging two people, or proposing an action that the record does not authorize.
Focused research question
When evidence is missing, conflicting, stale, or misleading, does the configured workflow remain within approved sources and choose uncertainty or escalation instead of invention?
The unit is one evidence challenge. It includes the source packet, user request, retrieved material, response, proposed action, and expected safe behavior.
Create a threat-led case taxonomy
Start from failure mechanisms found in the target process. Do not rely only on strange prompts that bear little resemblance to customer work.
- Absence: a requested fact does not exist in the approved record.
- Conflict: two allowed sources disagree and their authority is not equal.
- Staleness: an older statement looks credible but has been superseded.
- Collision: similar names or identifiers invite cross-record contamination.
- Instruction pressure: the request asks for certainty, action, or detail the evidence cannot support.
- Retrieval distraction: irrelevant material appears more similar than the authoritative source.
Map each case to one primary mechanism and any secondary risks. The taxonomy allows results to reveal why a workflow failed instead of reporting only that it failed.
Use paired and counterfactual cases
Construct pairs that change one evidentiary condition. A supported renewal date becomes absent, a current policy becomes superseded, or a correct account name gains a near duplicate.
The expected behavior should change with the evidence. If the output stays confident across both versions, the pair exposes insensitivity to source support.
Add benign controls that look similar but contain adequate evidence. A system that refuses everything may avoid inventions while failing the actual customer task.
Cases may use synthetic records or properly governed data. For every case, preserve the authoritative facts, forbidden claims, expected escalation, and reason for inclusion.
Keep final cases sealed from prompt authors until configuration choices are frozen. Document any later correction to an answer key as a protocol amendment.
Annotate at the smallest useful claim
Reviewers should split the output into atomic factual propositions and material recommendations. Each item receives a support label, not one impressionistic score.
- Supported: the allowed evidence entails the proposition at the stated level of certainty.
- Contradicted: an authoritative source conflicts with the proposition.
- Unverifiable: the permitted packet cannot establish or refute it.
- Outside task: the statement exceeds the requested or permitted scope.
Review source references separately. A citation can be real yet fail to support the attached statement, or point to a source prohibited for that workflow.
Score language, answer, and action apart
Uncertainty language matters only when behavior follows it. A cautious sentence paired with an unauthorized CRM update is still an operational failure.
Score factual support, calibration, citation accuracy, entity integrity, escalation, and action correctness as distinct outcomes. Mark critical events without dilution.
Potential measures include unsupported proposition rate, case-level critical failure count, correct abstention, supported completion, and escalation precision.
These are proposed measures, not reported values. The protocol should define denominators and aggregation before any system is run.
Reviewer safeguards
Use one reviewer familiar with the source domain and another trained in the annotation guide. They should work independently on a meaningful subset.
Adjudication should cite the exact evidence and rule. If a statement depends on interpretation, retain the disagreement and refine the expected behavior.
Hide configuration identity where practical during comparative review. Remove customer identifiers and restrict access according to the data-governance plan.
Diagnose the layer that failed
Trace each event to content, retrieval, generation, orchestration, permissions, or user-interface behavior. Fixing prose cannot correct a retrieval index that returns the wrong account.
Preserve reviewed failures as regression cases, but maintain a fresh holdout. A growing regression set can become familiar and overstate resilience to new patterns.
Reading the eventual evidence
A low observed error count would mean only that few annotated failures appeared in this version and case set. It would not prove that the workflow cannot invent.
Interpret by mechanism and consequence. The system may handle absent facts well while remaining vulnerable to stale sources or cross-record collisions.
Use the outcome to narrow permissions, improve source authority, add review, or block an action. Do not translate it automatically into a general safety claim.
Boundaries and disclosure
No finite challenge set covers every source change, language, adversarial strategy, or downstream integration. Synthetic cases may omit social and organizational context.
Human annotation can miss subtle implications and can disagree on what evidence entails. The protocol does not establish legal compliance, privacy, security, or field reliability.
A later report must state the taxonomy, sampling, data provenance, system version, reviewer process, protocol changes, results, uncertainty, and unresolved examples.
NIST's generative-AI risk material informs this design but supplies no HoopAI evidence. This paper remains a framework until an independently reviewable run is completed.
Methodology
Build a taxonomy of unsupported behavior: invented entity, false attribution, altered number, unsupported policy, fabricated event, source confusion, hidden uncertainty, and unsafe action suggestion. Create controlled cases for each type using synthetic or governed data. Include realistic distractors and near-duplicate records rather than only trick prompts. Record the authoritative source for each expected fact and run all cases against a frozen system version.
Reviewers should mark each factual unit as supported, contradicted, unverifiable, or outside scope. Score whether uncertainty was explicit, citations or source references were correct, and escalation matched the task contract. Evaluate proposed record changes, routing, and messages separately. Count critical errors by type and preserve examples for diagnosis instead of collapsing everything into one average.
Limitations
- No finite adversarial set covers every unsupported response or future source change.
- Reviewers may disagree about whether a statement is implied or directly supported.
- Synthetic examples can miss social and organizational context in customer work.
- This protocol does not prove safety, accuracy, or suitability outside the tested task.
Sources
- NIST AI 600-1, Generative AI Profile: Public generative-AI risk reference. It provides no evidence of a HoopAI implementation or satisfied control.
- NIST AI Risk Management Framework: Voluntary risk-management reference. It informs terminology and review questions; it does not validate HoopAI or any result in this framework.
Notes
Methodology framework only. No completed HoopAI benchmark, customer result, model comparison, or empirical performance finding is reported. Illustrative examples are not observed results.
