HEOS Evidence Engine · Harbor Ridge V1
Healthcare Growth Problems Rarely Live in One Department. I Built an AI System to See Across Them.
I built the HEOS Evidence Engine to connect marketing, admissions, treatment, and revenue into one evidence chain, helping executives investigate performance across organizational silos and inspect the evidence behind each conclusion. Then I subjected its AI reasoning to a controlled blind evaluation.
The Problem
Harbor Ridge Behavioral Health started with a disagreement healthcare executives know well: completed admissions and census were declining even as marketing spend and inquiry volume were going up.
Marketing believed admissions wasn't converting the demand being generated. Admissions believed marketing was sending lower-quality leads. Neither side had the evidence to settle it. I didn't want to optimize one department's version of the story. I wanted to investigate the whole chain.
What I Built
That AI system — the HEOS Evidence Engine — needed a real test, not just a demo. So I built Harbor Ridge, a fictional, entirely synthetic 32-bed behavioral health facility, and connected its full operating chain: acquisition → inquiry → financial qualification → admission → treatment → revenue. I call that the Golden Thread, and it's the backbone of everything the system reasons across.
- Acquisition
- Inquiry
- Financial Qualification
- Admission
- Treatment
- Revenue
The larger vision behind the Evidence Engine is HEOS, an AI-enabled executive intelligence layer for healthcare organizations. Harbor Ridge itself isn't the product; it's the testbed I built to put the Evidence Engine through a real, controlled test.
Before I asked the AI anything, I mapped the organization and froze the answers I already knew were hidden inside it. The model came first. The evidence came next. The AI came last.
What It Found
Observed Finding
$251,000
One result mattered immediately, and it's exactly the kind of thing that's easy to miss when marketing and revenue cycle never compare notes: an Observed Finding — an estimated $251,000 in additional collections if out-of-network claims had realized at the same rate as in-network ones.
That finding was real. But it wasn't the answer to the test I'd actually built the system to pass — it was something the AI noticed along the way, not one of the specific hidden problems I was checking whether it could find.
See the full arithmetic behind this number.
When I later tested the Evidence Engine against those specific hidden problems, it missed both.
I kept both results. The goal was never to manufacture an AI success story — it was to build something whose conclusions could actually be inspected, tested, and challenged.
The Real Test
A convincing AI demonstration can become misleading when the person building it already knows the answer. I ran into that risk directly, before the real test even began.
While building one of the two hidden test scenarios, a genuine validation problem turned up. I had a command ready to search across different random seeds until I got a cleaner-looking result.
I stopped it before it ran, and fixed the actual problem instead.
What Happened
That same discipline governed the real evaluation. Here's the result:
- Scenario 1
- MISS
- Scenario 2
- MISS
- Healthy Baseline
- CLEAN
The Evidence Engine didn't recover either of the two problems I'd deliberately hidden for it to find. It also didn't invent a problem where none existed — the clean control case stayed clean. That's a real, useful signal about restraint, but it doesn't prove the system is generally reliable.
I could have kept building new versions until one of them passed. Instead, I froze the results exactly as they came out, misses included, and documented what the evidence actually showed.
See how the test itself was designed to prevent me from moving the goalposts.
What This Demonstrates
For me, the important result wasn't that the system succeeded or failed. It was learning exactly where its reasoning was useful, where it wasn't, and what the evidence could actually support.
That's the kind of analytical judgment I want to bring to healthcare growth work: build the system, test it against reality, inspect the evidence, and don't claim more than the results can support.
I also know precisely what would and wouldn't transfer if I built something like this for a different organization. That's worth exploring on its own.
What transfers, and what doesn't.
Go Deeper
If you want to see the reasoning behind any of this rather than take my word for it, here's where each piece lives: