The report that updates itself: five requirements

Every dashboard is born beautiful and dies in six months. The causes are known, and none of them is a missing chart — they are freshness, definition, cost, access and editing.

Dashboards have a predictable life cycle. Someone builds one carefully, the team uses it for three weeks, a definition changes without the dashboard knowing, a number starts to diverge, someone gets suspicious — and from then on nobody trusts any number on it. The dashboard stays up, and becomes decoration.

More charts do not fix this. Five requirements do, and the interesting part is that four of them have nothing to do with visualisation.

1. Freshness that is visible, not assumed

The most frequent question in front of a dashboard is "how old is this data?", and most cannot answer. The report's updated date does not count: it says when someone edited the layout, not when the numbers were computed.

What matters is the last materialisation time of each query feeding the screen. When that is visible, suspicion disappears — and when it is old, the person knows it is old instead of deciding on it.

2. The definition next to the number

The second cause of death is diverging definitions. The dashboard says 189 sales, finance says 319, and both are right: one counts acquisition, the other counts everything. Without the definition written alongside, the conversation becomes a spreadsheet duel.

A number without a definition is not data. It is an opinion that looks like data.

3. Cost proportional to use

This is the requirement nobody anticipates and everybody discovers through the invoice. A dashboard with twenty queries that refreshes itself hourly runs close to five hundred queries a day — including on weekends when nobody opened it.

The rule that fixes it is easy to say and tedious to implement: only recompute what someone has looked at since the last computation. A forgotten dashboard stops costing; a used one stays fresh.

There is a cruel detail in that implementation, worth recording because it is expensive to discover: if the cache key does not change when a query is edited, editing the report serves the old result, and the person concludes the edit did not work. The key has to carry the query's version, not just its text.

4. Link access, with rules

A report that requires a login on your platform does not circulate. The partner, the client and the agency will not create an account to see one number, and the workaround becomes a screenshot in a chat — which has no freshness, no definition and no revocation.

What works is a public link with its own password per recipient, revocable one by one, with a record of who opened it and when. Changing the password drops whoever was inside; revoking a link cuts that access without touching the others.

5. Cheap editing

The fifth requirement decides whether the report will follow the business. If changing one column means rebuilding the whole dashboard, nobody changes it — and the report freezes in the shape of the day it was born, while the business moves on.

In practice that means being able to swap one query without touching the other nineteen, and without the swap triggering a full recomputation. When editing is expensive, it does not happen; when it does not happen, the report ages.

What this has to do with AI

The link is direct: with the five requirements in place, a report stops being an artefact someone builds and becomes the result of a question. You ask, you check the query, you publish — and the thing stays alive on its own.

Without them, asking an AI to "build me a dashboard" only speeds up the production of dashboards that will die in six months. The bottleneck was never build speed.

In CrazyLeads reports are publishable artefacts: each declares how old its data is, recomputes only what has been viewed, is shareable by link with a per-recipient password, and can be edited one query at a time without republishing the rest.