One event backbone

A change happens, a KPI moves, a rule fires, an alert reaches an owner, a plan responds, an audit trail records all of it. In most enterprises those are six systems stitched together by exports. Lineage dies in the stitching.

3 min read

Trace a single operational event through a typical enterprise. A supplier's ownership changes in a registry on Monday. A data warehouse picks it up in a scheduled load midweek. A KPI recalculates in a nightly job. A weekly report renders the KPI. An analyst reading the report raises a ticket. The ticket earns a meeting; the meeting amends a plan; the amendment is minuted. A quarter later, an auditor asks a simple question: show me how the plan change connects to the ownership change. Six systems, four file exports and one shared drive later, the honest answer is a shrug.

Two things died in transit. The first is time. Each hop between systems runs on its own schedule, and the latencies stack into weeks between the world changing and the organisation responding. The second is quieter and worse: lineage. Every export, copy and re-key strips the connection between an artefact and what caused it, until the relationship between the change and the response is a matter of institutional memory.

The backbone alternative

The alternative architecture is one flow, not six stitched systems. A change in the world enters once, as an event, and everything downstream is a consequence on the same backbone:

A change. The KPI. The rule. The alert. The plan. The audit.

  • The ownership change lands as an event with a timestamp and a source.
  • The KPIs that depend on it recalculate because they subscribe to it, not because a nightly batch happened to run.
  • The rules watching those KPIs evaluate immediately, with the triggering event in hand.
  • A rule that trips raises one alert, addressed to a named owner, carrying the whole causal chain: this alert exists because this rule fired because this KPI moved because this change occurred.
  • The plan responds through a decision recorded against the alert, with the intervention's expected effect stated.
  • And every link above writes itself into the audit trail as it happens, because on a backbone the audit record is not a reconstruction. It is the flow, replayed.

The auditor's question stops being an investigation and becomes a query: walk the chain from the plan amendment back to the Monday event, every hop typed and timestamped.

What the stitched version can never provide

It is tempting to treat this as an integration nicety, but two properties are structurally unavailable to the export-and-import architecture, at any budget:

Causality you can prove. When systems exchange snapshots, the relationship between artefacts is inferred after the fact, by people. When consequences flow from events, the relationship is recorded at the moment it happens. Only the second survives an adversarial question, from an auditor, a regulator, or your own post-incident review.

Latency measured in minutes. A pipeline of five systems on nightly and weekly schedules has a floor on its response time, however fast each individual system becomes. A backbone's floor is the propagation itself. The difference is not comfort. It is whether the alert about Monday's ownership change arrives before or after Thursday's payment run.

One flow, nothing stitched together after the fact.

Prophesee runs on exactly this backbone. Change, KPI, rule, alert, plan and audit as one event-driven flow across every module. To trace one of your own events through it, start here.

New essays land on LinkedIn first. Follow 3RDi to catch them, or get a demo to see Prophesee on your own data.