“Check it.”

It sounds like a small instruction. In practice, it can contain an entire discipline.

Suppose a report says a bridge reopened on Monday. You find an official page saying the bridge reopened. Have you verified the claim?

Perhaps. But first ask which bridge, which Monday, which version of the page, whether “reopened” means fully reopened or partially reopened, whether the official page is reporting a plan or an observed state, whether the page has since been corrected, and whether an independent source or current operational record agrees.

Now suppose you find the same sentence on ten websites. That may look stronger. But if all ten copied one announcement, you have ten appearances and perhaps one evidence lineage.

Verification is what turns this mess into a controlled question.

Verification is not the act of seeing information twice. It is the disciplined process of checking whether a specified claim, requirement, identity, calculation, state or record is adequately supported by appropriate evidence under an explicit method.

The answer in one paragraph

In this article, verification means a structured check that begins with something precise enough to test, identifies the evidence and criteria that would count for or against it, controls identity, time, scope, version and provenance, performs the relevant inspection, analysis, demonstration, test or reconstruction, records contradictory and missing evidence, and produces a traceable result whose wording is no stronger than the check justifies. Verification can establish that a requirement was met, a quotation is accurate, a calculation reproduces, a file is unchanged, a source actually says what is attributed to it, or a factual claim is supported within defined limits. It does not automatically establish that a system is useful for its intended purpose, that an authenticated source is truthful, or that one successful check settles every broader question.

This article sits in a public foundation sequence. What Is a Claim? asks what exactly is being asserted. What Is Evidence? asks what information bears on that assertion. What Is a Fact? asks what conclusion is justified. Verification is the bridge between those layers: the method by which evidence is tested against a claim.

The word verification is used differently across engineering, software, identity systems, auditing, journalism, research, digital preservation and everyday reasoning. This article therefore uses a cross-domain educational definition while keeping specialist meanings visible. Where official standards are cited, their definitions remain scoped to their own domains.

1. Verification begins with a target

You cannot verify “the situation”. You verify something about the situation.

The target might be:

• a factual claim;
• a requirement;
• a numerical calculation;
• a quotation;
• an identity;
• a document version;
• a file’s integrity;
• a system behaviour;
• a historical state;
• a present operating state;
• a model output;
• a reported event.

Good verification starts by making the target explicit enough that another person could understand what success and failure mean.

2. A vague target produces a vague check

“Check whether the programme worked” contains several hidden questions. Worked for whom? Which outcome? Compared with what? Over what period? Under which definition of success?

Rewrite the target:

“Verify whether the median completion time among participants with both baseline and follow-up measurements decreased by at least ten minutes during the six-week pilot compared with the defined baseline period.”

Now the verifier knows which population, measure, threshold, comparison and period matter.

The act of specifying the target is not bureaucracy. It is part of verification itself.

3. Verification and validation are related but not identical

Engineering gives us one of the clearest formal distinctions.

NASA’s Systems Engineering Handbook describes verification as establishing compliance with requirements and validation as establishing that the system meets customer expectations or intended purpose. NIST’s current glossary similarly includes verification definitions centred on objective evidence that specified requirements are fulfilled, while validation definitions focus on intended use, stakeholder needs or application.

A useful shorthand is:

Verification: Did we meet the specified requirement?
Validation: Is this the right thing for the intended use?

The shorthand is not a universal legal definition, but it captures an important design distinction.

4. A system can be verified and still fail validation

Imagine a timetable system specified to display the next lesson within two seconds. Tests show that it does so every time. The requirement is verified.

But the system may still display the wrong lesson because the underlying schedule model does not handle a school’s rotating-week pattern. The product satisfies a technical requirement yet fails the user’s actual need.

This is why verification and validation should not be collapsed into one word such as “tested”.

5. ISO uses verification and validation for claims too

ISO/IEC 17029:2019 covers bodies performing validation and verification as conformity-assessment activities. Its public abstract distinguishes validation of claims as plausible with regard to intended future use from verification of claims as truthfully stated, within the programmes and sector-specific requirements that govern the activity.

This again shows why the target and governing criteria matter. Verification is not a free-floating feeling that something looks right. It is a check performed against a defined claim under a defined scheme.

6. Verification is not the same as fact-checking

Fact-checking is one important application of verification. It usually concerns factual claims in public communication, journalism, publishing or research.

Verification is broader. You can verify a calculation without fact-checking a public statement. You can verify that a software module meets a specification. You can verify that a file is unchanged. You can verify that a quotation appears in a particular edition.

For the editorial workflow specifically, see How Editorial Fact-Checking and Source Verification Work. The present article owns the general verification grammar across domains.

7. Verification is not the same as authentication

Authentication establishes confidence in identity, source or authenticity under a particular system.

