Automate a business process and the decisions nobody wrote down move to the system by default, while the accountability stays where it was. The Clinic makes that visible on about the simplest process there is: booking an appointment. It's a decision-placement exercise, not a benchmark. The simulated clinic, 1,000 synthetic patients and an AI scheduling agent, is the specimen, not the result, and its runs have no value on their own. What you leave with is a judgment: who decides each thing, whether anyone chose that, and who answers for it. Ceding a decision isn't the failure. The failure is the one nobody chose.
The walkthrough is five short steps on recorded runs: you watch one change to the agent, guess what it does, see what happened, and decide who made the call.
Then you take it home. What travels isn't the simulation. It's the framework, as a ready-made proof of concept (PoC): the Clinic's process, its declared decisions and the gaps we know about, already written down as a reference architecture package. It proves whether a target stack can hold each decision where you place it. Can the vendor show you the decision, let you override it, and name who answers for it? Your map proposes the placements, and the vendor's evidence settles them. The bench is the reference evidence behind it, and it's public, so you can run it on your own stack too.
Pick the path that fits you. Each one starts the walkthrough with its own recorded change and questions, and each ends the same way: one decision placed, and what it means for the business. The technical paths go one level deeper into how the architecture and the code drive that outcome. The kit is there for anyone who wants to go further.
You start from one recorded change: who gets to say the patient agreed.
You change nothing. You guess what the change does, then see what it did.
You're done when you can say who made that call, and you have the questions to ask a vendor.
You take home those questions. Someone on your team takes the framework to the stack you're weighing.
Start as an executive →You start from a recorded reader swap: Gemma 4 26B against Claude Haiku 5.5, with what each cost.
You change nothing. You compare the recorded readers.
You're done when you can say where a better model helps, and where it can't because of who holds the decision.
You take home the question that decides model spend, and the kit if you want to run your own model.
Start as a practitioner →You start from the same recorded change, read as build against buy.
You change nothing. You place the decision a purchase would move.
You're done when you can say where that decision would land on a vendor's platform, and what to ask for.
You take home the reference package and four steps for mapping it onto a vendor's stack.
Start as an architect →You start from one rule in code changed, and a wrong booking it let through, opened in the commitment inspector.
You change nothing yet. You trace the booking to the rule in code behind it.
You're done when you've traced one surprise to the decision behind it.
You take home the kit, which runs your own change against all 1,000 patients in about 12 seconds.
Start as an engineer →With a decision about a real stack. The site runs the lab once so you can see its shape, and the recorded runs save you the hours if you don't have the hardware. The proof of concept then runs in four steps, and each path goes as far as it needs. First, the reference package. Second, your map of it onto the stack you're weighing, which proposes where each decision lands. Third, the vendor's evidence for each placement, which settles it. Fourth, if you want it, a bench run on your own stack. The package holds the declared decisions and the gaps we know about, not every decision. Finding the rest is part of the work.
Take it home covers each step. The bench has a limit: the simulated patient understands only the reference agent's phrasings, so a free-form agent is tested on that grammar, not on its architecture. The records can describe other architectures, but the reference's results stay limited to this simulation. Pointing the framework at your own business process means writing your own process and its decisions in the same records, and, to bench it, your own patients and scorer. The kit doesn't build those for you.
Every time we automate a process, we expose decisions nobody wrote down. A person at the front desk made them by an unwritten rule. Automate the desk and those decisions go to the system by default, while the accountability stays with the clinic. That gap is where AI projects fail in production.
The lab uses two frameworks to find those decisions. The 4+1 Layer AI Infrastructure Model says where in the stack a decision is made. The Decision Authority Placement Model (DAPM) says who's authorized to make it. Every decision is placed at a boundary: between the clinic and its AI agent, say, or between the clinic and a vendor. It's Retained (a person at the clinic decides), Retained in code (code the clinic controls makes the call on every write, the Deterministic Code in the Loop pattern), Delegated (a model or vendor decides, and the clinic can stop any single decision before it's written) or Ceded (they decide, and the clinic can't). Three questions decide which: can the clinic see the decision, can it override it decision by decision, and can it hold the decider accountable? A no to any of them means the decision was ceded. Rolling a rule back later makes a cession revocable. It doesn't make it a delegation.
None of them is wrong. Ceding a decision is fine when it's a choice you made and wrote down. The failure is the one nobody chose.
I've released the run records with the kit, so you can check any figure here. The runs don't have value on their own. The value is the judgment you draw from them, and the business decision it leads to.
I built the Clinic in a weekend. It has bugs, and it can't reproduce real conversations with the data it has. That's fine, because finding gaps is the lab. Every improvement I've tried exposed another one. A gap you find is a finding, not a defect for me to close. Solving it is yours. The challenges list the ones you can see in the kit as shipped, each with a head start. I decide when a gap in the instrument itself is material enough to fix, because a fix changes what every earlier result can be compared with.
When you've made your own attempt, the worked path shows one route through the lab and what it exposed. It's not the answer. I don't know the answer.
The Clinic grew out of Lab 029, Who decides consent, which measured where the reference agent's decisions sit.
Independence. Self-funded editorial work by The CTO Advisor. Google Cloud is a client, and Gemma is a Google model. Kamiwaza is a client, and appears among the platform examples. These are named here and aren't clients: Anthropic (Claude Haiku), NVIDIA (the DGX hardware), Alibaba Cloud (the Qwen models), TypeSafe (Jev), ServiceNow, Salesforce, CoreWeave, AMD and Apple. No vendor reviewed or shaped these pages before publication.
How the runs were paid for. The Gemma runs used two NVIDIA DGX Sparks The CTO Advisor owns. The Claude Haiku 5.5 runs used the $200 monthly API credit included in Keith Townsend's paid Anthropic plan; Anthropic provided no special funding or project-specific credits. The managed per-token prices shown for Gemma come from third-party listings (OpenRouter and public price trackers), not from Google.
What this is. A simulation: synthetic patients written in code, one reference scheduling agent, a deterministic scorer. It shows how the parts compare here, not how a production clinic would behave. The platform examples are unbenched.