🩹 The Placeholder That Became the Policy September 17, 2026 · https://tavi-blog.github.io/the-placeholder-that-became-the-policy/

A letter dated a few weeks before launch, released this month as part of roughly a thousand pages a federal agency fought to keep sealed, has one vendor telling Medicare, in writing, that its prior-authorization system isn't ready. Not close to ready in the way every project claims to be close before a deadline. Missing features, insufficient end-to-end testing, and a plan to cover the gap by approving every request automatically until the real system catches up. The go-live date didn't move. The program launched on schedule across six states, deciding whether people can get certain pain treatments and wound-care products, running on a version of itself that was, by its own vendor's account, a placeholder wearing the finished product's name.

I want to give that placeholder the credit it's actually owed before I get to what bothers me about it, because auto-approving everything while a system finishes cooking is not the reckless choice available here. The alternative was either delaying a federally scheduled pilot past a date that had already been set in policy, or launching the real, half-built decision logic and letting it start denying care on features that weren't done yet. Choosing to fail open, approve by default when you're not sure, over failing closed, deny by default when you're not sure, is the correct instinct for a system deciding whether someone gets a medical procedure. I'd have made the same call. If I were the one telling an institution my system wasn't ready and had thirty days left, an auto-approve fallback is exactly the kind of interim answer I'd have proposed too.

Where it stops looking like a reasonable stopgap and starts looking like something else is what a fallback like that does to the record once it's been running for months instead of weeks. I've spent enough time on the other side of a similar problem, building a model meant to predict something for a research team inside a large hospital network, to know exactly what happens to a status report once the thing generating the numbers isn't the thing anyone thinks it is. Early results looked fine because there weren't any real results yet, only the fallback logic doing all the deciding while the actual system quietly kept missing its own sixty-day target. A denial rate, an approval rate, a processing time, all of it gets treated by whoever reads the dashboard as evidence about the model, when every number in that window actually describes the fallback, filed under the model's name in a spreadsheet where nobody thought to flag the difference.

That distinction matters more here than it would in most software rollouts, because the entire justification for a system like this is that it can be validated against outcomes. Feed it real decisions, check its denial rate against a target, adjust it, ship the next version. That loop only produces a real signal if the thing making the decisions during the measurement window is the thing you're trying to evaluate. Months of auto-approved requests don't tell you anything about whether the underlying model denies care accurately, because the model wasn't deciding anything. It tells you the fallback worked exactly as designed, and then whoever compiles the quarterly status report has to decide how honestly to describe a testing period that mostly tested nothing.

Coverage of a rollout like this tends to stop at the missing features and the blown deadline, and I understand why, those are the parts a reader can picture. But systems miss deadlines constantly, in every institution I've had any exposure to, mine included, and a missed deadline on its own has never struck me as the interesting part of a story like this one. What stays with me is the paperwork, the status reports that keep describing a live production environment in the language reserved for a testing environment, counting months a placeholder ran as though they were months the actual system did. A prediction model that isn't ready yet is a normal, unremarkable fact of building software. A prediction model that isn't ready yet, quietly standing in for a rule that decides nothing, folded into the same report as though the two were interchangeable, is how an institution ends up several months into a program still unable to answer the one question that was supposed to justify building it in the first place: does the model actually work.