NIST’s cybersecurity glossary uses authentication for processes that establish confidence in identities or in the source and integrity of information, depending on context.

An authenticated message can still contain a false statement. Authentication tells you who or what the system accepts as the source. Verification of the message’s factual content is another job.

Authentic does not mean true.

8. Integrity verification is narrower than truth verification

NIST defines integrity verification in cybersecurity as obtaining assurance that information has not been altered in an unauthorised manner since creation, transmission or storage.

If a cryptographic hash confirms that a file is bit-for-bit unchanged, you have strong evidence about file integrity. You have not proved that the original file contained correct information.

A perfectly preserved mistake remains a mistake.

9. Provenance is not verification—but verification often depends on it

Provenance records where information came from and how it changed.

The W3C PROV family models entities, activities, agents and derivation relationships. NIST similarly defines provenance in terms of chronology of origin, ownership, location, changes and associated processes.

Provenance helps a verifier answer:

• Is this the original source or a copy?
• Was the chart generated from this dataset?
• Which version was used?
• Did two apparently independent sources share one upstream record?
• Who performed the transformation?

Provenance makes verification reconstructable. It does not perform the verification by itself.

10. Corroboration is not verification by counting

Corroboration adds compatible evidence through another route. It can strengthen verification when the new route is meaningfully independent.

Ten webpages copied from one press release are not ten independent confirmations. One official record and one independently captured observation may be more informative than twenty derivative pages.

Verification asks about evidence structure, not web-page count.

11. Reproduction is a powerful verification method

If a report states that a total is 8,432, a strong check may be to reproduce the total from the underlying rows rather than merely finding the same number in another document.

If an analysis reports a regression coefficient, a verifier may rerun the published code on the same data. If a chart shows a rate, the verifier may reconstruct numerator, denominator and transformation.

The National Academies has distinguished computational reproducibility—obtaining consistent results using the same data, methods and code—from replication using new data. Terminology differs among fields, so a verification record should state exactly what was repeated.

12. Replication goes beyond repeating the same calculation

Recomputing the same result can reveal arithmetic, coding or data-handling errors. A new study using new data tests something different: whether a finding survives another encounter with the world.

This matters because a perfectly reproducible analysis can faithfully reproduce a biased dataset or flawed research design.

Verification can therefore occur at several layers: data integrity, computation, procedure, requirement and substantive claim.

13. Inspection, analysis, demonstration and test

NASA’s systems-engineering guidance lists familiar verification methods including inspection, analysis, demonstration and test.

Method	Question	Simple example
Inspection	Is the specified feature, record or property present?	Inspect a document for a required clause.
Analysis	Does calculation or reasoning show the requirement is met?	Recalculate load capacity from approved inputs.
Demonstration	Can the required function be shown in operation?	Demonstrate that an interface completes the required workflow.
Test	Does controlled execution produce the required outcome?	Run the system under defined test cases and measure results.

The categories are especially useful in engineering, but the broader lesson travels well: the verification method should fit the claim.

14. Define the acceptance criterion before seeing the result

If possible, decide what counts as passing before looking at the outcome.

“The page loads quickly” invites post-hoc interpretation. “The page becomes interactive within two seconds under test condition C for at least 95 of 100 runs” is a defined criterion.

Predefined criteria reduce the temptation to move the goalposts after seeing inconvenient evidence.

15. Freeze the thing being verified

A moving target cannot be checked reliably without version control.

Before verification, freeze or identify the relevant artifact:

• document version;
• dataset snapshot;
• software build;
• webpage capture or retrieval time;
• model version;
• test configuration;
• claim wording;
• source passage.

Otherwise a later reviewer may inspect a different object and believe the original check has been reproduced.

16. Verify identity before verifying properties

Before asking whether a person holds a role, verify that the record concerns the correct person. Before checking a building’s height, confirm which building. Before merging two datasets, confirm that the identifiers refer to the same entities.

A verification performed on the wrong entity can be internally flawless and externally useless.

For the deeper identity layer, see When Are Two Things the Same Thing?

17. Verify time

A statement can be correct on Monday and wrong on Friday because the world changed.

Current-state verification should ask:

• When did the underlying event occur?
• When was it observed?
• When was the record created?
• When was it published?
• When did the state become effective?
• When was the source retrieved?

These clocks can differ.

18. Verify version

A policy, dataset, webpage, model or software package can have many versions.

Crossref’s versioning guidance for scholarly works provides a useful public example: significant updates, corrections and retractions should be represented explicitly rather than silently blurring versions together.

“The document says X” is incomplete when different versions say different things.

19. Verify scope

“Students improved” can be verified only after we know which students, which measure, which period and which comparison.

“The rule applies” requires a jurisdiction, population, effective date and sometimes exception conditions.

A verification that ignores scope often verifies a narrower statement than the public wording claims.

