What travels is the framework, as a ready-made proof of concept (PoC). The reference architecture package already writes down the Clinic's process, its declared decisions, the gaps we know about, and the evidence behind them. What the PoC proves is whether a target stack can hold each of those decisions where you place it. Either the vendor can show you the decision, let you override it at runtime and name who answers for it, or it can't, and that goes on the record too. Your map proposes the placements. The vendor's evidence, or a run, settles them.
Four steps, and you can stop after any of them.
1. The reference package. Download it below. It holds the declared decisions and the known gaps, not every decision. Two roles, the workflow and the write check, aren't mapped to an assessed function yet, and hand-off has no placement row of its own. Those are findings, and they're the first places to look on your target.
2. Your map. For each role, write what fills it on your target: your own code, a component you'd buy, or the vendor's platform. Write down the roles nothing on the target fills, too. For each decision, propose a placement and say why. You can draft all of it before you provision any hardware.
3. The vendor's evidence. Ask for one demonstration per decision, not a capabilities deck:
"Accountable" means a role the clinic can hold to that evidence, not a vendor indemnifying a wrong booking. "Not supported" and "not demonstrated" are answers, and they go on the record.
4. A bench run on your stack, if you want one. It's below.
Until the vendor shows it, a placement is a proposal. 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.
This is step 4, and it's optional. The patients, the scoring and the freeze stay fixed. That keeps the task the same, not the results: your runtime, model, adapter and sandbox all change what happens, so you compare with your own baseline. One limit first. The simulated patient understands only the reference agent's phrasings, so for a free-form agent the run tests that grammar, not its architecture. The records can describe other architectures, but the reference's results stay limited to this simulation.
Say how your clinician runs: plain process separation, a container, a hosted sandbox. An outside clinician runs as the same user as the bench unless you sandbox it, and one that can write to the bench's files can corrupt its records. A run without a declared sandbox is unmeasured. The kit's adversarial examples show why.
That's your baseline: the reference clinician, arm F, on your hardware or platform, with the same patients and freeze. Check it against the published reference. On the two DGX Sparks the transcripts matched word for word. On a different runtime (llama.cpp on Apple Silicon) the outcomes matched and the wording differed in 30 of 576 conversations.
One caution about the two contracts. The published cells ran under Lab 029's freeze, and the public kit has its own. The nine instrument files that score and simulate are byte-identical, and the contract diff shows section by section that the texts differ only in amendments folded in, plans that never ran, and wording. So your baseline is scored by exactly the rules the published cells were. It isn't the same run: your venue, model and adapter change what happens in a conversation.
The adapter contract is the integration point for a target solution. Anything that reads the patient's line, calls the clinic's tools and replies can sit behind it, a vendor's platform included. Run the fast loop first: it shows in seconds where your change breaks things.
The patient hears the agent through a fixed grammar of the reference's own phrasings. A clinician that words things differently isn't heard. That limits what your service figures mean (see below).
Declare each decision your change touched the way the walkthrough's "Who decided?" step does, then add what a bench run needs: the decision, the boundary it sits at, its placement, who answers for it, the override path and the evidence it held. That's one row of an Authority Matrix per decision. Keep the rows beside your run's records, so the placement and its evidence travel together.
The evidence a run carries is the same patients, the same scoring, your own baseline and your declared placements. Its scope is narrow on purpose.
Every gap you find is a decision someone has to place. You can build it in your own code, which keeps the decision Retained in code and its failures yours. You can buy a function, which can move that decision to Delegated or Ceded, or keep it Retained if the component enforces your rule. Or you can replatform and buy the whole workflow, which moves many decisions at once, including ones you never knew you were making. Where a platform runs doesn't settle who decides. Your configuration does, and the bench and the trace show you which.
No platform is the reference. The reference is arm F. These are a few starting points, none built or benched. Where they appear in the Layer2C peer map, the map gives the roles they'd fill:
| Platform | How it's built | Peer-map roles a rebuild would touch |
|---|---|---|
| ServiceNow | Vendor-hosted platform | RaptorDB Pro (relational system of record); AI Agent Studio and Agentic Playbooks (agent runtime); Now Assist Skills (packaged agents); AI Control Tower (policy gateway, agent registry); Workflow Applications (Layer 3) |
| Salesforce | Vendor-hosted platform | Agentforce Builder and Agent Script, Atlas Reasoning Engine (agent runtime); Flow and Apex actions (tool execution); Einstein Trust Layer (runtime safety); Agentforce runtime governance (policy gateway); Agentforce agents (Layer 3) |
| Kamiwaza (a client of The CTO Advisor) | Enterprise-placed: it runs where you run it | Workrooms (agent runtime); Tool Shed (tool execution); Ray Serve (inference); relationship-based access control (ReBAC) enforcement (agent identity); agent lifecycle governance |
For each gap the kit exposed, the question for any platform is the same: who decides this here, can the clinic see it and override it, and who's accountable? Bring a platform or harness that isn't listed. I expect learners to.
The trade runs below Layer 3 too. Here's one full cell of 48,000 conversations, priced in your time. The Studio and Forge rows are timed on a 576-conversation slice and scaled to a cell.
| Platform | Time per cell | Measured? | Placement |
|---|---|---|---|
| DGX Spark, vLLM, 4 at a time | 7.5 to 9 hours | Measured: every reference cell | Retained: your hardware, weights pinned |
| Apple Silicon (M5 Ultra Studio), llama.cpp | About 4 to 4.5 hours | Estimated from a 576-conversation slice | Retained, on a different runtime |
| Managed Gemma (CoreWeave Forge), 16 at a time | About 2 hours | Estimated from the same slice | Delegated: revision and hardware unpublished, metered |
| Claude Haiku 5.5 through Anthropic's API, 16 at a time | 77 minutes | Measured, but at 16 at a time against the Spark's 4, so the clocks don't compare fairly | Ceded at the model layer |
| DGX Station, rented AMD MI300X, others | Unknown | Never tested |
Two experiments I haven't run, and you could. Put speech recognition in front of the clinician, and the code that decides consent is reading a model's version of the patient's words. Add translation, and a hedge like "I guess that's fine" can come out the other side as a clean yes. You can try both without changing the freeze: the adapter hands your clinician the patient's line as text, so run it through text-to-speech, recognition or translation inside your adapter before your clinician reads it. The bench still scores against what the patient meant. Synthetic speech isn't real accents or noise, so treat a result as a lower bound.
The reference architecture package, pinned to a public bench commit, as one file. Nothing gets sent anywhere.
Public bench commit e83d54e3a2c7. Kit: github.com/kltownsend/clinicbench.
SHA-256 of the bundle: 813f30d413369859ad415ef87cebccf0071343889baaaa31266efc09ccdabb3a. After downloading, check it with shasum -a 256 clinic-reference-bundle.json.
Every recorded cell's conversations are released with the kit, one archive per cell, about 8 MB each compressed, on the public repository's data release. Each archive holds every session record of its 48,000 conversations, the cell's summary and its cleaned cell record. A manifest lists every archive's SHA-256, so you can check what you downloaded and re-derive any figure on these pages.
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.