A failure log is rarely polite.
A cooling pipe ruptures. A control system fails. Temperature does not jump instantly; it climbs. A later inspection action records an unsafe reading. Somewhere in that sequence, someone asks the expensive question: what caused the threshold breach?
The lazy answer is: the last event before the alarm.
The slightly less lazy answer is: remove each event and see whether the breach still happens.
Both answers are attractive. Both can be wrong.
That is the problem addressed in On the Semantics of Primary Cause in Hybrid Dynamic Domains, a formal paper by Shakil M. Khan, Asim Mehmood, and Sandra Zilles.1 The paper asks how to define actual primary cause in domains where discrete actions and continuous change coexist. Not metaphorically. Formally. In a logic where actions happen at times, situations evolve, and temporal fluents such as temperature can change continuously under discrete contexts.
This matters because many AI and automation systems live in exactly this hybrid world. A robot receives a command, then battery charge decays. A trading agent places an order, then portfolio exposure evolves with market prices. A digital twin records a valve state, then pressure accumulates. A clinical workflow triggers an intervention, then patient vitals move gradually. The real effect is often a threshold crossing, not a button flipping.
So the core question is not simply “which event happened before the outcome?” It is:
Which discrete action enabled the context under which the continuous process achieved the observed effect?
That one sentence is the paper’s useful center of gravity.
The old but-for instinct breaks when time keeps moving
Actual causation usually begins with a familiar counterfactual intuition: if the cause had not occurred, the effect would not have occurred. This is the classic “but-for” test.
It works beautifully until it does not.
The known problem is preemption. Suppose two events could have caused the same outcome. One happens first and achieves the result; the other is present but never gets to matter because the result has already been achieved. If we remove the first event, the second may step in. A naive but-for test then says the first event was not a cause, even though it clearly was.
Hybrid domains make this worse. In a purely discrete domain, preemption usually has a clean temporal order: the actual cause fires first; the preempted alternative would have fired later. In a hybrid domain, an earlier action can create a context that does not immediately achieve the effect, but would have achieved it later if another context had not taken over.
That is the annoying part. The preempted contributor may occur before the actual primary cause.
Continuous change gives old events a longer shadow.
Hybrid Temporal Situation Calculus gives the paper its machinery
The paper works inside Hybrid Temporal Situation Calculus, or HTSC. The important idea is manageable even if the formal notation is not something one casually reads over breakfast, unless breakfast has gone badly.
Situation calculus represents a dynamic world through actions and situations. A situation is a history of actions. A fluent is a property whose value can change from situation to situation.
Standard situation calculus is mostly discrete: actions change fluents. HTSC extends this by separating two things:
| Component | What it represents | Example |
|---|---|---|
| Discrete actions | Named events that happen at a time | pipe ruptures, cooling system fails, pipe is fixed |
| Discrete fluents | Contextual states changed by actions | pipe is ruptured, cooling system has failed |
| Temporal fluents | Values that evolve over time | core temperature at time $t$ |
| State evolution axioms | Rules for how temporal fluents change under context | temperature rises faster when both pipe and cooling fail |
This separation is the key. Continuous change is not treated as magic. It happens under contexts. A temperature changes according to one rule when the pipe is ruptured and the cooling system has failed, another rule when only the pipe has ruptured, and another when only cooling has failed.
In the paper’s running nuclear power plant example, the authors use simplified rate equations:
| Context | Discrete condition | Temperature behavior in the example |
|---|---|---|
| $\gamma_1$ | pipe ruptured and cooling failed | rises at 100 degrees per second |
| $\gamma_2$ | pipe ruptured and cooling working | rises at 35 degrees per second |
| $\gamma_3$ | pipe intact and cooling failed | rises at 55 degrees per second |
The specific numbers are illustrative, not empirical engineering claims. The point is structural: actions enable contexts, and contexts govern continuous evolution.
That is why the primary cause of a temporal effect is not necessarily the action nearest the threshold crossing. It is the action that enabled the context active when the effect was achieved.
The first mechanism: find the achievement situation
For a discrete effect, causation can often be tied to the action after which the effect becomes true. For a temporal effect, that is not enough.
A temporal effect may become true after time passes. Irrelevant actions may occur between the original context-changing action and the later threshold crossing. A technician may measure radiation. A logging system may write a record. A robot may beep in a very official tone. None of those necessarily caused the temperature to cross the line.
So the paper introduces the idea of an achievement situation.
The achievement situation is the earliest situation in the scenario where the temporal effect holds by the end of that situation and continues to hold through the later relevant parts of the scenario. This “continues to hold” condition is important. The paper is concerned with achievement causation: the effect was false before and is achieved as true. It is not merely searching for a transient blip.
Operationally, the achievement situation works like an audit timestamp, but with better manners. It asks:
- When did the effect become true?
- In which situation did that happen?
- Did it remain true afterward, up to the observation point?
Only after this point is fixed can the paper ask which context was active and which action enabled that context.
This is the first major correction to naive reasoning. In hybrid systems, cause identification needs a temporal landing zone. Without the achievement situation, the analysis is just staring at a log and hoping chronology will confess.
The second mechanism: identify the active context, not the nearest event
Once the achievement situation is identified, HTSC does something useful: it checks which context for the temporal fluent was active there.
Because the relevant contexts are assumed to be mutually exclusive, only one context governs the temporal fluent at the achievement situation. This matters because mutual exclusivity prevents the framework from attributing the same primitive temporal effect to two simultaneous context rules.
The primary cause is then defined as the action-time-stamp pair that directly caused the active context.
In plainer language:
The primary cause of a temporal effect is the action that enabled the discrete context under which the continuous fluent achieved the effect.
That is the paper’s foundational definition.
This also explains why the framework can ignore irrelevant intervening actions. If an action occurs after the context was enabled but does not enable the active context governing the temporal fluent, it is not the primary cause. It may be close to the observed event. It may appear in the dashboard. It may have a dramatic log message. That does not make it causally important. Logs are not immune to theatre.
The contribution-based definition says the same thing from the production side
The paper does not stop with one definition. It gives a second definition based on contribution.
This second route defines possible contributors, actual contributors, and then primary cause through actual contribution to the achievement situation. A direct possible contributor is an action that can initiate the relevant temporal change by causing a context of the temporal fluent. A direct actual contributor is such a contributor that actually appears in the scenario and is linked to the achievement situation.
The primary cause is then the direct actual contributor associated with the active context when the effect is achieved.
This definition matters because it shows that the paper is not merely naming the context-enabling action and calling the job done. It connects the foundational action/context view to a production-style view of causation: what action actually contributed to producing the observed temporal effect?
The paper proves that the two definitions are equivalent.
| Definition route | What it emphasizes | Why it matters |
|---|---|---|
| Foundational definition | The action that directly enabled the active context in the achievement situation | Gives a clean semantic account inside HTSC |
| Contribution-based definition | The action as an actual contributor to the temporal effect | Connects the account to production-style causation |
| Equivalence theorem | Both routes identify the same primary cause | Reduces the risk that the result is an artifact of one formal framing |
For business readers, this is not a benchmark result. There is no accuracy score to admire politely. The evidence is formal: definitions, lemmas, equivalence, and counterfactual validation. That is appropriate for the paper’s goal. It is building semantics, not shipping a root-cause-analysis dashboard.
The modified but-for test removes the cause and the hidden substitutes
Now we return to the tempting but-for test.
If the identified primary cause is real, should the effect disappear when the cause is removed?
Not necessarily. Preemption can make the effect appear anyway. Another action may become the new primary cause once the actual cause is removed. In hybrid domains, that alternative contributor may even have occurred earlier, because an earlier context may persist long enough to achieve the effect if the later context-changing action is removed.
The paper’s answer is a modified but-for test using a defused situation.
The procedure is conceptually simple:
- Replace the identified primary cause with a no-op action.
- Check whether another action becomes the primary cause in the modified scenario.
- If a new primary cause appears, treat it as preempted and replace it with a no-op too.
- Repeat until no further primary contributors remain, or until the maximal removable set has been defused.
- Evaluate whether the effect still holds or whether the scenario remains executable.
The no-op action is not a casual placeholder. It must be an action that is always possible and has no effect, and the domain modeler is responsible for making that true. This is a modeling obligation, not a gift from the universe.
The paper then proves a counterfactual-dependence property: under the condition that no relevant context of the temporal fluent is already active initially, the defused scenario either no longer has the effect or becomes non-executable.
This is not presented as a complete proof that the definition is uniquely correct. The authors explicitly note that such a property alone is not enough to certify a definition of causation. A bad definition might also satisfy a superficially similar property. The point is more disciplined: the proposed cause behaves the way an intuitively valid cause should behave under a structurally aware counterfactual test.
The modified but-for test is therefore not the foundation of the definition. It is a validation lens.
That distinction is worth keeping. Otherwise, we end up pretending that counterfactual replay is a magic wand. It is not. It is a test whose meaning depends on the model underneath it.
What the paper’s formal results actually support
Because this is a formal semantics paper, its “findings” are not experimental. The paper’s support comes from definitions and theorems, with a running example used to show why the definitions behave intuitively.
Here is the useful reading map:
| Paper component | Likely purpose | What it supports | What it does not prove |
|---|---|---|---|
| Nuclear power plant example | Running illustration | Shows why nearest-event reasoning fails and why context matters | Does not validate the framework empirically |
| Achievement situation definition | Core mechanism | Locates the earliest maintained achievement of a temporal effect | Does not handle arbitrary compound effects |
| Primary cause definition | Main formal contribution | Links temporal effects to the action that enabled the active context | Covers primary causes only |
| Contribution-based definition | Alternative semantic route | Shows causation can be read through actual contribution | Does not add a separate empirical result |
| Equivalence theorem | Internal consistency result | Shows the two definitions converge | Does not prove practical deployability |
| Modified but-for theorem | Counterfactual validation | Shows effect disappears or scenario fails after defusing cause and preempted contributors, under stated conditions | Does not make naive but-for reasoning valid |
| Appendix proof sketches | Formal support | Provide proof structure for properties | Not an implementation guide |
The most business-relevant result is not “the model finds a cause.” It is more precise:
If a domain can be modeled as a linear hybrid action scenario with mutually exclusive contexts governing primitive temporal fluents, the paper gives a formal way to identify a unique primary cause of a threshold-like temporal effect, and to validate it through a modified counterfactual defusion test.
That sentence is less flashy than “AI can explain everything.” It also has the advantage of being true.
The operational translation: from formal semantics to causal audit workflow
The paper does not provide enterprise software. It does, however, suggest what a rigorous causal audit pipeline would need to contain.
A practical system inspired by this paper would need at least seven steps:
| Step | Operational task | Why it matters |
|---|---|---|
| 1 | Represent the event history as a linear scenario | The framework assumes ordered action traces |
| 2 | Define discrete fluents | These are the context states changed by actions |
| 3 | Define temporal fluents | These are continuously evolving values such as temperature, pressure, battery charge, risk exposure |
| 4 | Specify mutually exclusive contexts | The active context determines how the temporal fluent evolves |
| 5 | Define the observed temporal effect | Usually a constraint such as $temp(t) > threshold$ |
| 6 | Locate the achievement situation | Prevents confusion between cause, delay, and later observation |
| 7 | Defuse cause and preempted contributors | Tests whether the effect depends on the identified causal structure |
This is where the paper becomes relevant for industrial digital twins, robotics logs, safety workflows, and agentic systems.
The business value is not “better philosophical hygiene,” although one should not underestimate the ROI of fewer confused meetings. The value is sharper post-incident diagnosis:
- Was the effect caused by the action that changed the relevant operating mode?
- Was a later event merely an observation?
- Did an earlier action become preempted by a later, stronger context?
- Was the apparent cause actually outside the observed trace because the relevant context was already true initially?
- Would removing the identified cause merely expose another contributor?
Those are practical audit questions. They appear in safety reviews, compliance reports, insurance disputes, AI governance documentation, and internal engineering postmortems.
The strongest business implication is cheaper diagnosis, not automatic blame
The paper’s framework is useful because it separates four things that are often mixed together in business narratives:
| Common business question | Formal replacement |
|---|---|
| “What happened right before the failure?” | Which situation achieved the temporal effect? |
| “Which event looks responsible?” | Which action enabled the active context? |
| “Would the failure still happen without it?” | What happens after defusing the cause and preempted contributors? |
| “Who is responsible?” | Not answered directly; causal attribution is not the same as legal or managerial responsibility |
That last row matters. The paper is about primary actual cause, not moral blame, legal liability, or organizational accountability. A causal explanation can support responsibility analysis, but it does not replace it. Businesses enjoy skipping this distinction because it makes slide decks shorter. Reality, once again, is less polite.
For an AI governance team, the framework’s immediate value is explanation discipline. It encourages system designers to model how discrete decisions affect continuous variables over time. That is especially relevant for agentic systems whose actions trigger downstream processes: order placement, resource allocation, robotic movement, pricing changes, automated approvals, or physical controls.
But the model must already know the domain’s causal structure. HTSC does not infer the correct contexts from messy logs by itself. Someone still has to model the system.
That someone should probably be sober.
The implicit-cause case is the audit trap executives will miss
One of the paper’s important properties is that a primary cause may not exist inside the scenario.
This can happen when the relevant context was already true initially. If the system begins in a state where the temporal fluent is already evolving toward the threshold, then no action in the observed trace may be the primary cause. The effect may be driven by the initial situation.
For business systems, this is a serious warning. Many post-incident investigations begin too late.
If a machine was already overheating before the recorded workflow started, the “cause” may not be in the incident log. If an AI agent inherited a risky portfolio state before the latest trade sequence, the causal trigger may predate the audit window. If a hospital workflow begins after a patient’s risk state has already been established, the visible action trace may contain only symptoms and measurements.
The framework’s answer is not to force a cause into the available log. It allows the possibility that the observed scenario lacks a primary action cause.
This is a useful form of formal humility. We could use more of it, particularly in dashboards that color everything red and call that insight.
Where the framework is deliberately narrow
The paper is careful about scope. That is good, because the restrictions matter.
First, it focuses on primitive temporal fluents. The effect is a constraint on a temporal fluent such as a temperature value. The paper does not yet handle arbitrary compound effects involving complex combinations of discrete and temporal conditions.
Second, it assumes linear scenarios. The action history is a sequence, not a concurrent multi-agent event structure. Many real AI systems involve concurrency, distributed control, and overlapping agency. Those require additional machinery.
Third, it studies primary causes, not indirect causes. Earlier actions that made the primary cause executable, or that enabled preconditions for the primary cause, are not the focus here.
Fourth, the framework depends on careful domain modeling. Contexts must be defined. State evolution axioms must be specified. No-op actions must truly have no effect. The logic can only be as reliable as the model.
Fifth, the modified but-for test assumes conditions such as no relevant context being active initially. If a context is already active at the start, the effect may persist after defusion because the cause is implicit in the initial state.
These are not minor footnotes. They define where the paper can safely be used.
The right conclusion is not “this solves causality for hybrid AI.” The right conclusion is narrower and more useful: this gives a coherent semantics for primary actual cause in a restricted but important class of hybrid dynamic domains.
Why this is better than another explainability slogan
Most business discussions of AI explainability still lean heavily on output explanations: feature importance, model rationales, chain summaries, decision logs. Those are helpful, but they often fail when the system’s effect unfolds through time.
A temporal system does not merely decide. It evolves.
That means explanation must track the difference between:
- the action that changed the mode;
- the continuous process that followed;
- the later observation of the effect;
- the alternative contributors that were preempted;
- the initial conditions that may have already carried the system toward the outcome.
This paper’s contribution is to make that distinction formal.
For Cognaptus-style automation work, the business lesson is straightforward: causal audit systems should not be bolted onto logs after deployment. They should be designed into the domain representation. If the enterprise wants serious post-incident explanation, it needs structured action traces, modeled contexts, temporal fluents, and explicit state evolution rules.
Otherwise, the audit layer becomes a historian with missing archives and a confident tone. We already have enough of those.
Conclusion: the cause is the context trigger, not the loudest log entry
The paper’s main insight is deceptively simple: in hybrid domains, primary causation runs through context.
A discrete action enables a context. The context governs continuous evolution. The temporal fluent eventually achieves the effect. The primary cause is the action that enabled the active context at the achievement situation.
The contribution-based definition confirms this from another angle. The modified but-for test then shows how to validate the cause after removing both the actual cause and the preempted contributors that would otherwise muddy the counterfactual.
For safety-critical workflows, robotics, digital twins, and agentic AI systems, this is not just logical housekeeping. It is a blueprint for more disciplined causal diagnosis.
Not automatic blame. Not generic explainability. Not a magical “why” button.
Just the beginning of a more precise way to say what actually caused what when the world refuses to change one discrete step at a time.
Notes
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. https://arxiv.org/abs/2602.14994 ↩︎