20. Verify definitions before verifying numbers

Two reports can both calculate correctly and still disagree because they define the variable differently.

One report counts “completion” as finishing all required tasks. Another counts anyone who attended the final session. One cost estimate includes land and financing; another reports construction cost only.

Before checking arithmetic, check what is being counted.

21. Verify units and denominators

“The rate is 12” is not a complete numerical claim.

Twelve percent? Twelve cases per thousand? Twelve minutes? Twelve dollars?

Percentages require denominators. Rates require exposure or population definitions. Currency claims may require year, exchange-rate basis and whether values are nominal or real.

Numerical verification is semantic before it is arithmetic.

22. Verify the baseline in every comparison

“Thirty per cent faster” is meaningless without the comparison target.

Verify the baseline, comparison period, metric and calculation. A change from 10 minutes to 7 minutes is a three-minute reduction and a 30% reduction relative to the original 10 minutes. A move from 10% to 7% is a three-percentage-point reduction and a 30% relative decrease.

Verification should preserve the type of change.

23. Verify what the source actually says

A source may be reputable and still not support the sentence attached to it.

Check the exact passage. Preserve qualifiers such as may, estimated, in the sample, approximately, according to and preliminary.

If a summary says “caused” while the source says “associated”, the citation is real but the verification fails.

24. Verify source authority for the specific question

An official source can be authoritative for the wording of its own rule. It may not be independent evidence that the rule produced a claimed social effect.

A manufacturer can be authoritative for product specifications and interested in performance claims. A witness can be authoritative about what they personally observed and unable to see the entire event.

Authority is claim-specific.

25. Verify independence before counting corroboration

When several sources agree, trace their provenance.

If every article ultimately cites one database, agreement may reflect shared dependence rather than independent confirmation.

Independence matters because shared errors can propagate through copying, syndication, common datasets and common models.

26. Verify negative claims carefully

“No record exists” is stronger than “I did not find a record.”

To verify a negative claim, define the search boundary and detection capability. Was the archive complete? Were aliases checked? Could records have been deleted? Was the correct date range searched?

For the full missingness problem, see What Does a Blank Actually Mean?

27. Contradictory evidence is part of verification

A verifier should search not only for support but also for credible contradiction.

If one official record says 14 June and another says 21 June, do not quietly select the newer-looking page. Ask whether the dates refer to announcement, completion, acceptance, publication or effective operation.

Apparent contradiction may reveal hidden definitions. Genuine contradiction should remain visible until resolved.

28. Missing evidence is a verification result

Verification does not always end with yes or no.

It may end with:

• insufficient evidence;
• identity unresolved;
• time mismatch;
• source unavailable;
• definition missing;
• conflict unresolved;
• calculation not reproducible;
• verification not possible under current access.

A mature verification system preserves these states instead of converting them into guesses.

29. Verification carries uncertainty

A measurement can pass a requirement while retaining measurement uncertainty. A historical identification can be strongly supported while not mathematically certain. A source match can be highly probable while an ambiguous namesake remains possible.

“Verified” should never be used to erase uncertainty that materially affects the conclusion.

The correct result may be “verified within the stated tolerance and test conditions”.

30. Verify calculations from inputs, not from appearance

A table can look professional and contain a wrong total.

For calculations:

• identify source inputs;
• check units;
• recompute independently;
• inspect rounding;
• check missing values;
• check denominators;
• check transformations;
• check whether the formula matches the verbal claim.

Verification should be able to move backwards from result to ingredients.

31. Statistical verification requires more than recalculation

You can reproduce a statistical output and still fail to verify the substantive conclusion.

Check design, sampling, exclusions, missing data, model assumptions, multiplicity, uncertainty and whether the reported population matches the data.

Reproducing the arithmetic verifies one layer. It does not automatically validate the inference.

32. Causal claims require causal verification

“B happened after A” can be verified from a timeline. “A caused B” requires more.

A causal verification must address plausible alternative explanations using an appropriate design: experiment, natural experiment, quasi-experiment, process evidence, longitudinal structure, mechanistic reasoning or another domain-appropriate approach.

The method must match the claim type.

33. Forecasts cannot be verified as outcomes before the future arrives

“The project will finish in December” can be verified as a statement that somebody forecast December. It cannot yet be verified as an observed completion date.

Before the target date, check source, model, assumptions and forecast issuance. After the target date, compare forecast with outcome.

Prediction status should survive the verification process.

34. Current-state claims need current evidence

Current leaders, opening hours, regulations, prices, software capabilities and operating conditions can change quickly.

A source can be perfectly authentic and historically correct while stale for the current question.

Current-state verification therefore includes a freshness check.

35. Historical verification uses historical state, not current state

If the question is what a policy required in 2019, today’s amended policy is not sufficient.

