I was consulting with a founder building a lead enrichment pipeline at a small, VC-funded startup where everyone wore three hats and shipped fast.
The pipeline pulled GitHub profiles and matched them to LinkedIn accounts, cross-referencing company pages along the way. The model returned 0.78 confidence on a match.
The model gave us the wrong person. Right company, right first name — wrong human being.
We needed to understand why.
The pushback surprised me. They couldn’t dispute the wrong match, but fixing it would require understanding how the system reached its predictions.
“Let’s rebuild the system. We will do better.”
“We need to hire ML researchers.”
“We just need to keep iterating.”
None of that would explain the failure. We didn’t know what guided the model’s prediction or whether we were feeding it the wrong context.
Could anyone explain why this match was supposedly correct?
Not “the model said 0.78 confidence.” Why 0.78? What did it weigh? What did it consider and reject? What evidence supported the decision?
Nobody could answer that, because the system wasn’t built to answer it. It was enabling us to do the wrong thing.
What they resisted wasn’t slowing down but confronting a harder question: Can we measure and explain why our pipeline produces these results?
The question was uncomfortable because shipping faster wouldn’t fix a visibility problem. “0.78 confidence” was a number, not an explanation.
What Financial Audits Require
After Enron collapsed in 2001, the response wasn’t “we need better accountants.” Sarbanes-Oxley required stronger internal controls and records that auditors could trace.
Even when I Venmo my buddy Brett $23.44 for pizza in Brooklyn, there’s a record. Corporate finance does this at scale: every journal entry traceable to source documents.
"The silent, immeasurable value of well-designed safeguards lies in the scandals they prevent from happening."
AI systems need the same kind of traceability.
What Dashboards Miss
We talk about Evals and Observability like they solve the problem.
Observability tells you what happened—latency, cost, throughput. Evals tell you how often you’re right—perhaps 85% accuracy on a test set.
Neither tells you why any individual decision was made.
Evals don’t explain how to improve the system. They surface the gap—”we’re wrong 15% of the time”—but someone still has to inspect the failures, infer what went wrong, and revise the prompts.
I see this in startups under pressure to ship. Teams track latency, cost, and benchmark accuracy while individual decisions remain opaque.
Admitting that an impressive demo might be confidently wrong is uncomfortable. Shipping the next feature is easier than investigating the last failure.
So we tried something different.
Recording the Decision
After the wrong match, we changed how the pipeline made and recorded decisions.
For that same profile, the new system logged:
Lead Enrichment Pipeline
GitHub → LinkedIn Match · Traced Decision
Software Engineer. Building at Guilder Inc. Passionate about revenge and sword fighting.
Guilder Inc
Guilder Inc
Íñigo Montoya
Íñigo Montoya Fernández
Software Engineer
CTO
Strong name + company match. Role mismatch (Software Engineer → CTO) may reflect recent promotion or outdated GitHub bio. Flagged for human review.
Instead of recording only “0.78 confidence,” the system recorded four candidates, the evidence for and against each one, and the final decision. When the next wrong match happens, we can inspect that record.
The founder asked me later: “How do we know the good matches are actually good?”
You can’t trust the hits if you can’t explain the misses.