Static dependencies and runtime causality are different questions.

Configuration can tell you where an entity is referenced.

Before renaming or removing an entity, a useful question is whether loaded automations, scripts, scenes, groups, dashboards or templates refer to it. That is a static dependency problem.

A configuration scanner can preserve the source, the role of the reference and its exact location. Literal entity IDs can be recognized without executing templates. A script call can be followed structurally. A scene can expose membership. A dashboard can be marked as a dependent configuration.

This information is valuable precisely because it does not claim to know what will execute tonight. It describes configuration relationships that exist in the loaded system.

An incident starts from something that actually happened.

When a light changes unexpectedly at 19:42, the question is no longer “what could reference this light?” It is “what evidence was captured around this change?”

History, logbook entries, automation traces, service calls and Home Assistant context IDs can all contribute. The useful unit is an observed event and the structural context links around it, not every configuration that could theoretically touch the entity.

This is why runtime incident reconstruction benefits from a bounded recorder. Captured state changes, service calls, automation triggers and script starts can be normalized, ordered and inspected without retaining arbitrary Home Assistant objects forever.

Timing correlation should not quietly become a causal claim.

Home Assistant contexts provide stronger evidence than timestamps alone. A child context with a parent_id explicitly links one context to another. Events sharing a context can be shown as part of the same captured change and ordered as observed.

That still does not mean every earlier event directly caused the next one. If several events share one context, the relationship is between contexts and captured activity, not a guarantee that one selected row is the uniquely proven trigger.

When a required context is outside the buffer or absent from the original event, the right UI state is a gap such as Cause not captured, not an invented explanation based on “this happened 200 ms earlier.”

Unknown targets are part of the model, not an error to hide.

Static analysis has its own evidence boundaries. A literal entity ID inside a Jinja expression can be surfaced, but a dynamic expression may not reveal its final runtime target. Device, area, floor and label selectors can identify a selector without proving the exact entity set that will be eligible when the action executes.

Expanding those selectors into definite downstream effects would turn incomplete static information into false certainty. The more useful design is to retain a visible “needs review” class and keep direct references separate from broader coverage diagnostics.

One model helps before a change; the other helps after an incident.

Static dependency analysis is ideal for change planning: inspect the blast radius, find references and understand structural downstream relationships before mutating configuration.

Runtime forensics is ideal for incident review: start from the captured event, follow context evidence, save a bounded incident window and make missing evidence explicit.

Combining both into one “smart” causal engine would be tempting, but it would also make it easier to blur configuration possibility with runtime fact. Keeping the evidence models separate makes both answers more trustworthy.