A delivery assertion is not evidence merely because it appears in a status report. Assurance must test whether the underlying evidence is relevant, complete, current, traceable and strong enough to support the client decision.
Key judgement
Absence of evidence is not proof of failure, but it prevents defensible confidence. Where material claims cannot be evidenced, the opinion must say so plainly.
Why conventional evidence packs fail
Delivery teams can produce large volumes of documents while leaving the central claim unproven. A plan may show dates without demonstrating achievable dependencies. A test summary may show passes without defining coverage. A risk log may record actions without showing that exposure has reduced.
The standard therefore assesses evidence by its decision value, not by document count. The question is not whether an artefact exists. The question is whether a competent reviewer can trace a material claim to reliable evidence and reproduce the reasoning.
Eight sufficiency dimensions
| Dimension | Assurance test |
|---|---|
| Relevant | Does the evidence directly address the claim and the decision being supported? |
| Complete | Does it cover the material scope, exceptions, dependencies and populations? |
| Current | Was it produced recently enough to represent the present delivery position? |
| Traceable | Can the conclusion be traced to controlled source records, owners and dates? |
| Consistent | Does it agree with related plans, logs, technical records and governance decisions? |
| Corroborated | Is the claim supported by more than the statement of the party responsible for it? |
| Owned | Is an accountable person responsible for accuracy, action and maintenance? |
| Reproducible | Could another competent reviewer reach the same conclusion from the evidence set? |
Evidence hierarchy
1. Source system or primary artefact
2. Controlled report traceable to source
3. Approved governance record
4. Interview or management statement
5. Unsupported assertion
Higher position in the hierarchy does not automatically mean sufficient. Source data can be incomplete, a governance minute can record an unsupported judgement and a controlled report can exclude material exceptions. The hierarchy indicates evidential strength, while the sufficiency dimensions determine fitness for the decision.
The four evidence tests
1. Provenance
Identify who produced the evidence, when it was produced, which source it came from and whether it has changed. Screenshots and extracts must retain enough context to be interpreted correctly.
2. Completeness
Test the whole material population or a defensible sample. Confirm what is absent. Aggregated totals must not conceal failed business processes, excluded interfaces, unresolved defects or untested operating conditions.
3. Consistency
Compare the claim across connected evidence. A green milestone that conflicts with an overdue dependency, a declining test pass rate and unresolved design decisions cannot be accepted without explanation.
4. Decision relevance
Evidence must answer the decision maker’s question. Activity records may prove that work occurred, but not that an outcome is ready, a risk has reduced or a supplier obligation has been met.
Evidence expectations by domain
| Domain | Examples of stronger evidence | Common limitation |
|---|---|---|
| Plan and milestones | Logic-linked schedule, dependency owners, critical path evidence, actual progress and forecast basis. | Dates reported without entry criteria or dependency confidence. |
| Quality and testing | Traceable coverage, execution records, defect analysis, environment and data limitations, acceptance evidence. | Pass percentages without risk coverage or exception detail. |
| Architecture | Decision records, requirement traceability, testable constraints, capacity and resilience evidence. | Design approval treated as proof of implemented behaviour. |
| Migration and cutover | Reconciliation rules, rehearsal evidence, exception disposition, timed runbook and rollback triggers. | Row counts or completed rehearsals presented without outcome evidence. |
| Operations | Service model, monitoring, support capability, security actions, continuity tests and operational acceptance. | Handover meetings treated as operational readiness. |
| Commercial and supplier | Deliverable acceptance, obligation traceability, change impact and dependency ownership. | Narrative supplier status accepted without client-side corroboration. |
Sufficiency outcomes
| Outcome | Meaning | Governance consequence |
|---|---|---|
| Sufficient | The material claim is supported to the level needed for the decision. | The claim may inform the opinion, subject to residual uncertainty. |
| Sufficient with limitation | Evidence supports part of the claim, with a defined and bounded limitation. | The limitation and decision condition must be explicit. |
| Insufficient | Material gaps prevent a defensible conclusion. | Do not infer confidence. Require evidence or defer the decision. |
| Contradictory | Material evidence conflicts and the conflict is unresolved. | Escalate the inconsistency and test the underlying control failure. |
Evidence request rule
Ask for the minimum evidence set that can prove or disprove the material claim. Do not reward volume, and do not allow the delivery party to substitute presentation quality for traceability.
How this standard supports client governance
This standard gives the client a repeatable basis for challenging delivery claims without taking ownership away from the supplier. It enables proportionate scrutiny, records the reasoning behind material decisions and makes residual uncertainty visible to the accountable decision maker.
Use with
Independence safeguard
No practitioner may independently assure delivery that they directly own. Where advisory support and assurance are both required, roles, reporting lines and review responsibility must be separated and recorded.