How Assurance Cases Work | Build an Auditable Argument From Claims, Evidence and Assumptions

An assurance case is a structured, auditable argument that explains why there is sufficient reason to believe an important claim about a system.

The claim might be that a railway signalling system is acceptably safe in a defined operating environment. It might be that a software service satisfies a security property. It might be that an AI-enabled decision system meets specified performance and oversight requirements. It might be that a medical device remains dependable under defined conditions.

The key word is not document. It is argument.

A pile of test reports is not automatically an assurance case. A certification badge is not automatically an assurance case. A checklist with every box ticked is not automatically an assurance case. An assurance case makes the reasoning chain explicit:

Claim → argument → evidence → assumptions → conclusion that can be challenged.

NIST defines an assurance case as a reasoned, auditable artefact supporting the contention that a top-level claim is satisfied, with systematic argumentation, underlying evidence and explicit assumptions. That definition captures the central job: assurance is not merely having evidence. It is showing how the evidence actually supports the claim.

The direct answer

Assurance cases work by decomposing a large trust claim into smaller claims until each important part can be supported by evidence that is relevant, credible and current.

A simple case might say:

• Top-level claim: the autonomous warehouse vehicle is acceptably safe for operation in Zone A under the defined operating rules.
• Subclaim 1: the vehicle reliably detects people and obstacles within its required stopping envelope.
• Subclaim 2: braking performance is sufficient across the permitted speed, load and floor conditions.
• Subclaim 3: failures are detected and move the vehicle to a safe state.
• Subclaim 4: human operators can intervene and recover the system when required.
• Evidence: test results, hazard analysis, simulation, field trials, inspection records, software verification, human-factors evaluation and operational monitoring.
• Assumptions: the floor remains inside specified friction limits, maintenance intervals are followed, the operating zone is configured correctly, and the vehicle is not used outside its approved envelope.

The case is strong only if the argument genuinely connects these pieces. If an assumption is false, an evidence item is stale, or a subclaim does not cover an important failure path, the assurance case should make that weakness visible.

1. Assurance begins with a precise claim

Weak assurance often begins with a vague statement such as:

The system is safe.

Safe for what? Safe where? Safe under which operating conditions? Safe according to which criteria? Safe for which users? Safe for how long? Safe after which modifications?

A useful top-level claim needs a boundary.

For example:

The system is acceptably safe for the defined operational design domain when configured to release X, operated under procedure Y, and maintained according to schedule Z.

The exact wording will depend on the domain, but the principle is universal: an assurance claim must be narrow enough that evidence can actually support it.

2. Claims must be decomposed before they can be tested

Large claims are rarely supported directly by one piece of evidence.

Instead, the argument decomposes the claim.

A safety claim might be broken down by:

• hazard;
• subsystem;
• operating mode;
• lifecycle stage;
• failure mechanism;
• safety function;
• human role;
• environmental condition.

A cybersecurity assurance case might instead decompose around:

• identity and access;
• data protection;
• software integrity;
• attack resistance;
• detection;
• response;
• recovery;
• supplier dependencies.

The decomposition is not just organisational convenience. It is part of the reasoning. A poor decomposition can hide gaps. A good decomposition makes it harder for an important failure route to disappear inside a broad statement.

3. The argument explains why the evidence is relevant

Imagine a system has passed 10,000 test cases.

That sounds impressive.

But the number alone says very little.

Were the tests representative of real operation? Did they cover the dangerous boundary conditions? Were tests independent of the development data? Did they include degraded sensors? Did they include uncommon but foreseeable combinations of conditions? Were failures investigated or averaged away?

An assurance case makes the relevance step explicit:

These tests support this claim because they exercise the required behaviour across the defined operational envelope, including specified boundary and degraded conditions.

Without that bridge, evidence becomes decoration.

4. Evidence quality matters as much as evidence quantity

Assurance is easily confused with accumulation.

More reports. More tests. More pages. More dashboards.

But an argument can be buried under evidence and still be weak.

Useful evidence should be judged on dimensions such as:

• relevance: does it actually bear on the claim?
• credibility: was it produced by a method that deserves trust?
• independence: was the evaluator sufficiently separate from the work being assessed?
• coverage: what part of the claim does it support, and what remains uncovered?
• freshness: does it describe the current system version and operating environment?
• traceability: can reviewers reconstruct how the evidence was produced?
• reproducibility or repeatability: where appropriate, can the result be recreated?
• uncertainty: what limitations or error bounds remain?

One high-quality piece of evidence can matter more than a hundred irrelevant test logs.

5. Assumptions are structural components, not footnotes

Every assurance case contains assumptions.

The dangerous cases are the ones that pretend they do not.

A braking claim may assume a minimum tyre condition. A security claim may assume privileged credentials are managed correctly. An AI system may assume input data remain within a defined domain. A human-oversight claim may assume an operator is present, trained and able to intervene within a required time.

If those assumptions are hidden, the assurance case can look universal when it is actually conditional.

Good assurance therefore asks:

• What must be true for this argument to hold?
• Who owns that assumption?
• How is it monitored?
• What happens when it stops being true?

6. Context tells reviewers where the argument applies