You need the version in force at the relevant time, plus evidence about effective dates and amendments.

Historical verification often requires reconstructing a past information environment rather than looking at the present website.

36. Verify quotations at three levels

A quotation can fail in at least three ways:

• Text: the words are copied inaccurately.
• Attribution: the words are assigned to the wrong speaker or author.
• Context: the quotation is accurate but presented in a way that changes its meaning.

Strong quotation verification checks all three.

37. Verify webpages as versioned records

Webpages change silently. Content may be edited, removed, redirected or updated without the reader noticing.

For material claims, record retrieval time, URL, relevant passage and, where appropriate, an archived or saved version.

A link alone is not a durable verification receipt if the page later changes.

38. Verify images and video through provenance and scene constraints

An image can be genuine and attached to the wrong event. A video can be authentic and clipped in a way that removes decisive context.

Visual verification may involve:

• source provenance;
• capture date;
• geolocation;
• weather and lighting consistency;
• landmarks;
• metadata where trustworthy;
• earlier appearances;
• frame sequence;
• editing or synthesis detection;
• comparison with independent records.

The visible pixels are only one layer of the check.

39. Verify digital files for fixity separately from meaning

The Library of Congress treats fixity information as essential for determining whether digital content has changed and performs routine integrity reviews for preservation content.

A checksum can verify that transferred bits match expected bits. It cannot verify that the file’s factual assertions are correct.

Digital verification should state which property is being checked: identity, integrity, authenticity, format validity, content truth or something else.

40. Verify datasets through lineage and constraints

A dataset verification can include:

• schema checks;
• row counts;
• identifier uniqueness;
• range checks;
• referential integrity;
• missingness patterns;
• duplicate detection;
• source-to-target reconciliation;
• transformation logs;
• sampling back to source records.

Passing these checks says the data satisfy defined constraints. It does not automatically validate that the dataset represents the world without bias.

41. Verify spreadsheets as programs

A spreadsheet is not merely a table. Formulas, hidden columns, filters, named ranges, manual overrides and copied cells form a small executable system.

Verification can include formula inspection, independent recalculation, boundary tests, hidden-sheet checks and reconciliation to source totals.

A correct-looking total is not enough.

42. Software verification is requirement-centred

NIST and NASA both use verification language around objective evidence that systems satisfy specified requirements.

For software, verification can include static analysis, code review, unit tests, integration tests, property checking and system tests depending on the requirement.

A test suite verifies only what its tests meaningfully cover. Passing tests are not proof that no defect exists outside the tested conditions.

43. Engineering verification should be designed with requirements

NASA’s systems-engineering guidance stresses that verification approaches should be considered while requirements are being developed, because a requirement that cannot be measured or demonstrated is difficult to verify later.

This principle travels beyond engineering:

If you cannot say how you would know the requirement was met, the requirement may not yet be well formed.

44. Models need both verification and validation

A computational model can be verified as correctly implementing its specified equations and still be a poor representation of the real system for the intended use.

This is a classic reason to keep verification and validation separate.

See How Models and Simulations Work for the specialist treatment.

45. AI answers should be verified at claim level

A long AI answer can contain twenty factual claims, three calculations, two forecasts and several pieces of interpretation.

A single label such as “verified” is too coarse.

A stronger public workflow is:

1. freeze the exact answer;
2. extract its factual claims;
3. restore necessary context;
4. retrieve evidence for each claim;
5. check source-to-claim alignment;
6. recompute quantitative claims;
7. preserve unresolved conflicts;
8. return claim-level statuses;
9. revise only what the evidence justifies.

This is a public reasoning pattern, not a claim about any particular proprietary eduKateAI implementation.

46. Search is not verification

Search finds candidate evidence. Verification decides what the evidence supports.

A top-ranked page may be stale. A snippet may remove a qualifier. A page may concern a namesake. Ten results may copy one source.

Retrieval is upstream of verification.

47. Reading is not verification

Reading a source carefully is necessary but not always sufficient.

If the source contains a calculation, reproduce it. If it attributes a claim, inspect the upstream source. If it reports an event, look for independent evidence. If it is a current-state claim, check freshness.

Verification is an active operation on information, not passive exposure to it.

48. “Official” is not a complete verification method

An official source can establish official status, official wording or an official announcement. It can still be outdated, mistaken, incomplete or unsuitable for an independent effects claim.

Use official sources where their authority is the property being verified. Use independent evidence where independence matters.

49. Independence strengthens some checks

Independent verification and validation exists in engineering and security precisely because an objective third party can detect assumptions or errors that the original developer may share with the system.

NIST’s glossary describes IV&V as comprehensive review, analysis and testing performed by an objective third party in the relevant system context.

