Temperature is a patient witness.
A valve ruptures. A cooling system fails. A technician records a radiation reading. Minutes later, the core temperature crosses a danger threshold. The incident report now asks the question every system audit eventually asks, usually after everyone has already chosen a favorite suspect:
Who caused the temperature rise?
The lazy answer is “the last event before the alarm.” The slightly less lazy answer is “remove one event and see whether the alarm still happens.” Both are tempting. Both are also unreliable in systems where discrete actions and continuous dynamics live in the same room, which is to say most real-world engineered systems.
The paper behind this article, On the Semantics of Primary Cause in Hybrid Dynamic Domains, by Shakil M. Khan, Asim Mehmood, and Sandra Zilles, studies exactly this problem.1 It does not offer another dashboard attribution score. It gives a formal semantics for primary actual cause in hybrid dynamic domains, using the Hybrid Temporal Situation Calculus. That sounds abstract because it is abstract. The useful part is that the abstraction is aimed at a very practical failure mode: organizations often log actions, monitor continuous variables, and then pretend the causal connection between the two is obvious.
It is not.
The paper’s core idea is simple enough to state without symbolic machinery:
In a hybrid system, the primary cause of a temporal effect is not necessarily the last action before the effect. It is the action that enabled the active context under which the continuous variable crossed the threshold and then stayed there.
That sentence is the article. The rest is the machinery needed to make it precise.
The usual “but-for” instinct breaks when time is doing part of the work
Business readers usually meet causation through a counterfactual test:
If the action had not happened, would the effect still have happened?
This is the familiar “but-for” test. It works reasonably well for simple stories: if the switch had not been flipped, the light would not have turned on. Very neat. Very classroom-friendly. The world, unfortunately, has not signed the classroom attendance sheet.
Hybrid systems combine two different kinds of change:
| Layer | What changes | Example |
|---|---|---|
| Discrete action layer | Named events change the system state | A pipe ruptures; a cooling system fails; a repair action occurs |
| Continuous evolution layer | Values evolve over time under a context | Core temperature rises at a rate determined by the current failure mode |
The business version is familiar. A robot changes operating mode, then its physical trajectory evolves. A battery management system switches cooling policy, then temperature drifts. An AI workflow routes a case to an automated process, then latency, exposure, or risk accumulates over time.
The action does not always produce the effect immediately. It may only enable a condition under which the effect becomes true later. Between the action and the observed effect, other events may happen. Some are irrelevant. Some are partial contributors. Some are preempted alternatives that would have produced the same effect had the actual cause not taken over first.
This is why a naïve audit trail is dangerous. Event logs tell us what happened. They do not, by themselves, tell us which event enabled the continuous process that made the bad state inevitable or persistent. A log is not a causal model. It is a diary with timestamps.
The paper’s setting: actions create contexts; contexts drive continuous change
The paper works inside the Hybrid Temporal Situation Calculus, or HTSC. The ordinary Situation Calculus represents dynamic worlds as histories of named actions. A “situation” is basically the world after some sequence of actions has occurred. Fluents are properties that may change from situation to situation.
HTSC adds temporal fluents. These are values that can vary over time inside a situation. The paper’s running example uses a nuclear power plant:
- actions include pipe rupture, cooling failure, pipe repair, cooling repair, and radiation measurement;
- discrete fluents include whether the pipe is ruptured and whether the cooling system has failed;
- the temporal fluent is the core temperature at a given time;
- contexts determine how the temperature changes.
The contexts are mutually exclusive. For the example, the relevant contexts include:
| Context | Discrete condition | Temperature behavior in the simplified example |
|---|---|---|
| $\gamma_1$ | Pipe ruptured and cooling failed | Temperature rises fastest |
| $\gamma_2$ | Pipe ruptured only | Temperature rises more slowly |
| $\gamma_3$ | Cooling failed only | Temperature rises at another rate |
The exact rates in the paper’s illustrative model are simplified, not meant as plant physics. Their job is to show how discrete failure states control the evolution of a continuous variable. In a real digital twin, those equations could be replaced by more realistic differential equations. The logical point would remain: the temperature changes because a context is active, and the context is active because some action enabled it.
That gives us the first useful separation:
| Question | Wrong shortcut | Better causal question |
|---|---|---|
| What happened last? | Check the final event before the alarm | Often irrelevant |
| What changed the continuous variable? | Look only at the threshold crossing | Too late; the process was already underway |
| What enabled the active dynamics? | Identify the context active when the effect was achieved | This is where primary causation begins |
The paper’s mechanism is built around this separation.
Step one: find the achievement situation, not just the alarm time
A temporal effect such as:
is not like a discrete light switch. It becomes true at some point in time and may remain true afterward. The paper therefore introduces the idea of an achievement situation.
An achievement situation is the earliest situation in the scenario where the effect is true at the end of that situation and remains true in all later situations and relevant time points through the observation point.
This does two jobs.
First, it prevents the model from treating temporary or unstable truth as the relevant achievement. A spike that immediately disappears is not the same kind of causal target as a condition that becomes true and persists.
Second, it prevents the model from blaming later events. If temperature already crossed the threshold and stayed above it, a later radiation measurement may be part of the record, but it is not the primary cause of the overheating. This sounds obvious until one remembers how many operational reports confuse detection with production. The smoke alarm did not cause the fire. Shocking, I know.
The achievement situation is therefore a temporal anchor. It tells us where to look for the active dynamics.
Step two: identify the active context driving the temporal fluent
In HTSC, temporal fluents evolve only under relevant contexts. The paper assumes these contexts are mutually exclusive for the temporal fluent under consideration. That assumption matters. If only one relevant context can be active at the achievement situation, then the model can avoid a swamp of competing simultaneous explanations.
For the plant example, suppose the temperature crosses the threshold while both the pipe is ruptured and the cooling system has failed. The active context is not “some bad plant condition.” It is the particular context under which both failures jointly define the temperature evolution rule.
This is the subtle move in the paper. The primary cause of the temporal effect is not defined by looking directly at the temperature curve alone. It is found by looking at the context responsible for that curve at the moment the effect is achieved.
In operational terms:
Discrete action
-> enables context
-> context governs continuous evolution
-> temporal effect becomes true and persists
The causal question is therefore not “which action was closest to the effect?” It is:
Which action enabled the context that was active when the effect was achieved?
That replacement is the paper’s main intellectual value.
Step three: blame the context-enabling action, not the nearest event
Once the achievement situation and the active context are identified, the paper defines the primary temporal achievement cause as the action that directly caused that context.
This produces several useful distinctions.
A radiation measurement may occur right before the observation, but it does not enable a temperature-changing context. It is not the cause.
An earlier action may have contributed to some slower temperature rise, but if it is not the direct cause of the active context in the achievement situation, it is not the primary cause.
An action may matter indirectly, but the paper deliberately brackets indirect causes. The target is primary cause for primitive temporal effects, not a full responsibility graph for every enabling condition, maintenance failure, and management decision since 2017. That graph may be useful. It is just not this paper.
The difference is easiest to see in table form:
| Candidate event | Why a naïve report may blame it | Why the paper may reject it as primary cause |
|---|---|---|
| Last event before the threshold is observed | It is temporally close | It may not affect the relevant temporal fluent |
| Earlier partial failure | It contributed to some temperature increase | It may not be the context active at achievement |
| Measurement event | It reveals the bad state | Detection is not production |
| Action enabling the active context | It may be earlier and less visible | This is the action that made the decisive continuous dynamics operate |
This is where the paper is most relevant for AI operations and industrial automation. Modern systems produce a lot of traces. Many traces are observational. Some are control actions. Some are mode switches. Some are downstream consequences. If a system cannot distinguish these categories, its “root cause analysis” is often just timestamp theater.
What the formal results actually support
The paper does not run experiments. There are no benchmark tables, ablation curves, or performance scores. Its evidence is formal: definitions, examples, properties, equivalence, and proof sketches.
That matters because the article should not pretend the paper empirically validates an industrial root-cause system. It does something narrower and cleaner: it shows that the proposed semantics has intuitive formal properties under a restricted setting.
| Paper component | Likely purpose | What it supports | What it does not prove |
|---|---|---|---|
| Nuclear power plant example | Illustrative case | The definitions separate true causes from irrelevant nearby actions | Real-world plant validity or physical realism |
| Achievement situation definition | Main semantic mechanism | The effect is anchored to the earliest persistent achievement point | Handling all transient, noisy, or probabilistic observations |
| Primary cause definition | Main contribution | Primary cause is tied to the context active at achievement | Full causal responsibility across indirect causes |
| Uniqueness properties | Formal sanity check | The framework can identify a unique primary cause in the restricted setting | That real systems always have unique blameworthy agents |
| Contribution-based definition | Alternative semantic route | Causation can be described via contributors and still match the foundational definition | That contribution tracing is easy to implement from raw logs |
| Modified but-for theorem | Counterfactual validation | Removing the cause plus preempted contributors makes the effect disappear or the scenario non-executable under stated conditions | That simple one-action counterfactual deletion is sufficient |
The uniqueness result is especially important. Given the paper’s assumptions, the direct cause, the achievement situation, and the primary cause of the primitive temporal effect are unique. That is not a minor convenience. In business contexts, ambiguous cause assignment is expensive. It creates duplicated investigations, defensive reporting, and the wonderful corporate ritual of everyone being “partly responsible” in a way that means nobody is accountable.
But uniqueness comes from modeling discipline. The contexts are mutually exclusive. The scenario is linear. The effect is primitive and temporal. The paper earns clarity by narrowing scope. That is a strength, not a weakness, as long as we do not sell it as a universal blame machine.
The contribution-based route is not decorative; it tests the same idea from another angle
After defining primary cause through achievement situations and active contexts, the paper gives a second route: causation via contribution.
This section can look redundant at first. It is not.
The first definition is foundational: start with actions, contexts, achievement, and define the cause. The second definition asks whether the same cause can be characterized as a contributor to the temporal effect. It introduces direct possible contributors, direct actual contributors, and then defines primary cause through actual contribution in the achievement situation.
The paper then proves that the two definitions are equivalent.
This matters because causation theory has long had competing instincts:
- counterfactual accounts ask what would happen if something were removed;
- production or regularity-oriented accounts ask what produced the effect;
- action-theoretic accounts ask how actions change histories and fluents.
The paper does not resolve all philosophy of causation, mercifully. It shows that, in this restricted hybrid setting, the foundational and contribution-based routes converge.
For business interpretation, that convergence suggests two implementation views:
| Implementation view | Operational question | Causal object |
|---|---|---|
| Context-first | Which context was active when the temporal effect was achieved? | The action that enabled that context |
| Contribution-first | Which action directly contributed to the temporal fluent becoming true in the achievement situation? | The same primary cause, under the paper’s assumptions |
This is useful because real engineering teams do not all think in the same representation. A control engineer may think in modes and state evolution. A process auditor may think in contributor chains. A formal assurance team may think in action theories. The paper’s equivalence result says these perspectives can be made to meet, at least for the defined class of problems.
That “at least” is doing work. Please do not ignore it and then blame the framework when a messy production system refuses to behave like a theorem.
Why ordinary but-for causation fails harder in hybrid domains
The paper’s modified but-for test is the most business-friendly part of the theory because it explains why intuitive counterfactual investigation often goes wrong.
Suppose action $A$ is identified as the primary cause. A naïve analyst removes $A$ from the scenario and checks whether the effect still occurs. If the effect still occurs, the analyst concludes $A$ was not really the cause.
That conclusion may be wrong because of preemption.
A preempted contributor is an action that did not cause the effect in the actual scenario because another action got there first or produced the relevant context more decisively. If the actual cause is removed, the preempted contributor may become the new cause.
In discrete domains, preempted causes are usually imagined as later backups: if the first person had not thrown the rock, the second person would have broken the window. In hybrid domains, the paper points out a more awkward possibility: a preempted contributor can occur before the actual cause. That can happen because removing the actual cause may allow an earlier context to persist long enough to produce the effect.
This is the hybrid twist. Continuous time gives older conditions a way to keep working in the background.
The paper’s fix is not to remove only the actual cause. It constructs a defused situation:
- Replace the actual cause with a no-op action.
- Check whether another primary cause emerges in the modified scenario.
- If it does, replace that newly emerged preempted contributor with a no-op as well.
- Repeat until the scenario is defused as far as possible.
- Then test whether the effect still holds or whether the scenario has become non-executable.
The theorem says that, under the condition that no relevant context was already active initially, the defused scenario either loses the effect or becomes non-executable.
This is a more disciplined counterfactual test. It says: do not test causation by deleting one event and leaving all backup causal machinery intact. That is like testing whether a fire sprinkler mattered by turning it off while leaving the emergency foam system, backup pump, and helpful intern with a bucket in place.
The paper is also careful about what this theorem proves. It is not a universal proof that the definition is correct. The authors explicitly note that even a bad definition might satisfy a similar property in some cases. The point is narrower: the proposed cause behaves in an intuitively counterfactual way once preempted contributors are handled.
That is the right level of claim.
The business lesson: model the causal pathway, not just the incident timeline
For AI operations, robotics, process automation, and digital twins, the practical lesson is not “use HTSC tomorrow morning.” Most organizations are not going to wake up, formalize their operational domain in second-order logic, and still make the 9:30 meeting.
The more useful lesson is architectural:
If your system contains discrete control actions and continuous state evolution, your audit model must represent the bridge between them.
That bridge is the context.
A meaningful causal trace should include at least five layers:
| Layer | What must be represented | Why it matters |
|---|---|---|
| Action log | Named actions with time and situation identity | Distinguishes actions from observations |
| Context model | Mutually exclusive or otherwise well-defined modes | Determines which continuous dynamics apply |
| State evolution model | How temporal fluents change under each context | Connects actions to delayed effects |
| Achievement logic | Earliest persistent point where the effect holds | Prevents blaming late or irrelevant events |
| Preemption handling | Alternative contributors after cause removal | Prevents false rejection of actual causes |
This is where the paper becomes relevant to business systems.
A digital twin that records sensor values but not the action-context relationship can describe what happened, not why. An AI agent platform that logs tool calls but not state transitions can show a trace, not a causal explanation. A robotic system that records a failure mode but not how that mode changed physical dynamics can support debugging, but only up to the point where everyone starts pointing at charts.
The framework suggests that robust incident explanation needs a causal schema, not merely observability.
What Cognaptus infers for AI governance and operational design
The paper directly shows a formal semantics for primary cause in a restricted hybrid action-theoretic setting. Cognaptus draws a broader, but bounded, business inference:
Hybrid causal explanation should be treated as a design requirement for systems where automated decisions change real-world dynamics over time.
That inference applies most strongly when three conditions hold:
- discrete actions or decisions switch operational modes;
- continuous variables evolve under those modes;
- threshold events matter for safety, compliance, cost, or liability.
Examples include autonomous vehicles, industrial control systems, medical devices, smart grids, warehouse robotics, energy systems, and some AI-driven workflow platforms where risk accumulates after a routing or approval decision.
The immediate ROI is not philosophical elegance. The ROI is cheaper diagnosis, cleaner audits, and less confusion between detection, contribution, and causation.
| Directly shown by the paper | Cognaptus business inference | Boundary |
|---|---|---|
| Primary cause can be tied to the context active at achievement | Root-cause systems should record action-to-context transitions | Requires an explicit domain model |
| Primary cause is unique under the paper’s assumptions | Audit workflows can reduce ambiguity when contexts are well modeled | Real systems may violate mutual exclusivity |
| Contribution and foundational definitions are equivalent | Different engineering teams can reason from modes or contributors | Only for the paper’s restricted class of effects |
| Modified but-for testing handles preemption | Incident analysis should remove backup contributors, not just one event | Requires identifying possible preempted contributors |
| Initial active contexts may imply no primary cause exists | Some harmful effects may come from initial conditions rather than later actions | This does not settle legal or managerial responsibility |
That last row deserves attention. The paper shows that a primary cause may not exist if the relevant context was already active in the initial situation and remained active until the effect was achieved. In business language: not every later incident has a later operational trigger. Sometimes the system was already in the dangerous mode when the observation window began.
That is uncomfortable for accountability, but useful for diagnosis. It tells auditors to ask whether the causal origin lies outside the scenario being analyzed. A missing primary cause is not a bug in the report. It may be the report telling you that the scenario starts too late.
Boundaries: where the paper stops before reality becomes rude
The paper’s scope is disciplined. That is why its definitions can be sharp. But the boundaries are material.
First, it focuses on primitive temporal effects. It does not handle arbitrary compound effects. Many business incidents are compound: temperature too high while pressure is unstable, or credit exposure rising while liquidity deteriorates, or an AI workflow both delays a case and escalates the wrong customer. Those require richer treatment.
Second, it studies primary causes, not indirect causes. In real organizations, indirect causes are often where governance lives: bad maintenance, flawed policy, inadequate monitoring, poor training, or a design decision three quarters ago. The paper’s primary cause tells us which action enabled the decisive context, not the entire institutional ancestry of the incident.
Third, the scenario is linear. The paper does not tackle concurrent multiagent action in this work. That matters for distributed systems, robotics fleets, markets, and multi-agent AI workflows where many actions may happen simultaneously or asynchronously.
Fourth, the framework assumes a formal model of actions, contexts, and state evolution. Raw logs will not give this to you for free. A company would need to define contexts, specify state evolution rules, and decide how observations map onto temporal fluents. This is engineering work, not dashboard decoration.
Fifth, the paper is deterministic and symbolic. Real sensor data are noisy. Learned models are uncertain. Human processes are under-specified. A production-grade implementation would need to decide how formal causal semantics interacts with probabilistic estimation and imperfect measurement.
These boundaries do not make the work less useful. They make it easier to use honestly. The paper is not a plug-and-play root-cause engine. It is a formal account of what a root-cause engine should mean when the system is hybrid.
The practical takeaway: causation needs a state model
The strongest message of the paper is that causation in hybrid domains is not found by staring harder at the final event.
A temporal effect is achieved under a context. That context was enabled by an action. If the effect persists, the primary cause is the action that enabled the active context in the achievement situation. If removing that action allows another contributor to take over, the counterfactual test must defuse the preempted contributors too. Otherwise, the analyst is not testing causation. They are testing whether the backup failure mode was also available.
For Cognaptus readers, the real implication is architectural:
- do not build AI audit systems that only store event timelines;
- do not confuse sensor measurement with causal production;
- do not treat one-action counterfactual deletion as sufficient;
- do model contexts, state evolution, achievement points, and preemption.
The paper is formal, narrow, and occasionally unforgiving. Good. Causation should be unforgiving. When systems act in discrete steps but fail through continuous drift, a vague attribution layer is not explainability. It is paperwork wearing a lab coat.
Temperature rises over time. Responsibility should not evaporate in the interval.
Cognaptus: Automate the Present, Incubate the Future.
-
Shakil M. Khan, Asim Mehmood, and Sandra Zilles, “On the Semantics of Primary Cause in Hybrid Dynamic Domains,” arXiv:2602.14994, 2026. ↩︎