Assurance is contextual.

A system can be safe in one operating environment and unsafe in another. A model can be reliable for one population and unreliable for another. A security control can be effective against one threat model and weak against another.

Context therefore belongs inside the case:

• system boundaries;
• version and configuration;
• operating environment;
• users and roles;
• interfaces;
• external dependencies;
• threat or hazard model;
• applicable standards and criteria.

Without context, the claim floats free from the world that makes it true or false.

7. A case should expose defeaters

A strong argument does not merely collect reasons to believe itself.

It searches for reasons it might be wrong.

These can be thought of as defeaters: conditions, counterexamples or unresolved questions that would weaken the claim.

For example:

• What if the sensor degrades in rain?
• What if the operator receives two conflicting alerts?
• What if the supplier changes a component?
• What if the training data underrepresent a rare but important condition?
• What if a security control fails open during recovery?

An assurance case that cannot represent doubt can become a persuasion document rather than an assurance instrument.

8. Testing and assurance are not the same job

Testing asks whether a system behaves as expected under selected conditions.

Assurance asks whether there is enough justified confidence in the relevant system property, considering the full argument.

Testing is therefore evidence inside assurance.

Other evidence can include:

• formal analysis;
• hazard analysis;
• architecture review;
• inspection;
• simulation;
• operational history;
• process evidence;
• independent assessment;
• human-factors evaluation;
• supplier evidence;
• monitoring data.

The relevant mix depends on the property being assured.

9. Compliance is not identical to assurance

Compliance asks whether specified requirements have been met.

That can contribute strongly to assurance. It is not always sufficient.

A system can comply with every applicable checklist item and still face a failure mode the checklist did not anticipate. Conversely, an assurance case can incorporate standards as evidence while making additional arguments about hazards, operating context and residual risk.

The useful question is not “compliance or assurance?” It is “what does compliance establish, and what important claims still require argument?”

10. Certification is a decision; the assurance case supports the decision

A certification authority may decide that a system satisfies a defined standard or approval condition.

An assurance case can organise the reasoning and evidence used to support that decision.

They are therefore related but not interchangeable.

The assurance case is the inspectable reasoning artefact. Certification is an authoritative outcome produced by a governance process.

11. Assurance cases are living objects

A system changes.

Software is patched. Models are retrained. Sensors are replaced. Procedures change. Users change. Suppliers change. Threats change. Operating environments change.

If the assurance case remains frozen, confidence can become detached from the current system.

Good lifecycle assurance therefore links change to argument impact:

1. What changed?
2. Which claims depend on the changed component or assumption?
3. Which evidence is now stale?
4. Which tests must be repeated?
5. Does the top-level claim still hold?

This makes configuration management part of assurance.

12. Version mismatch can silently destroy assurance

Imagine a performance report supports Model Version 7.

The deployed system is now Version 9.

If the case continues citing the old report without demonstrating that the relevant properties remain unchanged, the evidence may no longer support the claim.

This seems obvious when stated directly. In large systems with thousands of artefacts, it is surprisingly easy to lose.

Traceability is therefore not clerical housekeeping. It is part of the logic of confidence.

13. Assurance for AI requires special care

AI systems can make assurance harder because important properties may depend on data, model behaviour, distribution shift, human interaction and post-deployment monitoring.

An AI assurance case might need to address:

• the intended use and prohibited uses;
• training and evaluation data provenance;
• performance across relevant groups and conditions;
• uncertainty and abstention behaviour;
• robustness to foreseeable input variation;
• human oversight and intervention authority;
• monitoring for drift;
• security and misuse;
• change control when the model or data pipeline is updated.

NIST-hosted guidance discussing argument-based assurance cases for AI describes the same core structure: claims, arguments and evidence used to give confidence that a system possesses the qualities that need to be assured.

The important boundary is that an assurance case does not make AI trustworthy by declaration. It forces the trust claim to become inspectable.

14. Assurance should include the human system

Many failures occur at the interface between technology and people.

If a safety argument assumes an operator will intervene, the case needs evidence that the operator:

• receives a detectable signal;
• understands what it means;
• has enough time to act;
• has authority to act;
• has practised the intervention;
• is not overloaded by competing tasks.

“Human in the loop” is not evidence. It is a system claim that needs its own argument.

15. Supplier evidence creates another boundary problem

Complex systems often depend on third-party components.

A supplier may provide a certificate, test report or assurance statement. The integrator still needs to ask whether that evidence supports the claim being made about the complete system.

A component can be reliable in isolation but unsafe in a new interface. A library can be secure under one configuration but vulnerable under another. A sensor can meet its specification while the system’s decision logic misuses its output.

System assurance cannot be outsourced merely by collecting supplier paperwork.

16. Structured notation helps, but notation is not reasoning

Assurance cases are often represented graphically. Goal Structuring Notation and Claims-Arguments-Evidence approaches can make reasoning easier to inspect. The Object Management Group’s Structured Assurance Case Metamodel supports machine-readable representation and exchange of assurance-case structures.

These tools are useful.

They can also create a trap.

A beautifully drawn argument tree can still contain bad reasoning. Boxes and arrows do not validate the claims inside them.

