IRONWOOD
Evidence-grounded analysis with explicit decision boundaries.
IRONWOOD studies AI-assisted analysis where a useful answer must be supported by identifiable evidence and remain within a defined scope of action. It evaluates the entire workflow, including retrieval, synthesis, authorization, and human review.
Can a system recognize when it should not answer or act?
IRONWOOD investigates AI systems that work with incomplete or conflicting evidence. Its focus is a supported, reviewable response within an explicitly defined task, including the ability to identify unresolved questions and withhold a conclusion.
Evaluation includes the full system: retrieved material, model output, tool permissions, and the handoff to a human reviewer. A successful response must be assessed against the available evidence and the actions the system was permitted to take.
| Test condition | Behavior to evaluate |
|---|---|
| Missing evidence | Abstain or request the information needed to support a conclusion. |
| Conflicting sources | Expose the disagreement and route unresolved cases to review. |
| Out-of-scope action | Respect the authorization boundary and record the attempted action. |
| Changed input | Reassess the answer and identify which supporting evidence changed. |
Evidence model
The unit of evaluation is the claim.
Document retrieval and answer support are separate problems. A relevant document may omit the requested fact. A correct citation may point to a passage that does not support the attached statement. Evaluation therefore tracks the relationship between a claim and a specific source span.
Document identifier, version, effective date, and access scope.
The exact span used to support, qualify, or contradict a claim.
A statement evaluated as supported, contradicted, or insufficiently evidenced.
Answer, qualification, abstention, or escalation to a reviewer.
Separate usefulness from unsupported confidence
Evaluation records both the fraction of tasks answered and the error among answered tasks. A system that refuses everything has low exposure to error but little utility; one that answers everything may hide substantial unsupported content. The decision threshold is evaluated across that tradeoff.
Checks also distinguish retrieval failure, source interpretation failure, missing qualifications, and unsupported synthesis. This helps locate a failure in the workflow instead of attributing every error to the model.
Application context
Reconciling a changing technical record.
An analyst asks for the current operating condition of a system. One document describes an earlier configuration, a later note introduces an exception, and a third source uses an ambiguous component name. An adequate answer must resolve time and identity, preserve the exception, and expose what remains uncertain.
If the workflow includes a tool call or downstream action, permission is evaluated independently of answer quality. An accurate analysis does not by itself authorize a change to another system.
- Method
- Construct held-out tasks with traceable evidence, deliberate omissions, and contradictory sources. Compare the same system with and without retrieval, review, and permission constraints.
- Evaluation
- Assess evidence support, citation accuracy, appropriate abstention, unauthorized-action attempts, and reviewer correction burden. Report failure categories as well as aggregate scores.
- Output specification
- An evaluation harness specification, an evidence-trace format, and criteria for escalation or refusal within a bounded workflow.
Evaluation protocol and limitations
Score the evidence, not the presentation
Define what constitutes a supported answer before reviewing outputs. Use a documented annotation rubric and independent adjudication for disputed cases.
Preserve the decision record
Record the retrieved source versions, model and prompt versions, tool requests, permission decisions, and reviewer interventions. A citation alone does not establish that a claim is supported.
Boundary of the study
An evaluation can characterize performance on its test distribution; it cannot guarantee behavior on every future input. A deployment decision requires task-specific review and ongoing monitoring.
Methodological reference: NIST, AI Risk Management Framework — Measure.