Executive briefA release folder can be full while the decision remains unsupported

A release committee receives a model card, benchmark report, privacy assessment, penetration test, supplier certificate, risk register and operational runbook. Every document is genuine. No document states the precise proposition the committee must decide: whether this version of this capability is acceptable for the named population, authority, environment and exposure until a defined invalidation event.

A document inventory can show diligence without proving a decision-relevant claim. A benchmark may be rigorous but unrepresentative of the operating population. A process certificate may say little about the supplier endpoint actually deployed. A penetration test may support one attack boundary while the capability still has excessive business authority. Evidence becomes assurance only when an explicit inference connects it to a bounded claim and makes assumptions and counterarguments inspectable.

An AI assurance case is that structured, challengeable argument. It is not a declaration that a system is safe, fair, secure, reliable or compliant in the abstract. The top claim names the capability, version, use, population, authority, environment, exposure and time. Six claim families decompose the proposition. Each claim records acceptance, argument, evidence, provenance, limitations, residual risk, defeaters, monitoring, invalidation, owner, decision, expiry and revalidation.

The case remains live after release. Models, prompts, retrieval sources, tools, policies, populations, workloads and upstream services change. Outcome evidence arrives late. Complaints, near misses and incidents can defeat an earlier inference. A release decision therefore depends on claim coverage, evidence relevance and independence, open defeaters, exposure, recovery and validity conditions. Counting documents cannot manufacture confidence.

The strongest rival: competent engineering and accountable decisions

Clear release criteria, disciplined engineering, incident management and accountable leaders may be more useful than an ornate argument diagram. Poor assurance cases can rationalise choices already made, conceal weak evidence behind structure and become documents no operator uses. Structured notation does not make a weak argument sound.

The method is justified only when claims are decision-relevant, evidence changes the decision, defeaters are actively sought and runtime invalidation can alter operation. Use the smallest argument that exposes the controlling uncertainty. A low-risk summarisation assistant needs a narrower case than a credit recommendation or refund agent. Consequence and recoverability set depth, independence and exposure, but do not prove the top claim.

AI Assurance Case SpineOne top claim, six claim families and explicit validity

The top claim is: this version of the bounded AI capability is acceptably trustworthy for the named use, population, authority, environment and exposure until the stated review or invalidation condition. Every term must resolve to an operational reference. Name the model and system versions, workflow, affected population, decision rights, connected tools, jurisdictions, volume, exposure ceiling and expiry. Replace broad adjectives with acceptance conditions.

For each claim, record precise scope and acceptance; the argument strategy and alternatives; evidence and provenance; relevance, independence, representativeness and freshness; assumptions, context and dependencies; known limitations and residual risk; claim, evidence and inference defeaters; monitoring, invalidation and owner; decision, exception, expiry and revalidation. The record is a decision interface, not a document index.

Claim and argument grammarMake the inference reviewable before collecting more files

A claim states a property of a bounded capability and an acceptance condition. An argument explains why named evidence supports that property under stated context and assumptions. Evidence records observations, tests, artefacts or challenge. A counterargument identifies an alternative explanation, missing condition or fact that could defeat the claim or inference.

Start with the decision, then decompose. For a credit recommendation, the top claim depends on task performance, distribution across relevant groups, explanation adequacy, protected human authority, appeal effectiveness, security, resilience and staffing. The argument may rely on independent outcome analysis, representative tests and field observation. It must also state that the deployment population resembles the evidence population, that reviewers can disagree and that the appeal path reaches someone empowered to correct the decision.

Alternatives are part of the argument. If a deterministic rule, improved information architecture or added staff addresses the legitimate need with less uncertainty, purpose and value remain unproven. The case should show rejected alternatives and the evidence behind the choice. An AI option does not become preferable merely because its isolated model metric is higher.

Use GSN or SACM when structured or machine-readable representation helps review and maintenance. GSN Version 3 offers goals, strategies, context, assumptions, justifications and Source protocols. SACM 2.3 provides a metamodel for claims, argumentation and artefacts. Neither notation makes an unsupported inference valid. A compact prose case with clear links can be stronger than a large diagram whose nodes restate one another.

Assurance Evidence GrammarFive roles answer different questions

