Publication-Time Modeling
Separates business-valid time, system-visible time and official publication time so released reports remain reproducible after corrections arrive.
Use it when it is not enough to know what was true and what the platform knew. You must also preserve what was officially published, disclosed or used in a reporting output.
Corrected history can silently rewrite reports that were already published.
Bitemporal models separate business-valid time from system-visible time. That allows a platform to explain what was true and what it knew at a previous point in time.
But some reporting systems also need to preserve what was officially released. A January report may have been published as Standard before a February correction established that the customer was Premium from January onward.
Without a publication timeline, rebuilding the January report can silently replace the released result with corrected knowledge that was not part of the original publication.
The customer was corrected to Premium, but the official January report was already published as Standard.
The same historical case produces different answers depending on whether the query asks for business-valid truth, platform-visible knowledge or the officially published output.
The official January report had already been published with Standard and must remain reproducible.
Publication-Time Modeling prevents one timeline from pretending to answer every historical question. Truth, knowledge and publication are related, but they are not the same thing.
Truth, knowledge and publication answer three different historical questions.
Publication-Time Modeling extends bitemporal modeling with a third axis. Each timeline has a distinct meaning and must remain queryable independently.
The model does not force one timeline to answer every question. Instead, it keeps corrected business truth, platform knowledge and the officially published result available side by side.
Published outputs have their own lifecycle after data has been processed.
A fact may become valid in the business, arrive in the data platform later and be published at a third moment. These moments often diverge in regulated reporting, executive KPI delivery, customer statements and month-end processes.
Corrections can also arrive after an output has been frozen or disclosed. The corrected truth may be accepted without changing the previously published report, or a formal restatement may create a new publication version.
Model publication as an explicit temporal layer instead of hiding it in reporting logic.
Publication time is not a replacement for valid time or visible time. It adds the release lifecycle needed for audit-grade reproducibility.
Validate truth, knowledge and publication separately.
Publication-Time Modeling preserves what users and regulators actually saw.
A report rebuilt from today's corrected data can be accurate as current truth and still be historically wrong as a published artifact.
By preserving publication time, the system can explain the original release, later corrections and formal restatements without collapsing them into one rewritten history.
This is especially important in financial reporting, compliance systems, customer communications and any pipeline where released outputs must remain defensible years later.
How this pattern relates to other temporal models
Publication-Time Modeling extends bitemporal systems into a tritemporal architecture. It is most useful when historical truth, platform knowledge and official release status must all remain independently reproducible.
Publication-Time Modeling is rarely used alone. It normally sits on top of bitemporal state, correction and snapshot mechanisms.
Explore publication-time requirements in the Workbench.
Use the Historical Data Assistant to reason about valid time, visible time, publication versions, restatements and reproducible reporting outputs.
Open Historical Data Assistant →