The Answer Nobody Can Give

Two years later at Meridian Utilities

You have not missed anything if this is your first Meridian training. Here is the whole story so far, and then we start.

Meridian Utilities is a mid-size regional utility. Two years ago it moved off a data center: sized up its estate, chose where each workload should run, and migrated a decade of billing, outage, and meter data into a cloud lake. That migration was careful. It ran on an agreed data contract, it used a recorded cut-point so nobody had to guess which rows had moved, and it did not cut over until an independent count check passed. Nothing was lost.

Since then the estate got a great deal of attention. Access became identity-first rather than network-position-first. Delivery became a real pipeline with governed templates and provable build artifacts. The utility won a state-federal interconnect contract and learned to ship software into an environment where an assessor signs before anything goes live.

All four of those were platform work. Here is what nobody did in two years:

Nobody turned the data into a single answer anyone acted on.

The gap is not the platform

It is tempting to read that and conclude the platform is missing something. It is not. The lake is fine. The pipelines are fine. The access model is better than most.

The gap is a staffing shape that almost every organization has:

• The people who understand what the data means are analysts, planners, field supervisors, and engineers of the non-software kind. They know that a meter read flagged E-07 is a comms failure and not a usage anomaly, and that nobody has trusted the service_start_date column since the 2019 billing conversion.
• The people who can build with the data are a small platform team who do not know any of that, and who are already the bottleneck for four other systems.

Bridging that gap is traditionally a hiring problem: put a data engineer between them. That works and it is slow and expensive, and the data engineer still does not know what E-07 means.

This training takes the other route. It teaches the first group to do the work, using an AI command-line tool to close the part of the gap that is genuinely about syntax and tooling — and teaches them the part that no tool closes, which is knowing whether the answer is right.

What a data product is

Through this training, a data product means something narrower than “data someone produced.” It is a dataset or an answer that has all four of these:

1. A named consumer — a person or a team who will do something differently because of it.
2. A definition — what the numbers mean, at what grain, with one owner who settles disputes.
3. A check — something that fails loudly when the output is wrong, before anyone sees it.
4. A service level — how fresh it is, who is responsible when it breaks, and when it retires.

A query someone ran once has none of those. That is not a criticism of ad-hoc queries; most analysis should stay ad-hoc. The distinction matters because the moment somebody else starts depending on your number, all four become your problem whether you planned for them or not.

The most common failure in this work is not a broken pipeline. It is a spreadsheet that quietly became load-bearing.

What you will build

Over six modules you will take one real question at Meridian — which distribution circuits are trending toward an outage we could prevent? — and carry it end to end:

• Module 1 decides what the answer means, who needs it, and how you will know it is right.
• Module 2 profiles what the platform team actually handed you, including what the catalog never recorded.
• Module 3 builds a table that returns the same result every time it runs.
• Module 4 proves it reconciles before anybody sees a number.
• Module 5 serves it to the consumer who asked, in a form that consumer can use.
• Module 6 keeps it true after you move on to something else.

Every module teaches the work and the AI-assisted way of doing it as one workflow, not two. And every module ends by finding what the agent got wrong — because an agent that produces a confident, plausible, incorrect table is the specific hazard this training exists to inoculate you against.

Stop and escalate if you go looking for the lake and cannot find who owns it or what has landed — that inventory is the platform team’s to provide, and asking for it is the first legitimate escalation of this training.

KNOWLEDGE CHECK

Meridian's lake is governed, reconciled, and well secured, and no analyst has produced an answer from it in two years. What does that most strongly indicate?

A

The migration was done badly and the data needs to be re-landed.

B

The platform is missing a service, and buying the right tool would resolve it.

C

The people who understand the data cannot build with it, and the people who can build do not know what it means.

Key takeaway

The hard part of getting value from data is rarely the platform, and Meridian’s two silent years are the proof: a well-run migration can leave you with a governed lake and no answers. What separates a data product from a query is a named consumer, an owned definition, a check that fails loudly, and a service level. Lesson 1.2 starts with the first of those, because everything downstream is shaped by who is waiting for the answer.