Direct evidence tests or observes the claimed property in the intended context. A field evaluation of refusal behaviour in the target population can directly support a bounded limitation claim. Supporting evidence covers design, process or component properties that make the inference more plausible, such as a code review or supplier development control.

Boundary evidence shows where the claim does not apply. It records unsupported languages, populations, tool paths, environments, authority levels and operating loads. Boundary evidence prevents success in one context from silently expanding the claim. Operational evidence covers runtime outcomes, drift, incidents, interventions, complaints, recovery and redress. It can strengthen or defeat a pre-release claim. Challenge evidence contains red-team results, independent review, counterexamples, complaints and unresolved defeaters.

Assess each item for provenance, relevance, independence, representativeness and freshness. Strong testing on the wrong population remains weak support. Independent evidence may deserve more weight for a material claim, yet independence alone does not make it relevant. Fresh evidence can still depend on a failed assumption. No count or percentage converts these dimensions into assurance.

NIST SP 800-53A separates assessment methods, objects and findings. OSCAL can make control implementations, assessment plans and results machine-readable. PROV-O can link evidence to activities and agents. These structures help traceability and change impact. They do not establish that a technical control caused an acceptable human or business outcome.

Defeater-aware assuranceSeek the fact that would make the argument fail

A claim defeater says the proposition may be false, such as evidence that a refusal policy fails for a critical subgroup. An evidence defeater challenges an item, such as data leakage, unrepresentative sampling, stale provenance or supplier configuration mismatch. An inference defeater challenges the bridge from evidence to claim, such as the assumption that offline quality predicts outcomes under production workload.

Record the defeater, affected claim, source, mechanism, possible severity, required inquiry, owner, deadline and disposition. A defeater can be refuted by relevant evidence, accepted through a narrower claim and exposure, controlled by redesign, monitored under a limited release or left open. An open controlling defeater blocks the top claim. Restating the claim, adding unrelated documents or labelling the issue low confidence does not close it.

Negative evidence belongs in the same case as supporting evidence. A subgroup regression after a model update can defeat a limitation claim even if average task performance is unchanged. A field study showing that reviewers follow the model under queue pressure can defeat the human claim despite completed training. A red-team path that reaches prohibited authority can defeat security and governance claims until capability or authority changes.

More evidence should not change the decision when it misses the controlling defeater. Hundreds of new general benchmark cases do not answer whether the retrieval assistant enforces current entitlements. Another supplier certificate does not show the deployed endpoint matches the certified process. Target the uncertainty that controls the decision or redesign the system so the uncertainty no longer matters.

Assurance Validity ClockEvidence expires when the argument's world changes

An annual review date is an administrative backstop, not the validity mechanism. Evidence expires when a version, population, context, authority, policy, upstream dependency or observed outcome crosses a named threshold. Each claim therefore has a clock driven by the conditions that make its inference valid.

Version change includes model, prompt, retrieval configuration, tool contract and policy. Population change includes language, geography, vulnerability, product channel and volume. Context change includes source freshness, data generation and workflow. Authority change includes new actions, higher limits or less human control. Dependency change includes supplier endpoints, identity services and monitoring. Outcome change includes drift, complaints, reversals, incidents and recovery failure.

Connect thresholds to claim-level actions. A new model that preserves average quality but changes subgroup refusal performance expires the performance claim. A tool permission increase expires security, governance and resilience claims. A monitoring gap does not necessarily refute pre-release performance, but it defeats the operational inference that harmful change will be detected. The dependency graph shows which higher claims must reopen.

Expiry can lead to continued operation within a narrower envelope, limited exposure while targeted evidence is collected, containment, or withdrawal. The owner cannot silently extend validity because review is inconvenient. Record the change event, affected claims, decision, evidence request, temporary authority and deadline.

Strength versus relevanceAbundant irrelevant evidence does not increase assurance

Evidence strength asks how credible an item is on its own terms. Relevance asks how directly it bears on the bounded claim. A replicated, independent benchmark may be strong yet have low relevance to a multilingual customer workflow using retrieval, tools and pressured human review. A small field study may be highly relevant but too weak or narrow to carry the claim alone.

Use the matrix to decide the next action. Strong and relevant evidence can support the claim while remaining subject to boundary and challenge. Relevant but weak evidence calls for a stronger method, larger or more representative sample, or corroboration. Strong but irrelevant evidence belongs to a different claim or context and should not influence release. Weak and irrelevant material should be removed from the decision view.

