A18 Case Study banner
A dashboard refreshed this morning can still contain observations from an earlier reporting period. Similarly, a file captured a few minutes ago may be an unchanged copy of yesterday’s publication, while a recently processed dataset may be waiting for validation before it can be released. Each can carry a recent timestamp, although that timestamp describes a different event. For a professional trying to decide whether the data can support a decision, the distinction matters more than the apparent recency of the screen.
A18 Analytics is addressing this problem through the governance model behind Ask Bhalo. Using Ontario Electricity Demand as the working example, this case study examines how source freshness, capture time, processing time, versioning and publication state contribute to an assessment of trust. It reflects the product’s pre-launch implementation; the timeline below is illustrative and explains the distinctions without presenting a recorded customer incident.
The challenge: One timestamp carries too many meanings
“Last updated” is useful only when the event behind it is clear. On a source website, it might refer to a report’s publication date. Inside a data platform, it could identify the latest ingestion run, transformation or release. On a dashboard, it might simply indicate that the visualization refreshed successfully. These events can occur close together, making them appear interchangeable during normal operation, but their differences become consequential when a publisher is late or a quality check prevents publication.
Consider an analyst reviewing electricity demand before preparing a morning briefing. A recent refresh might suggest that the latest expected observations are available. However, if the publisher has not issued a new file, the refresh may only have retrieved the same information again. Alternatively, a new file may have arrived while the consumer product continues serving an earlier validated version because the new candidate contains an unresolved quality issue. In either situation, a single recent timestamp gives an incomplete account of the evidence available to the analyst.
The product requirement therefore extends beyond displaying a time. Ask Bhalo needs to explain which reporting period is represented, whether the expected source publication has arrived, what the platform has done with it and which version has reached the user. These details allow recency to be interpreted in relation to the product’s purpose and the publisher’s schedule.
The case: A new capture without newer observations
In the illustrative scenario below, an hourly source report is issued in the morning and contains observations through the previous market day. Ask Bhalo captures and processes that report before publishing the validated product. A second capture occurs later, but the source file has not changed. Although the platform has performed a more recent retrieval, the observation coverage and source content remain the same.
| Event or property | Illustrative record | What it establishes |
|---|---|---|
| Observation coverage | Through the previous market day | The period represented by the data |
| Source publication | 07:00 | When the publisher issued this version, where that time is available |
| Initial capture | 07:10 | When the platform obtained the artifact |
| Processing completion | 07:18 | When the transformation finished |
| Validated publication | 07:25 | When the prepared product version became available |
| Repeat capture | 09:00; unchanged content hash | A later retrieval of the same source content |
All times belong to the same illustrative morning and time zone; they are not an IESO publication schedule or an Ask Bhalo performance claim. Their purpose is to show why replacing a product’s freshness description with “Updated at 09:00” would conceal useful information. The later retrieval tells an operator that the source was checked again, but it does not establish that new observations were published or added to the product.
The opposite situation also deserves attention. A publisher may revise an earlier observation without extending the latest reporting period. In that case, coverage remains unchanged even though the source content differs. A freshness assessment based only on the newest observation would miss the revision, while an assessment based only on the newest capture would not explain what changed. Both coverage and source version are needed to interpret the update properly.
The approach: Evaluate freshness against an explicit expectation
Ask Bhalo assesses freshness in relation to the publisher’s cadence and the current product contract. The Ontario Electricity Demand implementation uses hourly actual observations with a daily publication rhythm and a 36-hour product freshness target. That target belongs to the product’s operating expectations; it does not mean a source must publish a new record every time a consumer refreshes a page. Annual OEB reporting, by comparison, requires an expectation aligned with its annual cycle.
This distinction also changes how completeness is assessed. An open market day may contain only the observations reasonably expected at that point, so its partial state need not indicate a failure. Once a period has closed and its observations are due, an absent value requires different treatment. Ask Bhalo records expected partial periods separately from genuine gaps, preserving the reporting context that would otherwise be lost in a generic missing-data percentage.
The demand implementation provides a concrete example through the absent hour-ending 01 observation on 1 May 2025 in the IESO demand file. That observation is retained as source-missing rather than replaced with an imputed value. A later platform refresh cannot remove the gap simply by making the capture time more recent. The quality record remains relevant because it describes the underlying evidence, while the capture record describes the platform’s activity.
Where a publisher’s precise publication time is unavailable, that uncertainty must also remain visible. A platform capture time establishes when the artifact was obtained, but it should not be presented as proof of when the publisher released it. This is part of the broader principle behind the product: metadata should communicate what is known about the data without making a stronger claim than the evidence supports.
The controls: Preserve versions and explain where a delay occurred
Ask Bhalo retains raw artifacts immutably and identifies their content through hashes. This allows a repeated retrieval to be distinguished from a changed source version, supporting the interpretation of both unchanged files and historical revisions. Pipeline versions then identify the transformation applied, while product versions describe the consumer contract. Together, these records help explain whether a difference arose in the source, in its preparation or in the scope of the offering.
Quality origin provides another part of the explanation. A publication may be delayed at the source, or the source may be available while Ask Bhalo’s processing is behind. An issue can also involve both, or remain unresolved pending investigation. Recording these possibilities separately supports a more useful response because the action required depends on where the delay occurred. The platform cannot resolve a missing publisher observation in the same way it can address its own processing backlog.
Publication state adds a further distinction. A file may have been captured and transformed without being approved for curated release, since critical quality failures can block publication. Consequently, processing success alone does not establish that consumers are receiving the newly processed data. Product-level lineage connects source events and quality outcomes to the offerings they affect, allowing an operator to investigate the status of the consumer product rather than relying solely on a successful pipeline run.
Operational health, implemented coverage and maturity are also recorded separately. A Beta product can be healthy against its current published contract while planned assets remain in development. Equally, a product’s visibility in the catalogue does not establish that its data, API or downloads are available. Keeping these states distinct helps prevent “current,” “healthy” and “available” from becoming interchangeable descriptions of different conditions.
The result: A more useful basis for judging the data
The operational contribution of this design is a more specific account of the product’s condition. For Ontario Electricity Demand, freshness expectations sit alongside publication-aware completeness, retained quality outcomes and source versioning. These controls give users and operators a basis for distinguishing an expected partial period from a missing observation, an unchanged retrieval from a source revision, and a processing event from a consumer release. The value lies in explaining the state of the data well enough to support an informed decision about its use.
Freshness nevertheless remains one part of trustworthiness. A current dataset can still use a definition that does not fit the analyst’s question, just as a correctly processed measure can be unsuitable for comparison with another reporting population. Ask Bhalo therefore connects freshness with business definitions, grain, lineage and quality, allowing the timing of an observation to be considered alongside what it actually represents.
At the pre-launch stage covered here, these are product and operational capabilities rather than measured customer outcomes. Their effect on review time, adoption and analytical work will need to be established through use. The immediate objective is to make the evidence behind the status inspectable, so a user can understand whether a limitation originates in the reporting cycle, the source content or the platform’s preparation.
For teams reviewing their own dashboards and data services, the practical starting point is to examine what each timestamp represents and which decision it helps a user make. Source publication, observation coverage, capture, processing and release all contribute information, but their usefulness depends on retaining their separate meanings. How does your team define data freshness, and can a user tell which of those events your “last updated” label describes?