Module 10 Summary
The idea this module was built around
Re-running a query is not verification - it reproduces the same mistake. Real verification means checks that could actually fail: an independent source, a parts-versus-whole test, a magnitude estimate.
What you can now do
- Design checks capable of failing, rather than checks that restate the query
- Reconcile a figure against a table populated by a different process
- Write an evidence note a reader can verify without asking you anything
The strongest evidence in this dataset
Completed revenue is ₹26,85,905. The payments table, populated separately and holding 1,185 rows against 988 orders, totals the same figure to the rupee - a difference of ₹0.00. Two independent processes agreeing exactly is worth more than any amount of re-reading the query.
Parts also close: 988 completed + 12 pending = 1,000 orders; ₹26,85,905 + ₹15,558 = ₹27,01,463 booked. And magnitude holds: 988 × ₹2,718.53 = ₹26,85,907.64, within ₹3 of the total once rounding is allowed for.
The check that fails, and why that is the valuable one
Line-item value does not reconcile to order_total for 999 of 1,000 orders. A verification pass that never fails is not testing anything. This one found a real limit on what the data can support, and that limit belongs in the note.
Before you move on
Take the last number you sent someone and write its evidence note: the figure, its population, the checks that passed, the check that failed, the limitation. If you cannot name a check that could have failed, you have not verified it yet.