Analytica Data Science SolutionsContact
Services
Work
Products
Company
ESC

↑↓ to move↵ to open

← All work

Case study

Four decades of pipeline incidents, and the gap nobody had measured

Alberta had four decades of oil-spill records and no clear picture of what they showed. We analysed roughly 62,000 incidents, and found that the story everyone worried about — how fast spills get reported — was not the problem.

Client
Government of Alberta
Sector
Energy · Environment · Public sector
Role
Direct engagement
Period
38 years of records, 1975–2013
incidents over 38 years
~62,000incidents over 38 years
reported same day
94%reported same day
resolved same day
20%resolved same day

The problem

A provincial government holds decades of incident records because it is required to, not because anyone has the time to read them. Alberta wanted to know what four decades of oil and pipeline incidents actually showed: what caused them, whether response was improving, and whether reactive maintenance was still defensible.

What we did

We assembled roughly 62,000 incident records spanning 1975 to 2013 and joined them against public environmental and geological data from NASA, NOAA and the USGS, plus contemporary news reporting for context the official record did not carry.

Then geospatial mapping of incident locations, time-series decomposition at yearly and monthly resolution, categorisation by incident type, and — the part that produced the finding — distribution analysis of notification lag against time-to-completion.

The finding that mattered

Reporting was not the problem. 94% of incidents were reported the same day, and 100% within three days. The regulatory machinery around notification was working.

Resolution was the problem, and nobody had put a number on it. Only 20% of incidents were closed out the same day. Half took ten days or more. Some ran for months or years. The gap between "we know about it" and "it is dealt with" was the real exposure, and it was invisible until the two distributions were put side by side.

~62,000 incidents · 1975–2013

Reporting lag against time to resolution, and the March 1997 outlierTwo distributions over the same buckets. Reporting lag is concentrated almost entirely in the first bucket: 94 percent of incidents were reported the same day and all of them within three days. Time to resolution is spread across every bucket — only 20 percent were closed the same day, and the distribution runs out through weeks and months. The distance between the two shapes is the exposure the engagement quantified. Below, a yearly incident count rising with extraction activity, with one month that does not fit the trend: March 1997, traced to a magnitude 4.0 earthquake 350 miles away.REPORTEDThe regulatory machinery worked.94%RESOLVEDNobody had put a number on this.20%SAME DAY1–3 DAYS4–10 DAYS11–30 DAYS1–3 MONTHSLONGERONE MONTH THAT DID NOT FITMarch 1997 — a magnitude 4.0 earthquake, 350 miles away19752013
Reporting was never the problem. Resolution was, and it had never been measured — the two distributions are drawn over the same buckets precisely because the finding is the distance between them. Only the four figures the record supports are stated; the shape of the tail is drawn from the engagement's description of it rather than from a bucket-by-bucket breakdown we do not have.

The spike

The time series showed a steady rise in incidents over the period, consistent with rising extraction activity. It also showed one anomalous spike, in March 1997, that did not fit the trend.

Tracing it back: a magnitude-4.0 earthquake, 350 miles away, on 31 March 1997.

That is the kind of thread that does not surface from a dashboard. It surfaces because somebody looked at an outlier and asked what else happened that week.

Why it is publishable

Every input was public record. This case study names its client because the client is a government and the underlying data belongs to the public.

What are you trying to get right?

Tell us the decision you keep having to make with less certainty than you would like. We will tell you honestly whether the data you already have can support it — and if it cannot, we will say so on the first call rather than the third.

Start a conversation