Independence is not always necessary. It becomes more valuable as consequence, conflict of interest, complexity and risk increase.

50. Reviewer independence and source independence are different

An independent reviewer can still rely on non-independent sources. Independent sources can still be evaluated by the same reviewer.

Keep the two dimensions separate:

• reviewer independence — whether the checker is organisationally or cognitively separate from the original work;
• evidence independence — whether the evidence pathways share upstream dependencies.

Both can matter. They solve different problems.

51. Reproducible verification leaves a route another person can follow

A verification is stronger when a competent reviewer can reconstruct the check from the record.

That record may include:

• exact claim or requirement;
• source version;
• retrieval time;
• inputs;
• method;
• calculation;
• test conditions;
• acceptance criteria;
• results;
• contradictions;
• uncertainty;
• reviewer;
• decision.

Reproducibility does not mean every reviewer must agree on every interpretation. It means the path is inspectable enough for disagreement to be located.

52. The verification receipt

A useful verification record can be thought of as a receipt.

• Target: What exactly was checked?
• Criteria: What counted as pass, fail or unresolved?
• Evidence: Which information was used?
• Method: What was done?
• Scope: Which entity, time, population, version and conditions?
• Result: What happened?
• Limits: What remains uncertain?
• Provenance: Can the evidence and transformations be traced?
• Reviewer: Who or what performed the check?
• Recheck trigger: What future change would invalidate or reopen the result?

The exact schema can vary. The design principle is durable: verification should leave enough evidence of the verification itself.

53. Verification needs status vocabulary richer than yes/no

• verified — the stated criteria were met within scope;
• verified with limitations — criteria were met but material boundaries remain;
• partially verified — some independent subclaims passed and others remain unresolved;
• contradicted — stronger relevant evidence conflicts with the target;
• not reproduced — the reported result could not be reproduced under the stated method;
• insufficient evidence — the check cannot support a verdict;
• identity unresolved — the referent is not controlled;
• stale — the evidence is not current enough for a current-state claim;
• superseded — a later authoritative state replaces the verified historical state;
• not applicable — the criterion does not apply to this case.

These labels are a public educational vocabulary, not a universal standard.

54. Verification can fail because the wrong claim was checked

A report says “the intervention may improve recall”. The checker tests “the intervention definitely improves recall”.

The source is then judged against a claim it never made.

This is why claim extraction comes before verification.

55. Verification can fail because the wrong entity was checked

Two people have the same name. Two buildings share a nickname. Two documents have similar titles. Two software packages use the same acronym.

The evidence can be perfectly correct about the wrong object.

Entity resolution is a verification prerequisite.

56. Verification can fail because the source is stale

An old official page can verify what the official page once said. It cannot necessarily verify the current state.

Freshness is not a universal preference for newer sources. It is a match between source time and claim time.

57. Verification can fail because copies look independent

A search may produce many agreeing pages whose language traces back to one source.

This is source-lineage blindness.

Before calling agreement corroboration, inspect provenance.

58. Verification can fail through confirmation bias

If the checker searches only for sources that support the initial belief, the process becomes confirmation rather than verification.

A stronger procedure actively asks:

• What evidence would contradict this?
• What alternative explanation fits the same observations?
• What result would make me revise the conclusion?

A verification method should make failure possible.

59. Verification can fail because the criteria move

A test begins with “response time below two seconds”. The system produces 2.4 seconds. The team then decides that “about two seconds” is good enough.

That may be a legitimate requirement change, but it is not a pass under the original criterion.

Change the requirement explicitly, version it and rerun the verification.

60. The verification method itself can be wrong

A broken test harness can falsely fail good software. A miscalibrated sensor can falsely verify a threshold. A spreadsheet used to audit another spreadsheet can contain its own formula error.

Verification tools and methods therefore need their own controls, calibration, peer review or validation where consequences justify it.

61. A signature verifies some things, not everything

A digital signature can provide evidence about origin and integrity under the relevant cryptographic trust system.

It does not prove that the signed statement is factually correct.

A signature can verify authorship of an error.

62. A hash verifies sameness of bits, not correctness of content

If two files have the expected cryptographic digest under the relevant method, that can provide strong evidence that the bits match the reference.

But if the reference file contained the wrong figure, perfect fixity preserves the wrong figure perfectly.

Always name the property being verified.

63. Passing a test verifies the tested condition, not every possible condition

A bridge component may pass a load test at one defined load and environment. Software may pass all known test cases. A student may answer three examples correctly.

Do not generalise beyond the test envelope without additional justification.

Test coverage is part of verification scope.

64. Verification is time-bounded

A safety inspection can be valid today and obsolete after a modification. A source check can be valid before a webpage correction. A model verification can be invalidated by a software update.

Verification is often a statement of the form:

Under version V, conditions C, evidence E and method M, target T met criterion K at time τ.