Notation should make reasoning visible. It should never substitute for reasoning.

17. The strongest cases make uncertainty visible

Assurance is often communicated with binary language: pass or fail, safe or unsafe, compliant or non-compliant.

Real evidence can be less tidy.

A good case can represent:

• measurement uncertainty;
• limited test coverage;
• unresolved assumptions;
• model error;
• residual hazards;
• operational unknowns;
• areas where independent evidence is weak.

The purpose is not to make the case look uncertain everywhere. It is to make the boundary of justified confidence honest.

18. Common assurance-case failure modes

• Argument by volume: many pages of evidence with no clear reasoning chain.
• Circular reasoning: the claim is true because the system passed a test designed from the same unchallenged assumption.
• Evidence drift: evidence belongs to an older version or configuration.
• Hidden assumptions: critical environmental or human conditions are left unstated.
• Decorative decomposition: claims are divided into neat boxes but important failure paths are missing.
• Compliance substitution: satisfying a checklist is treated as proof of every relevant property.
• Selective evidence: confirming results are included while inconvenient results disappear.
• Independence theatre: a nominally independent reviewer is structurally unable to challenge the programme.
• Operational blindness: pre-deployment evidence is treated as permanent even when the real operating world changes.

19. Counterexample: not every system needs a giant assurance case

Assurance cases have costs.

Building and maintaining a detailed argument requires engineering effort, documentation discipline, evidence management and review.

A disposable internal script with trivial consequences does not need the same assurance machinery as a safety-critical control system.

The depth of assurance should scale with:

• consequence of failure;
• complexity;
• novelty;
• uncertainty;
• regulatory requirements;
• difficulty of detecting failure;
• difficulty of reversing harm.

The principle is proportionality, not bureaucracy for its own sake.

20. A practical assurance-case workflow

1. Define the property that needs assurance.
2. State the top-level claim precisely.
3. Define the system boundary, operating context and version.
4. Identify hazards, threats, failure modes or quality criteria relevant to the claim.
5. Choose a defensible decomposition strategy.
6. Write subclaims that are specific enough to support.
7. Identify the evidence needed for each subclaim.
8. Assess evidence relevance, quality, independence and freshness.
9. Record assumptions explicitly.
10. Search for defeaters and counterexamples.
11. Resolve, mitigate or openly retain residual uncertainty.
12. Review the argument independently where consequence warrants it.
13. Baseline the case against the deployed configuration.
14. Link future system changes to case impact analysis.
15. Use operational evidence to update confidence after deployment.

21. Questions an assurance reviewer should ask

• What exactly is the top-level claim?
• Which conditions limit that claim?
• Why was this decomposition chosen?
• Which failure modes are not represented?
• How does each evidence item support its claim?
• Which evidence is weakest?
• What assumptions would invalidate the argument?
• What contrary evidence exists?
• What changed since the evidence was produced?
• Which claims depend on human action?
• Which claims depend on suppliers?
• How will the case be maintained after deployment?
• What would make the organisation withdraw or narrow the assurance claim?

22. Assurance is a governance mechanism

An assurance case does more than organise engineering evidence.

It creates an accountability surface.

Someone has to own the claim. Someone has to provide evidence. Someone has to accept assumptions. Someone has to decide whether residual uncertainty is tolerable. Someone has to update the case when the system changes.

This makes assurance part of governance: it connects technical facts to decision rights.

23. Assurance cases are useful precisely because evidence can disagree

Real systems often produce mixed evidence.

Laboratory tests may be strong while field data remain thin. Simulation may show excellent nominal performance while one rare edge case remains poorly understood. Formal analysis may establish one property while human interaction introduces another uncertainty.

An assurance case gives the organisation somewhere to put that disagreement.

Instead of forcing every signal into one score, it can show which parts of the argument are strong, conditional or unresolved.

24. Where this fits in the eduKateSG knowledge map

Assurance cases sit at the intersection of evidence, verification, system safety, governance and change control. They are not another name for testing.

Useful neighbouring routes include How Verification Works, How Engineering Failure Works, How Human Oversight Works, and How Technology Is Governed.

This page owns a distinct reader job: how to turn a high-level trust claim into an explicit, reviewable chain of claims, argument, evidence and assumptions.

25. Authoritative sources and further reading

• NIST CSRC — Assurance Case, defining an assurance case as a reasoned, auditable artefact with systematic argumentation, evidence and explicit assumptions.
• NIST — Measurement, Metrics, and Assurance, describing NIST work on structured software assurance and assurance-case models.
• NIST — Assurance Case Tools, updated May 1, 2026, with references to Claims-Arguments-Evidence and Goal Structuring Notation tooling.
• Object Management Group — Structured Assurance Case Metamodel, supporting structured interchange of assurance arguments and evidence.

26. The quiet conclusion

Trust is easiest to claim when nobody asks how it was earned.

An assurance case makes that shortcut harder.

It asks you to state exactly what you believe about the system.

Then it asks why.

Then it asks what evidence supports the why.

Then it asks what assumptions the evidence depends on.

And finally it asks the question that keeps assurance honest:

What would have to be true for this confidence to stop being justified?