Every Export Is a Fork
The moment a report becomes a file, it stops being a view of your data and becomes a copy of it. It will not update, it cannot be corrected, and because nothing here stores a metric series there is no way to work out afterwards what it should have said.
Reporting systems are usually judged on what they can show you. The more consequential property is what happens to a number after it leaves, and almost nobody asks about that during an evaluation.
The position, stated first
Exports are recorded here — who ran what, when, in which format — and that record is genuinely useful. The file itself is a fork the moment it is created: it does not update, nothing can recall it, and since every figure is computed live with no stored history, you cannot later reconstruct what it should have said. Date every export you circulate and keep the ones that matter.
What a fork means here
Three things, and they compound.
It does not update
A backdated correction, a reversal, a late invoice — none of them reach a file that was produced last Tuesday. The system is now right and the circulated copy is not.
It cannot be recalled
There is no revocation, no expiry, and no way to mark a circulated file superseded. Once it is in an inbox it stays there.
It has no history to be checked against
Every figure is computed live and nothing stores a daily series, so re-running the report today produces today's answer and not the one in the file.
The export itself is recorded
Who ran it, when, and in which format. This part is built and is what makes the rest manageable.
The system knows that you exported something. It does not know what the something said, and it cannot work it out afterwards.
The argument this produces, every quarter
Somebody quotes a figure from a pack. Somebody else opens the report and gets a different number. Both are looking at correct outputs of a correct system.
The difference is time: the pack was computed against the data as it stood on the day, and the data has since changed — an invoice was corrected, a credit note was applied, a movement was backdated. Nothing was wrong and nobody made a mistake.
What makes this an argument rather than an explanation is that it is unresolvable. There is no stored series to point at, so neither party can demonstrate what the number was. It ends when somebody more senior decides which figure to use.
The same report, two dates
Illustrative. The only artefact that proves the first figure existed is the exported file, which is why filing it is the whole of your historical reporting.
Three habits that cost nothing
-
Put the run date in the document, not the filename
Filenames get changed and stripped. A figure quoted without the date it was produced is a figure that will be contradicted eventually, and the contradiction will look like an error.
-
File every pack you circulate, in one place
It is the only record of what you believed. A folder and a naming convention is the entire implementation and it takes an afternoon to set up once.
-
Re-run before you argue
When two figures disagree, run the report again and note today's answer as a third number. If it matches neither, the data has moved twice and the disagreement is about time rather than about arithmetic.
Two, and the first makes the second possible
The record of exports exists. What is missing is any way to reconstruct what one contained, and that is a storage problem rather than a reporting one.
Keep the artefact, not just the record
Retain the generated file against its run record, with a retention period you set, so "what did the April pack say" is a lookup rather than a search of somebody's inbox. It also gives the run trail something to point at, which is what makes an audit trail useful rather than merely present.
A stored metric series to compare against
A nightly value per named metric, with a rebuild path. This is what turns "why does March disagree" from an argument into a difference of two stored numbers — and the table it would write to already exists in the schema with nothing writing to it.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product.
Talk to us about reporting historyWhat AWRA OpsHub does today
- Exports in several formats from both standard and custom reports.
- A record of report runs and exports — who, what, when and in which format.
- A per-field visibility model that governs what a report definition can contain.
- A read API, which is the repeatable alternative to a manual export.
- Live computation, so a report run today always agrees with the data today.
What it does not do
- Retention of the generated artefact against its run record.
- Any stored metric series, so no as-at reconstruction of a past figure.
- Any expiry, revocation or supersession of a circulated file.
- Any watermark or run-date stamped into the document body automatically.
- Any notification to prior recipients when the underlying data changes materially.
Not ours, by choice
- None of this is unusual — almost every reporting tool forks at the export. It is worth stating because the record of the export being present makes people assume the content is too.
- Live computation is the right default and is the reason a re-run disagrees with an old file. That is a feature behaving correctly, not a defect.
- Nothing here is American or Canadian. North America is here because circulated management packs are an entrenched routine in those markets, which is exactly the practice this gap bites.
Four questions about exported numbers
Is the exported file retained?
A good answer sounds like
Yes, with the run.
What it actually means
Ours records the run and not the file. The distinction is invisible until somebody asks what a pack said.
Can I reproduce last quarter's figure exactly?
A good answer sounds like
Yes, from a stored series.
What it actually means
If the answer is "re-run it for that period", that is today's answer for an old period, which is a different number.
Does the run date appear in the document?
A good answer sounds like
Yes, in the body.
What it actually means
A date in a filename does not survive being forwarded, and forwarding is what happens to packs.
Is there any way to mark a circulated report superseded?
A good answer sounds like
Rarely yes.
What it actually means
Almost nothing offers this. Knowing it means treating circulation as final rather than provisional.
Date it, file it, re-run before you argue
Three habits, no software, and between them they settle the quarterly disagreement that no reporting system on the market prevents.
Talk about reporting practiceFrequently asked questions
Does the run record tell me what the report contained?
It tells you the report, the person, the time and the format. The content is not retained, so the file in somebody's inbox is the only copy of what it said.
Is the API better than exporting?
For anything recurring, yes — it is authenticated, permissioned and repeatable, and it produces a fresh answer each time rather than a copy that ages. For a pack circulated to people, an export is still what you want; just date it.
Why does re-running give a different answer?
Because figures are computed live against current data, so any correction, reversal or late entry posted since the first run is now included. That is the system working correctly, and it is the reason a stored series would be worth having.