That is much more useful than a floating label reading “verified”.

65. Reverification needs triggers

Reverification should be triggered when material inputs change.

• software update;
• policy amendment;
• new dataset;
• changed model;
• new evidence;
• corrected source;
• changed operating environment;
• new failure mode;
• expired calibration;
• new identity information;
• changed acceptance criterion.

Verification without change awareness becomes historical documentation rather than current assurance.

66. Stop rules prevent endless checking

Perfect certainty is often impossible and unnecessary.

A verification process needs a stopping rule proportional to consequence. Stop when the defined criterion is met with the required evidence quality, when remaining uncertainty cannot change the decision materially, or when a formal process reaches its required threshold.

For high-stakes decisions, the threshold rises. For reversible low-cost decisions, it may be rational to act earlier and monitor.

67. Verification and decision are separate layers

A verification result can inform a decision without dictating it.

Suppose a component is verified to meet a minimum requirement. A decision-maker may still choose a stronger component because of future risk, cost of failure or strategic margin.

Conversely, a provisional action may be justified before full verification when delay itself is dangerous.

Keep what the evidence establishes separate from what we choose to do.

68. Worked example: verify a lesson start time

Claim: “The lesson started at 3:00 pm.”

First define started. Scheduled start? Teacher arrival? First instruction? First student activity?

Evidence:

• timetable: scheduled start 3:00;
• photo timestamp: students seated at 3:04;
• access log: teacher entry recorded at 3:06;
• student account: instruction began around 3:08.

Result: the scheduled start is verified as 3:00. The exact instructional start is not verified by the available evidence. The verification succeeds for one claim and remains unresolved for another.

69. Worked example: verify an official rule

Claim: “Rule X requires form Y.”

Method:

1. Identify the governing authority.
2. Locate the authoritative rule text.
3. Verify jurisdiction.
4. Verify effective date.
5. Verify version and amendments.
6. Check exceptions.
7. Quote the relevant clause accurately.

An older official page may verify the historical rule and fail the current rule question. Authority does not remove the time requirement.

70. Worked example: verify a reported percentage

Claim: “Completion increased by 25%.”

Suppose completion rose from 40 to 50 students.

The absolute increase is 10 students. Relative to the original 40, 10 ÷ 40 = 25%. The arithmetic verifies that interpretation.

But if class size changed from 50 to 100, the completion rate fell from 80% to 50%. A statement about student counts and a statement about completion rates are different claims.

Verification must reconstruct the denominator.

71. Worked example: verify a citation-rich AI answer

An AI answer contains six factual statements and four citations.

A superficial check asks whether the links work.

A real verification asks:

• What are the six claims?
• Which citation supports each claim?
• Does any citation support only part of a sentence?
• Are the sources current?
• Do they concern the same entity?
• Are copied sources being counted as independent?
• Can the quantitative claim be recomputed?
• Does the conclusion strengthen the source wording?

An answer can be citation-rich and verification-poor.

72. Worked example: verify a photograph

Claim: “This photograph shows yesterday’s flood on Street A.”

Verification may require:

• reverse-image search for earlier appearances;
• landmark comparison;
• weather records;
• shadow or lighting consistency;
• capture metadata where trustworthy;
• source account history;
• independent images from the same event.

The image can be authentic but old. It can be recent but from another street. It can be correctly located but unrelated to the claimed cause of flooding.

73. Worked example: verify a student answer

A student solves an equation and gets x = 7.

Verification does not require a teacher to repeat the whole solution from scratch. Substitute x = 7 back into the original equation. If both sides match, the proposed solution passes a powerful check.

This is a miniature verification architecture:

• target: x = 7;
• criterion: satisfies original equation;
• method: substitution;
• evidence: equality after substitution;
• result: verified for that equation.

Teaching verification as a distinct step turns “check your work” into an actual method.

74. For students: verification is a strategy, not a reminder

“Check your work” is weak advice when the learner does not know how.

Different tasks require different checks:

• Mathematics: substitute, estimate, reverse the operation, check units.
• Science: inspect controls, units, trend, anomalies, uncertainty.
• English comprehension: match answer scope to passage evidence.
• Writing: verify that every task requirement is answered.
• Humanities: cross-check date, source, attribution and causal wording.

Verification becomes teachable once the method is named.

75. For teachers: ask for the checking method

Instead of asking only “Did you check?”, ask:

• What did you verify?
• What test did you use?
• What would have shown the answer was wrong?
• Did the check use information independent of the original step?
• What remains uncertain?

A learner who can explain the verification method has acquired a transferable reasoning skill.

76. For researchers: verify the analysis chain

A research result can be checked at multiple layers:

• data provenance;
• data cleaning;
• exclusion rules;
• code execution;
• model specification;
• numerical output;
• figure generation;
• reported table values;
• claim wording;
• generalisation.

