[{"data":1,"prerenderedAt":4},["ShallowReactive",2],{"article-body-one-event-backbone":3},"\nTrace a single operational event through a typical enterprise. A\nsupplier's ownership changes in a registry on Monday. A data warehouse\npicks it up in a scheduled load midweek. A KPI recalculates in a\nnightly job. A weekly report renders the KPI. An analyst reading the\nreport raises a ticket. The ticket earns a meeting; the meeting amends\na plan; the amendment is minuted. A quarter later, an auditor asks a\nsimple question: show me how the plan change connects to the ownership\nchange. Six systems, four file exports and one shared drive later, the\nhonest answer is a shrug.\n\nTwo things died in transit. The first is time. Each hop between\nsystems runs on its own schedule, and the latencies stack into weeks\nbetween the world changing and the organisation responding. The second\nis quieter and worse: lineage. Every export, copy and re-key strips\nthe connection between an artefact and what caused it, until the\nrelationship between the change and the response is a matter of\ninstitutional memory.\n\n## The backbone alternative\n\nThe alternative architecture is one flow, not six stitched systems. A\nchange in the world enters once, as an event, and everything\ndownstream is a consequence on the same backbone:\n\n**A change. The KPI. The rule. The alert. The plan. The audit.**\n\n- The ownership **change** lands as an event with a timestamp and a\n  source.\n- The **KPIs** that depend on it recalculate because they subscribe to\n  it, not because a nightly batch happened to run.\n- The **rules** watching those KPIs evaluate immediately, with the\n  triggering event in hand.\n- A rule that trips raises one **alert**, addressed to a named owner,\n  carrying the whole causal chain: this alert exists because this\n  rule fired because this KPI moved because this change occurred.\n- The **plan** responds through a decision recorded against the\n  alert, with the intervention's expected effect stated.\n- And every link above writes itself into the **audit** trail as it\n  happens, because on a backbone the audit record is not a\n  reconstruction. It is the flow, replayed.\n\n> The auditor's question stops being an investigation and becomes a\n> query: walk the chain from the plan amendment back to the Monday\n> event, every hop typed and timestamped.\n\n## What the stitched version can never provide\n\nIt is tempting to treat this as an integration nicety, but two\nproperties are structurally unavailable to the export-and-import\narchitecture, at any budget:\n\n**Causality you can prove.** When systems exchange snapshots, the\nrelationship between artefacts is inferred after the fact, by people.\nWhen consequences flow from events, the relationship is recorded at\nthe moment it happens. Only the second survives an adversarial\nquestion, from an auditor, a regulator, or your own post-incident\nreview.\n\n**Latency measured in minutes.** A pipeline of five systems on\nnightly and weekly schedules has a floor on its response time,\nhowever fast each individual system becomes. A backbone's floor is\nthe propagation itself. The difference is not comfort. It is whether\nthe alert about Monday's ownership change arrives before or after\nThursday's payment run.\n\n*One flow, nothing stitched together after the fact.*\n\nProphesee runs on exactly this backbone. Change, KPI, rule, alert,\nplan and audit as one event-driven flow across every module. To trace\none of your own events through it, [start here](/contact).\n",1786799034545]