Independence, representativeness and freshness refine the judgement. Development-team tests can provide useful direct evidence for lower-consequence claims but may need independent reproduction where exposure is material. Representative evidence must reflect the intended population and operating conditions. Freshness is tied to the validity clock. Do not translate these dimensions into an unsupported assurance percentage.

Live assurance loopRuntime evidence can invalidate, contain and reargue release

Release activates the validity conditions; it does not close the case. Runtime monitors map to claims and thresholds. Performance monitors cover critical errors and refusal. Rights monitors cover distribution, explanation, challenge and appeal. Security monitors cover attack paths, authority and supply chain. Resilience monitors cover capacity, latency, containment, recovery and exit. Human monitors cover workload, overrides and decision quality.

A threshold crossing opens the affected claim and dependent top claim. The system moves to the pre-agreed response: reduce exposure, disable a capability, require human commitment, contain, reconcile or withdraw. Operations collect the direct, operational and challenge evidence needed to explain what happened. A revised argument then supports restoration, narrower operation or retirement.

Absence of incidents is informative only with credible exposure and detection. A pilot with little use cannot establish a low incident rate. A monitor that misses complaints or downstream reversals cannot support resilience. Link outcomes and affected-person evidence to the case even when they arrive after the immediate transaction.

Governance frameworks, management systems and legal records provide context and duties. The NIST AI RMF, Generative AI Profile, ISO/IEC 42001, ISO/IEC 23894, the EU AI Act and UK assurance guidance support lifecycle governance. The assurance case remains system-specific: it must show why the actual control and evidence system supports the bounded decision.

Ten worked casesDisposition follows the controlling claim and defeater

1. Narrow summarisation assistant

The top claim covers internal summaries for named document types, with no external commitment. Purpose, performance, privacy, security, resilience and human-use claims are proportionate. Representative direct tests, boundary tests and user correction records support it. The weakest inference concerns uncommon formats, bounded by exclusion. No controlling defeater remains. Approve the bounded release within the stated envelope; product owns the claim and model risk challenges limitations.

2. Retrieval assistant with stale or unentitled context

Strong model tests do not prove that answers use current, authorised sources. The rights and performance claims both depend on entitlement and freshness. The controlling evidence defeater is missing retrieval provenance at decision time. More general benchmarks do not change the decision. Collect targeted entitlement, freshness, citation and stale-source evidence. The data owner and security own the boundary; assurance challenges the inference.

3. Credit recommendation

The top claim binds population, recommendation authority and mandatory human decision. Performance, rights, explanation, human authority and appeal interact. Direct subgroup outcome tests and appeal records are strong, while field evidence of workload is thinner. No blocking defeater exists, but exposure should remain limited until human decision quality is observed. Approve limited exposure with claim-level monitoring. Credit leadership owns the decision and independent risk challenges it.

4. Action-capable refund agent

The case adds tool, authority, cumulative-effect and recovery evidence to all six families. Direct transaction tests are insufficient without independent policy decisions, idempotency, receipts and external reconciliation. A bounded pilot has passed containment drills but lacks broad operational evidence. Approve limited exposure with transaction, customer and cumulative limits. Service operations owns exposure; payments, security and model risk supply independent challenge.

5. Model update with subgroup regression

Average performance is preserved, but a critical subgroup refusal condition worsens. This claim defeater expires performance, rights and top claims. Targeted evidence must establish the mechanism and whether a narrower population or rollback restores acceptance. Additional average cases are irrelevant. Collect targeted evidence while the prior model or safe fallback remains. Product and model risk own the revalidation.

6. Good pre-release evidence, weak detection

Pre-production claims are credible, but operational resilience cannot establish timely detection of critical failures. The weakest inference is that release evidence will remain valid in use. Permit only a small exposure with explicit outcome sampling and manual review while monitors are proved. Operational risk owns invalidation design; product owns the exposure decision.

7. Open red-team counterexample

A realistic prompt-context path reaches a prohibited external action. The security and governance claims fail, and the top claim does not hold. Process records, extra benign tests and a statement that exploitation is unlikely do not answer the controlling defeater. Do not release. Redesign authority, isolation and tool boundaries, then repeat challenge. Security owns containment and independent assurance confirms closure.