A reproducible number is not automatically a valid scientific conclusion, but unreproducible analysis is an important failure signal.

77. For journalists: verify before amplifying

Journalistic verification often combines source confirmation, document checks, direct observation, independent corroboration, geolocation, chronology and transparent attribution.

The key discipline is to distinguish:

• what happened;
• what a source says happened;
• what has been independently verified;
• what remains allegation, forecast or interpretation.

For the broader domain, see What Is Journalism?

78. For auditors and assurance work: contradictory evidence belongs in scope

Assurance disciplines emphasise objective evidence, defined criteria and records because verification must withstand later review.

A mature process does not collect only evidence that supports management’s assertion. It also considers evidence that contradicts it.

The exact rules depend on the applicable audit or assurance standard. The general lesson is universal: verification becomes weak when contrary evidence is excluded by design.

79. For health and medicine: verification does not replace clinical judgement

A laboratory result can be verified as belonging to the right patient, measured under the relevant method and reported accurately. Whether it establishes a diagnosis or changes treatment is a further clinical inference.

Medical decision-making has domain-specific evidence, safety and professional requirements. This general article therefore stops at the verification grammar and leaves clinical ownership to the dedicated medicine branch.

80. For law: verification does not replace evidentiary rules

A document can be verified as authentic under one method and still face legal questions about admissibility, privilege, relevance or weight.

Legal systems define their own procedures and standards of proof. General verification concepts should not be used to override those rules.

81. A compact verification record

Field	Purpose
target	Exact claim, requirement, state or artifact checked
target version	Which version was frozen for verification
criterion	What counts as pass, fail or unresolved
entity	Resolved subject of the check
valid time	When the claim or state applies
scope	Population, place, jurisdiction, conditions
evidence	Records, observations, measurements or tests
provenance	Origin, lineage and transformations
method	Inspection, analysis, demonstration, test or reconstruction
uncertainty	Known limits of measurement or inference
contradictions	Material evidence pointing the other way
result	Verified, partial, contradicted, unresolved, etc.
reviewer	Who or what performed the check
verified at	Time of the verification
recheck trigger	Change that would reopen the result

This is intentionally generic. Different domains should add their own required fields rather than treating one schema as universal.

82. The rigorous verification pipeline

1. State the target. What exactly are we checking?
2. Classify it. Fact, identity, calculation, requirement, forecast, causal claim, integrity claim?
3. Resolve identity. Which entity or artifact?
4. Freeze version. Which source, build, dataset or wording?
5. Bound time and scope. When, where, for whom?
6. Define criteria. What would pass, fail or remain unresolved?
7. Choose method. Inspection, analysis, demonstration, test, reproduction or another appropriate method.
8. Gather evidence. Prefer sources whose relevance and provenance can be inspected.
9. Trace lineage. Separate independent evidence from copies.
10. Perform the check. Recompute, compare, test or reconstruct.
11. Search for contradiction. Ask what would show the claim is wrong.
12. Assess uncertainty. Measurement, missingness, ambiguity, coverage.
13. Record result. Use bounded status language.
14. Leave a receipt. Preserve enough information for review.
15. Set recheck triggers. Know when the result becomes stale.

83. The fast verification loop

Not every question needs the full pipeline. For ordinary low-stakes checks, use a compact loop:

1. What exactly is the claim?
2. Am I looking at the right thing?
3. Is the evidence current and relevant?
4. Can I reproduce or independently confirm the key point?
5. Is there credible contradictory evidence?
6. What is the strongest statement the evidence actually earns?

The fast loop preserves the same logic with less overhead.

84. Verification should scale with consequence

The effort spent on verification should be proportionate to the cost of being wrong.

A spelling check can be lightweight. A medical, legal, financial, safety or reputational claim deserves stronger safeguards. A decision that is irreversible may justify independent review, additional evidence or formal testing.

Verification is not maximal checking. It is sufficient checking for the consequence and purpose.

85. What “verified” should mean in careful writing

Use verified only when you can answer:

• verified what;
• against which criteria;
• using which evidence;
• under which method;
• for which entity;
• at which time;
• under which conditions;
• with what limitations.

If those answers are unavailable, choose narrower language: “confirmed in source A”, “reproduced from the reported data”, “consistent with available records”, “not independently verified”, or “verification pending”.

86. Verification does not manufacture certainty

A high-quality verification can end with uncertainty.

That is not failure when the world itself, the evidence base or the measurement process is uncertain.

The failure would be to hide the uncertainty and label the result certain because the workflow needs a green box.

87. Verification should preserve unknowns

If the exact date cannot be established, record a bounded interval. If two identities remain plausible, preserve the ambiguity. If a source is missing, say so. If a calculation cannot be reconstructed, do not invent the missing input.

