A colleague may edit a quantity while an owner reads a report. Which source should the first card and its later details describe?
Instead of repeating date-range advice, I built a small synthetic example that fixes a selection and derives several outputs from it. It contains no company accounts or accounting report.
Date range and read reference point differ
Records for the same period can change between reads. Calculating each panel from whatever is newest can mix sources despite identical period labels. The experiment freezes the selected rows and makes summary, details and output read that copy. Outputs from one query can then be identified together.
The revision is a supplied synthetic integer, not a wall-clock time or global server sequence. Production code must define which read creates it. A content fingerprint also distinguishes different contents even under a reused revision. Adding a number alone cannot establish that an upstream database read was consistent.
Cards and details share the same rows
summary counts and totals quantities from the same rows used by export_rows and page. Company A’s draft selection contains two rows with total quantity nine. Changing a source quantity and creating a new snapshot produces eleven, while the old result remains nine. Earlier and current references can be compared explicitly.
These are teaching quantities, not revenue, tax or accounting recognition. A real financial report still needs the unit and calculation contract described in the ledger examples. Maintaining a read reference point and deciding a metric’s business meaning are separate responsibilities. Agreement on source rows comes before interpreting the figure.
Refreshing deliberately creates another result
Refreshing may create a new snapshot, but the interface must avoid mixing old cards with new details. A next-page cursor is bound to its snapshot fingerprint and rejected on another selection. The caller chooses which result to continue instead of silently combining unrelated reads.
A real screen needs understandable creation time, version or freshness indicators. The module returns revision and snapshot values, not a finished browser reporting interface. Display, refresh behaviour and stale-result explanations remain connected-service responsibilities. Returning metadata does not prove users understood its meaning.
Freezing cannot repair an inconsistent input read
An input array already assembled from incompatible database moments remains inconsistent when copied. The implemented condition is narrower: subsequent edits of the source do not mutate the captured selection. A database transaction or native snapshot facility must separately establish a consistent upstream read.
Large datasets or reports across several stores need a more detailed contract for lag and completed work. This module accepts at most one thousand synthetic rows and provides neither persistent snapshot storage nor expiry. It is not a finished reporting service for every scale. I keep the documented responsibility aligned with the code.
Make the displayed total possible to unpack
Tests edit the source and verify the old summary remains unchanged while a new summary differs. They also concatenate pages and compare them with complete output. Same conditions, same rows and same reference point are individually inspectable relationships, giving more evidence than one correct number alone.
Recorded results show before and after values without a client-report audit or physical-device test. Adoption needs store-level read guarantees, permissions, field projections and report retention and refresh rules. I consider being able to verify a number as important as presenting an attractive overview card, and share the synthetic code and checks as evidence for that decision.