8. Certified supplier, irrelevant deployed evidence

The supplier process certificate is supporting evidence, but the deployed endpoint, configuration, update policy and target use remain untested. The evidence defeater is relevance, not document quality. Collect targeted endpoint, configuration, population and change evidence or replace the supplier. Procurement owns the evidence obligation; product and assurance judge use relevance.

9. Technically strong, organisationally weak

Tests show good model behaviour, yet field observation finds overloaded reviewers, incentives for agreement and inaccessible escalation. The human and organisational claim fails. More model evidence cannot repair it. Redesign queues, authority, incentives and staffing, then rerun field tests. Operations leadership owns the organisational system; product, risk and assurance challenge it.

10. Production incident and claim invalidation

An incident shows that a context change bypassed a control. The affected security and resilience claims expire, dependent claims reopen and authority is contained. Reconcile external effects, notify and remedy affected people, investigate the inference and update thresholds. Withdraw the capability until the complete case supports a bounded return. The business principal owns withdrawal; incident, tool, security, product and assurance leaders own the reargument.

Interactive instrumentAI Assurance Case Review Board

Select a scenario or change the assurance conditions. The Board returns exactly one of five dispositions and exposes the controlling logic rather than an aggregate score, confidence percentage or document count.

Executive operating cadenceReview claims, defeaters, expiry and operating evidence

The AI Assurance Case Spine, Assurance Evidence Grammar, Assurance Validity Clock and Review Board are this article's synthesis. GSN and SACM support argument structure. NIST, ISO, the EU record and UK guidance provide governance and assurance context. SP 800-53A and OSCAL inform assessment evidence; PROV-O supports lineage. Research on learning-enabled assurance, operational evidence, causal relationships and defeaters informs the argument method.

The April 2026 interagency US model-risk guidance replaced SR 11-7 and OCC Bulletin 2011-12. It preserves risk-based development, use, validation, monitoring, governance and effective challenge, while expressly excluding generative and agentic AI from scope. Use those disciplines as a foundation where relevant, not as a claim of direct applicability.

At release review, show the precise top claim, weakest family, decisive evidence, boundary, open defeaters, exposure, recovery, owner, independent challenge and earliest expiry condition. Ask which evidence would change the decision and which contrary fact is being sought. An unconditional approval is inappropriate when the argument supports only bounded exposure.

During operation, review claim-level thresholds, negative evidence, complaints, overrides, incidents, recovery and changed dependencies. Preserve previous claims and evidence rather than overwriting them. When a threshold crosses, record the affected inference, containment, decision and revalidation route. The assurance case is useful only when it can stop or reshape operation.

The closing question is not how many artefacts exist. It is whether the enterprise can defend one bounded claim, expose its weakest inference, name what would defeat it and act when that fact appears. That is the difference between documentation and assurance.

Source recordWorks cited

1. Safety-Critical Systems Club. Goal Structuring Notation Community Standard, Version 3.
2. Object Management Group. Structured Assurance Case Metamodel 2.3.
3. NIST. Artificial Intelligence Risk Management Framework.
4. NIST. Generative Artificial Intelligence Profile.
5. NIST. SP 800-53A Rev. 5, Assessing Security and Privacy Controls.
6. NIST. Open Security Controls Assessment Language.
7. ISO. ISO/IEC 42001:2023, Artificial intelligence management system.
8. ISO. ISO/IEC 23894:2023, Artificial intelligence guidance on risk management.
9. European Union. Regulation (EU) 2024/1689.
10. UK Government. The roadmap to an effective AI assurance ecosystem.
11. UK Government. Introduction to AI assurance.
12. Federal Reserve, OCC and FDIC. Revised Guidance on Model Risk Management, SR 26-2.
13. Burton, S. et al. Reliability Assessment and Safety Arguments for Machine Learning Components in System Assurance.
14. Kläs, M. et al. Integrating Testing and Operation-related Quantitative Evidences in Assurance Cases.
15. Picardi, C. et al. A causal model of safety assurance for machine learning.
16. Rushby, J. Defeaters and Eliminative Argumentation in Assurance 2.0.
17. W3C. PROV-O: The PROV Ontology.