Unknown is a legitimate verification output.

88. Verification should be able to fail gracefully

A resilient verification process does not collapse when one source disappears.

It can distinguish:

• source unavailable;
• target changed;
• check inconclusive;
• evidence conflict;
• tool failure;
• criterion not testable;
• result superseded.

These states support correction rather than forcing false pass/fail certainty.

89. Verification builds trust only when the method is visible enough

“Trust us, we checked” asks the audience to trust the checker.

A better system makes the verification path inspectable at the level appropriate to the audience: source links, methods, dates, criteria, calculations, uncertainty and correction history.

Transparency does not require publishing sensitive data. It requires enough visible structure that legitimate review is possible without exposing information that should remain protected.

90. The foundation chain

The public reasoning sequence now becomes clearer:

1. Type: What kind of thing is this?
2. Identity: Which particular thing is it?
3. Missingness: What do we not know, and why?
4. Claim: What exactly is being asserted?
5. Evidence: What bears on that assertion?
6. Verification: What disciplined check connects evidence to the target?
7. Fact status: What conclusion is justified?
8. Decision: What action follows, given consequence and uncertainty?

Each layer protects the next one from a different class of error.

91. The minimal rules

1. Verify something specific.
2. Define what would count as passing.
3. Check identity before properties.
4. Check time before current-state claims.
5. Check version before quoting revisable artifacts.
6. Check definitions before calculations.
7. Check provenance before counting sources.
8. Reproduce what can be reproduced.
9. Search for contradiction, not only support.
10. Preserve uncertainty and missing evidence.
11. Do not confuse authentication with truth.
12. Do not confuse integrity with correctness.
13. Do not confuse verification with validation.
14. Leave enough of a trail for another reviewer.
15. Know what change would require reverification.

92. The final verification checklist

1. What exact claim, requirement, state or artifact am I verifying?
2. What kind of verification is this?
3. What does pass mean?
4. What does fail mean?
5. What would make the result unresolved?
6. Have I identified the correct entity?
7. Have I frozen the correct version?
8. What time does the target concern?
9. What population, place, jurisdiction or conditions define scope?
10. What evidence is relevant?
11. How was that evidence produced?
12. What provenance does it have?
13. Which sources are genuinely independent?
14. Can the key result be recomputed, reproduced or reconstructed?
15. What evidence contradicts the target?
16. What uncertainty matters?
17. What evidence is missing?
18. Is my wording stronger than the result permits?
19. Could another reviewer follow the same path?
20. What future change would require this to be checked again?

Conclusion: verification is evidence made operational

Verification is where an abstract commitment to truth becomes a procedure.

It asks the question in a form that can fail. It identifies the thing being checked. It freezes the relevant version. It chooses evidence that actually bears on the target. It reconstructs numbers instead of admiring them. It distinguishes independent corroboration from copied repetition. It looks for contradiction. It records uncertainty. It leaves a trail.

That discipline matters because modern information systems can produce enormous quantities of plausible material at extraordinary speed. Search can retrieve it. Software can transform it. AI can explain it. None of those operations, by themselves, answers the verification question.

Verification asks something stricter:

What exactly was checked, against what evidence and criterion, under what conditions, with what result, and could another careful reviewer understand how we got there?

When that question has a good answer, “verified” stops being a decorative word. It becomes an accountable relationship between claim, evidence and method.

Sources and further reading

For systems-engineering verification and validation, see NASA’s Systems Engineering Handbook appendix, which distinguishes establishing compliance with requirements from establishing that a system meets customer expectations. For current terminology collected from standards and federal publications, see NIST CSRC glossary entries for verification, validation, authentication, integrity verification, provenance and independent verification and validation. For sector-neutral conformity-assessment principles, see the public overview of ISO/IEC 17029:2019, confirmed current by ISO in 2025. For digital fixity and integrity monitoring, see the Library of Congress Data Integrity Management guidance. For provenance, see the W3C PROV-O Recommendation. For scholarly versioning, corrections and retractions, see Crossref’s version-control guidance. For reproducibility and replication terminology, see the National Academies report Reproducibility and Replicability in Science.

Within eduKateSingapore, continue through What Is a Claim?, What Is Evidence?, What Is a Fact?, How Editorial Fact-Checking and Source Verification Work, How Research Methods and Source Evaluation Work and How Models and Simulations Work.

Wintour V1.0 edition · eduKate Publishing. Public educational synthesis. Specialist standards are presented within their own scope; examples are illustrative unless explicitly sourced. Verification terminology varies by domain, so this article uses a cross-domain public grammar without claiming a universal legal, scientific or engineering standard. No proprietary eduKateAI runtime, private control material, internal prompts or hidden implementation details are exposed.