Temporal reasoning in data analytics often involves facts that come from different places. A sensor reports a reading, a rule flags a threshold crossing, and a model forecasts a risk. I wrote a white paper called “Event, Condition, Episode” to give those facts a small, shared vocabulary, and I kept it implementation-agnostic, so it assumes no framework, decorator syntax, or storage schema. Keeping observed facts apart from derived ones matters because a system that blurs them makes two predictable mistakes. It rebuilds boundaries the source already supplied, and it governs low-level plumbing as if someone had authored it.
This post covers the data underneath, meaning how a system records what happened, when, and where each fact came from. Temporal reasoning in data analytics is working out what happened, when, and over what span of time, using the facts a system has recorded.
Three Categories for Temporal Reasoning in Data Analytics
The model answers questions that recur in any system that reasons about intervals rather than only point-in-time facts. What is the smallest set of categories that can say something happened, a rule classified it, and a bounded period existed while that rule held, without collapsing any two into one? How does a system avoid an unbounded chain of derived facts triggering more derived facts? Where is the line between a generic primitive and a business-specific result?
My answer to the first question is three categories. An Event is a punctual occurrence, something that happened at a specific instant. An Event records that something happened. Interpreting it is the Condition’s job. A Condition is a rule that classifies a stream of Events. It supplies the “why” behind an interval, and someone chose its content, such as a threshold or a pattern, using domain judgment. An Episode is a bounded span of time, bounded by two Events, that satisfies a Condition. The bare Interval is the “when.” An Episode is the “when” fused with the “why,” and that fusion is what gives it an identity of its own.
Where a Fact Came From in Temporal Reasoning in Data Analytics
Events carry two labels. Provenance records where a fact came from. A System-Observed Event is emitted by something like a sensor or an API. A Synthetic Event is computed by the model’s own reasoning. It may be spawned by a Condition crossing a threshold, computed from an aggregate or a correlation, or inferred by a model or scorer. Forecasts and other predictive outputs also fit here.
Generation counts how many derivation hops separate an Event from an observation. An observed Event is generation 0, and a derived Event always sits at least one generation above whatever it came from.
“How ‘derived’ something is says nothing about how meaningful it is.”
A common reaction here is to treat derivation as a proxy for meaning. If a fact was derived, it must be the business-meaningful one, and if it was observed, it must be raw. Neither label says anything about business meaning. A source system can emit a business-meaningful fact directly, and a derived Event can still be low-level plumbing.
A Worked Example, From Raw Reading to Detected Excursion
Take a temperature example. A sensor reports a reading of 94 degrees, a System-Observed Event at generation 0. A Condition evaluates the stream of readings and spawns two Events at generation 1, one marking the entry and a later one marking the exit. Those two Events bound an Episode, which lasts 44 minutes in this example. A further evaluation checks whether the duration exceeds 15 minutes and produces an excursion.detected Event at generation 2. The chain stops there because nothing in the example consumes that Event.
A Diagnostic for Common Modeling Mistakes
I put derivation source on one side of a four-cell matrix and business meaning on the other. A team that can’t fill all four cells for its own system has likely conflated the two. The matrix then exposes two common mistakes. A system may rebuild a boundary from timestamps when the source already supplied a discrete fact such as batch.started. Or it may over-govern low-level plumbing such as a value_changed event, adding review workflow it doesn’t need.
What the White Paper Adds
The paper goes further. It covers how Episodes relate to each other without smuggling in a parent-child claim, with Allen’s interval algebra handling the timing side. Chains of Conditions get a termination argument built on an acyclic dependency graph. The generic/curated boundary gets a mechanical test for where the model ends and a business artifact begins. It also includes the full four-cell matrix and compares the vocabulary with related work in provenance, complex event processing, and dimensional modeling.
Download the white paper to read the full vocabulary for temporal reasoning in data analytics.
A glossary of terms and the full reference list are included, so the reasoning can be checked independently.
✨ AI Post Recap
Jason Dossett’s white paper offers a small, implementation-agnostic vocabulary for temporal reasoning in data analytics, built on three categories. An Event is a punctual occurrence, a Condition is a rule that classifies Events, and an Episode is a bounded span of time that satisfies a Condition. Events carry two labels, Provenance and Generation, which record where a fact came from and how many derivation hops separate it from an observation.
What are Event, Condition, and Episode in temporal reasoning? An Event is a punctual occurrence at a specific instant. A Condition is a rule that classifies a stream of Events. An Episode is a bounded span of time, bounded by two Events, that satisfies a Condition.
How do you tell observed facts from derived ones in temporal reasoning in data analytics? Label each Event with Provenance. System-Observed Events come from sources like sensors or APIs. Synthetic Events are computed, whether spawned by a Condition, aggregated, correlated, or inferred by a model. Generation then counts the derivation hops from an observation.
What common modeling mistake does the white paper help catch? Conflating where a fact came from with what it means to the business. A four-cell matrix of derivation source against business meaning exposes it, for example when a team rebuilds a boundary from timestamps that the source already supplied.
