When the Thing That Breaks Isn't Yours to Fix
Modeling cross-plant risk from infrastructure Pawsome depends on but doesn't control — and the deployment cycle a vendor's engineer would run to prove the fix works before Pawsome ever signs.
Written from the seat of the engineer doing the deploying, not the seller closing the deal — pain, a scoped proof, a build-vs-buy technical case, and a handoff — loosely shaped around MEDDIC-style qualification, named below as each one shows up.
Pawsome's 2018–19 acquisition spree left it with sixteen plants across regions — each dependent on a different municipal water system, a different regional grid, a different weather pattern. Nobody had built a system to see the pattern across them until a storm made it obvious. When a single substation failure took out four plants at once, Pawsome's team didn't get one incident. They got four unrelated-looking alerts, three confused phone calls, and one unnecessary site visit before anyone realized it was a single root cause wearing four different faces.
That gap is what brought GuardRAIL — and their Forward Deployed Engineer, Sasha Malamute — to the table. Not a rep with a slide deck. The person who'd actually be embedded on-site, writing the correlation logic against Pawsome's real telemetry.
The Discovery Call
Pain-first technical discovery, not a feature-first pitch
Sasha's first move wasn't a pitch. It was a question: tell me about a time this actually went wrong. Apollo Heeler, GM of Plant Operations, walked her through the February storm — four plants dark within fifteen minutes, forty minutes before anyone had a clear answer for their own boss.
"How long before you had a clear, one-sentence answer for your boss about what was actually happening?"
"...Probably forty minutes."
The Proof — Scoped POC, Built and Run On-Site
Success criteria defined before the deployment runs — no moving goalposts
Instead of a generic demo, Sasha proposed something narrower: deploy GuardRAIL's correlation engine against the actual storm's sensor logs, and agree upfront on what "win" meant — before writing or running a single line of the pipeline.
Success criteria, defined before the POC ran:
- Collapse related alerts into one correctly-attributed incident
- Prove zero false alerts on unaffected plants
- Give Apollo a clear, defensible readout he could take upward
| Without correlation | With correlation |
|---|---|
| 20 separate raw alerts | 1 correlated incident |
| 4 plants read as unrelated problems | 1 shared root cause identified |
| — | 0 false alerts across the other 12 plants |
These numbers come from actually running the pipeline against simulated storm data — not narrative color.
The Objection — Build vs. Buy
The most common objection in this category — met with an engineering answer, not a sales one
The results were good enough to draw Apollo's director, Marguerite, into the room — and the obvious question: why pay a vendor when Anna could probably build this herself?
Sasha had this answer ready before the call ever happened — build-vs-buy is close to universal in this category, and walking in without a response prepared is how a good POC quietly dies in procurement. Her answer split "build it ourselves" into three honest pieces: the initial build, which Anna probably could match; the ongoing maintenance every time infrastructure changes, which is the part teams reliably underestimate; and the pattern library GuardRAIL already has from customers who've lived through storms Pawsome hasn't yet — the one piece that doesn't exist inside Pawsome's four walls at any price.
"Anna could build a version of this — for your sixteen plants, on today's infrastructure, exactly as it is right now. What she can't build as easily is the part that keeps working when things change."
The Close
Arming the champion, not closing the buyer
The final readout wasn't built to convince Apollo. It was built to arm him — one page, plain numbers, ready to walk into his own budget conversation.
"My job today wasn't to convince you. It was to make sure you had what you needed to convince them."
The Actual Deliverable
The POC readout wasn't just numbers on a slide — it was a real status update, generated by Claude off the real incident data, in Sasha's voice:
That's not scripted dialogue. That's the actual output of the pipeline built for this page — generate → correlate → remember → narrate.
What This Doesn't Prove Yet
Scoping honestly — the difference between a working POC and a production deployment
This POC replayed one storm, one region, one dependency type — enough to prove the correlation logic works, not enough to call it production-ready. A real rollout across all sixteen plants would need this running continuously against live telemetry instead of a historical replay, correlation windows tuned per dependency type instead of one fixed number, and integration into whatever escalation and on-call tooling Pawsome already uses — so the incident doesn't just get identified correctly, it reaches the right person, through the right channel, before it's too late to matter.
That's the honest next scope. Knowing the difference between "the POC worked" and "this is production-ready" is itself part of the pitch.
How It's Built
Built as a four-script Python pipeline — generate, correlate, remember, narrate — using the Anthropic API for the dual-audience triage and status-update layer above. This is the part of the role that doesn't show up in a slide: the pipeline that has to actually run against real telemetry before anyone can trust the readout it produces.
A vendor's own churn risk starts here too — an incident poorly communicated is exactly the kind of signal that shows up, three months later, in someone else's retention model.
A Note on AI Assistance
Claude (Anthropic) was used for architecture guidance, conceptual walkthroughs, and code review while building the correlation engine and LLM briefing layer. All design decisions, domain framing, debugging, and implementation are my own work.
AI was used as a collaborative assistant, not a replacement for engineering judgment.