The setup: one sentence of policy, the industrialized review behind it, and why neither the expert workforce nor the traditional software lifecycle can keep up.
the setup · why this playbook exists
Start with one sentence of policy.
The kind your coders apply thirty times a day, in minutes, from memory:
"A problem-oriented E/M service is separately reimbursable on the same date of service as a preventive E/M service when the problem addressed is significant and separately identifiable, supported by modifier 25."
It reads simple. It isn't. Hidden inside it are six decisions that must be made in order — and one requirement almost nobody sees coming: the two visits don't have to arrive on the same claim, so nothing can even begin until the patient and the encounter are matched across claims. Federal audits have found a third or more of these claims improperly paid, and the OIG's current work plan names modifier 25 an active enforcement target.
And this is one sentence, from one policy, in one corner of the revenue cycle. There are hundreds like it — and on each one, the payer's side has been industrializing: edits, analytics, and audit programs built faster than a provider can even learn the rules exist.
Neither answer you have can keep up. The expert workforce runs on minutes and memory — and memory was never the right tool for tens of thousands of classifications and compounding criteria. The traditional software lifecycle runs on quarters and a backlog — the build joins a hundred other high-need projects and waits.
So the leakage continues — the same four families this site opened with: denials, undercoding, downgraded levels of care, readmissions. The money, and the care that could've gone better.
Work this precise, this governed, and this contested has been nearly unapproachable — no workforce scales to it, and no traditional build cycle reaches it in time. That's what this playbook exists to change. Prescriptive AI puts the build in your domain experts' hands, with AI working beside them at every step — so a workflow like this one gets built, tested, refined, and into operation in days, not months. The pages ahead show you exactly how, one method at a time. Walk them and decide for yourself.
The discipline: Applied AI has structure — methods, techniques, tactics — and the same weave repeats at every scale.
00 · the discipline
Applied AI is a discipline. It has a structure.
If you came down through the understanding layer, you arrive holding a conclusion: healthcare's precision work needs Prescriptive AI — properties engineered into how the work runs, not bolted on after. This page is the other half: the methodology that builds it. Nobody else is operating from one — not because it's secret, but because nobody has done the work to put structure under the words. Here's the structure.
What we run is a tapestry: six engineering methods, each carrying named techniques, each technique carrying named tactics — the specific moves, with the reason each one exists and the failure it prevents. The weave repeats at every scale, from the whole methodology down to a single workflow in production.
Methods
The six engineering layers. Each one owns a stage of the journey and hands the next one exactly what it needs.
Techniques
The named steps inside each method, run in order. Each takes the raw material one step closer to buildable.
Tactics
The specific moves inside each technique — what to do, why it matters, and the failure it exists to prevent.
The model supplies cognition. It never supplies authority, and it never supplies control flow.
Reading, judging, classifying, narrating — that's the model's job. The answer lives in an authority you supply. The sequence is engineered in advance. Every tenet below is that one rule, applied.
And AI is used twice. It builds the workflow — a model working beside your domain expert to unfold the policy, find every decision, and manufacture the parts — and it works inside the workflow, only where judgment is truly needed. Some of the best Applied AI solutions run mostly as plain code: the thinking was applied while building, then frozen where it can't drift. Reaching for AI isn't the discipline. Knowing where to apply it is.
It's also why this playbook isn't project planning in disguise. Read as paper, eleven stations look like a quarter of traditional lifecycle — the build that sits in a backlog behind a hundred other projects. With AI doing the building beside your expert, it stands up in days, not months: the methodology is the acceleration, not the overhead.
Opportunity Engineering
Pick the right workflow, and read the infrastructure floor it needs, before a dollar moves.
Workflow Engineering
Unfold one sentence of policy into every decision hiding inside it.
Prompt Engineering
Decide, decision by decision, whether the model even deserves the job — then manufacture its instruction instead of writing it.
Context Engineering
Build the authority the AI answers to, and keep it true as code sets turn over.
Orchestration Engineering
Run the team without ever asking the agents to plan their own work.
Output Engineering
Get determinations that arrive with their defense already attached.
What you leave with today: the map, the vocabulary, the one rule everything derives from — and the case from the top of the page, which every method ahead picks up at its own altitude until you've watched it become a governed, evidenced workflow. And something scarcer: grounded hope that the cognitive work behind all that compounded cost and constrained care can finally be scaled.
Coming next: how to pick your first workflow — and why the question almost everyone asks first is the wrong one.
Method one: Opportunity Engineering — deciding where a build pays before anything is built.
01 · opportunity engineering
Decide where the build pays — before anything is built.
Every organization has more cognitive-heavy workflows than it can optimize. Opportunity Engineering is how you choose: find the work where judgment is the constraint, capture what governs it, and read the floor it will need to stand on — before a dollar is committed.
the autonomous instinct
Start with the technology and hunt for somewhere impressive to point it.
the prescriptive move
Start with the leak, weigh the judgment inside it, and price the fix before committing.
Don't hunt for the slowest workflow. Hunt for the one where judgment doesn't scale.
Everyone starts with "where do we lose the most time" — the wrong question, because thirty years of software already took the mechanical work. The workflows still run by hand today are manual because they turn on judgment, and judgment is the thing that has never scaled: you can't copy your best coder or your best denials analyst. That's the work this technology was built for, and it's how you pick.
Before you price the AI, count what was never written down.
"You just know after a while" — that sentence, from your best analyst, is the sound of criteria nobody ever wrote down. Write them down and they become lookups: exact, cheap, incapable of drifting. What's left is the true thinking work, usually far smaller than the workflow looked — and that smaller piece is what you're actually deciding to build.
The demo is one agent. The workflow never is.
Most vendors show a single AI doing a single impressive thing. No real workflow runs that way — production takes a team of them, plus everything nobody demos: whatever runs the handoffs, the references it decides by, the records that prove what happened. Price that, not the demo, or discover it after you've committed.
The workflow you pick decides the floor you'll need.
The floor is the infrastructure — the AI tooling and technology the workflow runs on. Nobody prices it for you. One assistant looking things up needs almost none. Put more agents on the job and give them more to do, and the tooling and technology grow with them: a place to run, references kept current, a queue for human review, a record of every action. Two workflows that look alike from the outside can need very different floors — read what yours demands while changing your mind is still free.
Targets
because the wrong pick wastes the whole build: find the work where judgment, not volume, is the constraint
Topic
because an AI-assisted workflow cannot be built past this point without this capture — everything the build does traces back to what you write down here
Triggers
because the work has to start from something real — and how messy that something is sets how hard the thinking will be
Telemetry
because an AI workflow doesn't run on air — before you commit, read the floor it will need to stand on
the thread · one workflow, carried through the playbook One real workflow travels this whole page, picked up by each method at its own altitude. Open it to see how it gets picked. open the case ▾close the case ▴
The candidate
Office visits where the provider bills two E/M services on the same day — a routine physical, and a real problem addressed in the same visit. The payer's policy allows both to be paid. It rarely happens cleanly.
The cognitive challengetargets
No coder has the problem-versus-preventive classification of every E/M memorized — nobody holds tens of thousands of code classifications in their head. Weighing diagnosis alignment, catching a modifier 25 on the wrong line, thirty encounters a day: this is judgment running on memory and minutes, and memory was never the right tool.
The costtargets
Denials, post-payment recoupments, modifier-25 audits — and the quiet version: coders dropping the second E/M rather than risk it, leaving earned revenue unbilled.
What governs the worktopic
The payer's dual-E/M policy, the modifier-25 rules, your own coding SOP — gathered now, because everything built later answers to them.
The source datatriggers
A claim carrying more than one E/M line, and the medical record behind it — one arrives structured, the other is exactly the messy source where the judgment hides. And the two E/Ms may not even arrive on the same claim: before any determination can begin, the patient and the encounter must be matched across them — infrastructure nobody budgets for standing at the policy.
The floortelemetry
No single-assistant job: a team of workers — some will run as plain code, some as a model; that verdict comes later, and it's made honestly — plus references kept current as code sets turn over, a review queue while trust is earned, and a record of every determination.
Why this fight
The payer already industrialized their side — an analytic reviews every multi-E/M claim they receive, and federal auditors have made this modifier an active enforcement target. Your side runs on minutes and memory. Workflows where the other side has automated and yours hasn't are the top of the funnel — the asymmetry is the opportunity.
What leaves this method: a chosen workflow, the documents that govern it, the sources that feed it, and an honest read of what it will take — which is exactly what the next method takes apart.
Coming next: that governing policy reads as one sentence. Workflow Engineering opens it up — and six decisions fall out that nobody budgeted for.
Method two: Workflow Engineering — taking the workflow apart until every decision has a name, then arranging the decisions into a tree.
02 · workflow engineering
In hand from Opportunity Engineering: a chosen workflow, what governs it, what feeds it, and an honest read of the floor it needs.
Take the workflow apart until every decision has a name.
A workflow described in a policy document or an expert's head isn't something you can build from. It's full of unstated assumptions, buried decisions, and judgment calls no one ever wrote down. Workflow Engineering turns that raw knowledge into something precise enough to build: the exact decisions the work turns on, arranged into an ordered tree.
the autonomous instinct
Hand the model the goal and let it find its own path through the work.
the prescriptive move
Decompose the work into named decisions, then lay the path they run in — before anything runs.
The workflow you can build from doesn't exist yet.
The policy describes how the work should go. The expert carries the rest in their head. The failures live in the gap between them — and the build starts by closing it.
Every soft word in a policy is a decision nobody made.
"Appropriate." "Significant." "As needed." Each one is a place where a person quietly supplies judgment and a machine quietly fails. We pull them out and make them answerable. And even the hard words only state the final allowed criteria — a policy never unfolds the information you must collect and the decisions you must make to apply it. That unfolding is this method's work.
Questions are buildable. Narrative isn't.
A decision written as a clear question can be assigned, equipped, and tested. A paragraph about the work can't. The whole method moves the workflow from the second form to the first.
A list of decisions is parts, not a workflow.
Some decisions settle a whole case by themselves. Some can't be made until another decision is made first. Some that look separate are the same question twice. Until the order and the dependencies are settled — and every possible outcome has somewhere to go — nothing can run.
Translate
because you can't build from what lives half in a policy and half in an expert's head
Tree
because a pile of decisions isn't a workflow until order, dependency, and exit are settled
the thread · the same workflow, unfolded One sentence of policy, opened up — and six decisions fall out. Open it to watch the unfold. open the case ▾close the case ▴
Here's the dual-E/M policy requirement the way it actually arrives — one sentence.
"A problem-oriented E/M service is separately reimbursable on the same date of service as a preventive E/M service when the problem addressed is significant and separately identifiable, supported by modifier 25."
The six decisions hiding inside it:
- Does this claim carry the same provider, the same date of service, and more than one E/M line — the pattern that triggers dual E/M review?
- Does the claim contain exactly one problem-oriented E/M service and exactly one preventive E/M service, with all E/M lines classified to a recognized type?
- Does the problem-oriented E/M service line have at least one ICD-10 diagnostic code linked to it?
- Do the ICD-10 diagnostic codes align with the claimed service types — active disease or symptom codes present on the problem-oriented line, and no routine or screening-only codes that would indicate preventive care on that line?
- Is modifier 25 attached to the problem-oriented E/M service line — not absent from the claim, and not misattached to the preventive line?
- Do all exception criteria pass — valid qualifying combination, diagnostic code support, and correctly placed modifier 25 — authorizing dual E/M reimbursement?
Six decisions behind one sentence of policy. That's why one decision per node: ask any engine — a model, a person, a black-box analytic — to leap to the final answer in one step and you get an answer with no trail: no way to see which criteria it weighed, what evidence carried each one, where it silently skipped. Walk it node by node and the determination compounds, each step evidenced before the next runs. And the unfair fight the last method named — the payer's analytic against a coder's minutes and memory — this is how it evens.
What leaves this method: the workflow made explicit — every decision named, ordered, and traceable to what demanded it — ready to be equipped with an engine and an authority. That is the next method's job.
Coming next: every decision needs an engine — and the first question of Prompt Engineering is whether a Gen AI model deserves the job at all.
Method three: Prompt Engineering — deciding for each decision whether a computer or a model does it, naming the work, and manufacturing the prompt.
03 · prompt engineering
In hand from Workflow Engineering: the workflow made explicit — every decision named, ordered, and traceable to what demanded it.
The prompt is manufactured. Not written.
Prompt Engineering here runs on a conviction: every node gets an assistant — an agent built for that one decision. Some agents run on a Gen AI engine, some on a code engine, and the choice is made on evidence, node by node. But both engines get the same thing: one authored instruction, engineered through the identical discipline — and only at the end rendered in the engine's language, as a prompt for the LLM or as code for the computer.
the autonomous instinct
Write clever instructions, point a capable model at the whole job, and iterate on vibes.
the prescriptive move
Give every node its agent, decide each engine on the evidence, name the specialist — and manufacture one instruction for all of it from parts the methodology already produced.
Every node gets an agent — and every agent gets an instruction.
This is the conviction the method runs on. Each node in the tree is worked by its own assistant, purpose-built for that one decision. Some run on a Gen AI engine, some on a code engine — but both are authored through the identical instruction discipline, one methodology for every node. Only at the end is the instruction rendered in its engine's language: a prompt for the LLM, code for the computer. The engine changes what the instruction is written in. It never changes how the instruction was made.
The engine is a choice — and much of the workflow shouldn't run on an LLM.
Nobody selling AI will tell you this. Every decision is tested for real thinking — reading, weighing, judging, narrating — and where none is required, the agent runs on the code engine: cheaper, faster, and incapable of making things up. Why pay Gen AI prices for a determination plain code renders perfectly? The LLM is reserved for the work that needs a mind.
The agent is a specialist, hired by name.
Finding the structure in a record, checking work against a standard, matching items to a reference, writing the finding in plain language — these are different jobs, and each one has a name here: Analyst, Auditor, Assigner, Author, and eleven more. The node's work picks its specialist, and the name carries a persona — the strengths that kind of work demands, and the disciplines that keep them honest. Leave the job unnamed and you've hired a generalist for specialist work.
The prompt is a standard structure. Your workflow is injected into it.
Eight sections, proven across years of production prompting and never rewritten per node — who the agent is, its single job, its inputs, its specialist strengths, its steps in order, its priorities when goals collide, its output contract, and the attestation it must open with. Built into that structure are injection points waiting for exactly what the earlier methods produced: the node's decision from the Tree, the rules it applies, the persona Type assigned. Fully personalized down to the detail. Never individually authored. Optimized out of the gate.
A prompt that rewrites itself is a prompt you can't defend.
Autonomous patterns celebrate instructions that update themselves as they learn. This method runs the opposite way: woven through every prompt are authored tactics that suppress an LLM's adverse tendencies rather than free them — report an absence instead of inventing a value, bind every claim to evidence, render the same decision on the same facts every time. And every instruction is versioned, on the record — so when the auditor asks what made this determination in March, you produce it.
Type
because paying LLM prices for a deterministic decision buys cost, latency, and risk — and nothing else
Assignerdecision 04's hire — matches what it reads to a governed reference and assigns the classification the evidence supports
Authordecision 06's hire — writes the finding in plain language, every claim bound to cited evidence
Triage
because the prompt is manufactured — a proven structure, injected with your engineered workflow — never written from scratch
the thread · the six decisions, given their engines How many of our six decisions actually need a Gen AI model? The honest verdict. Open it. open the case ▾close the case ▴
The same six decisions from the unfold — now each one given its engine, with the reason why.
01 · Same provider, same date, more than one E/M line?code · deterministic
The pattern that triggers dual E/M review — read straight off structured claim fields. No judgment involved.
02 · Exactly one problem-oriented and one preventive E/M?code · deterministic
Every line classified to a recognized type — across tens of thousands of codes no coder could memorize. The judgment was made once at build time and frozen into a reference; at runtime it's match and carry.
03 · At least one diagnosis linked to the problem-oriented line?code · deterministic
A structure check on the claim itself.
04 · Do the diagnoses align with the claimed service types?LLM · reads & weighsAssigner
Active disease or symptom codes on the problem line, and no routine or screening-only codes betraying it — reading and weighing evidence against criteria, the cognitive work an LLM exists for. Held to its reference table, never its memory.
05 · Modifier 25 attached — and to the right line?code · deterministic
Not absent from the claim, not misattached to the preventive line. A placement check.
06 · Do all exception criteria pass, authorizing dual E/M reimbursement?code · deterministic verdict + LLM · narrates evidenceAuthor
The verdict compiles deterministically from the five above. Then the LLM does the one thing left that needs a mind: it reads the record and narrates the evidence — the closing act you'll see in Output Engineering.
Four of six deterministic, one cognitive, one both. The market would call that a disappointing use of AI. It's the opposite — the AI was everywhere at build time: unfolding the policy, proposing the classifications, manufacturing every instruction. What's left for the model at runtime is exactly the work only judgment can do. The discipline was never how much LLM you use. It's how precisely you place it.
What leaves this method: every node with its agent — the engine decided on the evidence, the specialist named, and one manufactured, versioned instruction apiece, rendered as a prompt or as code.
Coming next: an instruction is half a node's equipment. Context Engineering builds the authority it decides by — and keeps it true as the world moves.
Method four: Context Engineering — supplying each node the authority it decides by, and keeping that authority current.
04 · context engineering
In hand from Prompt Engineering: every node typed — its engine decided on the evidence, its instruction manufactured from parts.
The model brings the thinking. You bring the authority.
A defensible determination can't rest on what a model happens to remember — or on how it happens to apply it today. Context Engineering is three jobs in one method: discipline the application, so the same rule reads the same way every time; discover and author the authority, including the rules no one ever published; and keep it true as the code sets and policies move. Every answer traces to a reference you supplied and can show.
the autonomous instinct
Trust the model's training to know the codes, the rules, and the policy — and how to apply them.
the prescriptive move
Supply the authority as a governed reference, hold the model to it, and maintain it like the asset it is.
The model knows the rule. Its wiring erodes the applying.
Much of the time the model genuinely knows the codes, the rules, the policy — it has read more of them than any person alive. The failure isn't knowledge. It's documented tendencies that bend the applying: it concludes before the whole record is read, recalls the gist of a rule but not your payer's edition, blends five payers' versions into a composite that belongs to none, sees what's present and misses what's absent, and gives different answers to the same facts. In most work that erosion is a rounding error. In precision work — the same determination for the same facts, the thousandth time as the first — it's the whole game. Consistency has to be supplied from outside the model. That's this method.
"If you must hand the model the rules, why use a model at all?"
Fair question — twenty years of payer edits prove that where a rule can be checked against claim fields, plain code wins. But watch what the payer does next. When the claim alone can't justify a denial, they don't run another edit — they request the medical record. That request is the industry's own admission: past this line, the work is cognitive. Reading the record. Picking the facts that matter. Mapping them to the rule. Weighing whether the evidence is enough. A standalone data point and a rule can't do it — that's why the record has to travel. It's also exactly the work the model is for, and the rules you supply are what keep it honest doing it.
You can't reference a rule you don't know exists.
The payer authored a policy, published it quietly, and has been screening every one of your claims against it — while nobody on your side knew there was a standard to capture. That's the reality of published-but-scattered rules: the audit arrives against criteria you never assembled. So the first context job isn't building a reference. It's discovery — using applied AI in the build to identify which rule sets the workflow is actually being graded against, before a single node runs.
Some rules you'll be audited against were never written by anyone.
There is no published table classifying each of 70,000 diagnosis codes as problem or preventive — it lives, approximately, in coders' heads. When the rule set doesn't exist, you author it: the LLM proposes at full coverage, your expert certifies, and every row carries its written basis. Authored that way, the reference becomes defensible — when the payer's rule differs from yours, yours survives scrutiny, because credibility is a property of the method. And it becomes the asset: your experts' judgment, encoded, surviving every model swap.
A reference nobody maintains is a rule that quietly expires.
Code sets turn over every year and payer policies move without notice — and a lookup table still carrying last year's retired code is a denial waiting to be written. Currency is an operation with an owner and a schedule, not an assumption — and when a rule changes, you edit the rule, not the model.
Tables
because every node that applies a rule named the reference it needs — some published, some scattered across payers, some existing nowhere until you build them
The Library
because code sets turn over every year — and a reference that quietly expires writes denials
the thread · the authority this case runs on Two tables the six decisions named — including one that exists nowhere else. Open it. open the case ▾close the case ▴
The table nobody publishes
Decision 02 needs every E/M code classified problem-oriented or preventive. CPT doesn't publish that table; it lives, approximately, in coders' heads. Here it gets built: an LLM proposes the classifications, your expert certifies them, and the judgment freezes into rows — classified once, applied identically forever.
| code | classification | description |
|---|---|---|
| 99213 | PROBLEM_ORIENTED | Office visit, established patient, low complexity |
| 99395 | PREVENTIVE | Periodic comprehensive preventive exam, established patient |
The table that guards decision 04
Which diagnosis codes are routine or screening-only — the ones that betray a preventive visit riding a problem line. Same build: proposed by the LLM, certified by the expert, frozen.
| code | classification | description |
|---|---|---|
| I10 | PROBLEM · active disease | Essential hypertension |
| R07.9 | PROBLEM · symptom | Chest pain, unspecified |
| Z12.11 | PREVENTIVE · screening | Screening for colon cancer |
That last row is the trap: Z12.11 riding a problem-oriented line is exactly the betrayal decision 04 catches — and exactly the kind a person misses at volume.
And when the code sets turn over
Both tables diff against the new year's source — new, retired, reactivated — and any row still carrying a retired code raises its own flag. The authority stays true without anyone remembering to check.
What leaves this method: every reference built, tested, keyed to its governed master, and put on a maintenance cadence — the authority each determination will trace to.
Coming next: the parts become a team. Orchestration Engineering runs the handoffs — without asking the agents to.
Method five: Orchestration Engineering — governing the handoffs between agents rather than letting agents coordinate themselves.
05 · orchestration engineering
In hand from Context Engineering: every node equipped with the authority it decides by, built and kept true.
Orchestration governs the handoffs. It doesn't ask the agents to.
The market's orchestration lets agents plan their own work and negotiate their own handoffs. Ours reads the sequence from the tree. Every agent is one node's declared configuration. The runtime assembles it, runs it, and dispatches the result — and the routing was decided at design time, not by the machine at run time.
the autonomous instinct
Spin up a team of agents and let them decide who does what next.
the prescriptive move
One node, one agent, one declared package — executed in an order the tree already settled.
The path is decided before the run.
The write-ups celebrate agents that plan their own steps and negotiate who goes next. But a plan made at run time is a different plan every run — and an emergent order is an unauditable path. Here the sequence is read from the tree, every exit was declared at design, and every case walks the identical route. What looks like the machine choosing is the tree executing — which is why the route can be reproduced, and why the determination can be defended.
"Done" is declared, not felt — and a failed check earns a human, not a retry.
The loop pattern runs until the job looks done, self-auditing and retrying along the way. Iterate-until-good is how errors learn to look like answers — each pass polishes the output until it passes the check, not until it's right. Here, done is a contract the output met. And when a determination can't be made cleanly, the line stops: the case routes to a person — recorded, queued, and owned — not around a loop until something plausible emerges.
An agent is a configuration, not an employee.
It comes into being when its node's package is declared — inputs, references, prompt, outputs, routing. No shelf of ready-made agents doing approximately the right thing. The configuration is the agent, and nobody joins the team at run time.
Orchestration is a delivery service, not a manager.
The market's orchestrator thinks — planning, delegating, spawning helpers. Ours delivers. The right inputs to each agent at its turn; a parent's output prepped, placed, and provided as its child's input; exactly the context each job needs; the next agent triggered by the completion of the one it depends on. End-to-end automation with zero decisions made by the machinery running it. The agents do the work. The orchestration does the logistics.
The run is rendered for a person to certify.
Autonomous orchestration optimizes for finishing without you — the work disappears into a loop and an answer emerges. Ours optimizes for you being able to certify it: every agent's increment surfaced as it lands, its evidence front and center, the determination compounding in view, every verdict written as a row. The trail isn't a byproduct of the run. It's a deliverable of it.
Team
because the team was designed stage by stage — here it's confirmed, not invented
Tower
because the run is where trust is won — governed, watched, on the record
the thread · the case, running One claim walks the six nodes — including the moment it needs a person. Open it. open the case ▾close the case ▴
Before node one
The two visits arrived on separate claims. The floor did its quiet work first: one patient, one encounter, matched — or nothing downstream can run.
The walk
- 01Reads the trigger pattern — the case enters reviewcode
- 02Matches both codes against the classification tablecode
- 03Finds the linked diagnosiscode
- 04Reads the diagnoses against the service types, held to its table, and deposits its finding with the codes that carried itllm
- 05Checks the modifier's placementcode
- 06Compiles the verdict, then narrates the evidencecode + llm
One pass of the team, the engines toggling node by node — code to LLM and back.
Agent team execution cost
A code node costs effectively nothing — fractions of a cent of compute. An LLM node costs real money — whole cents per call, scaling with the length of what it reads. Call it a hundred-fold difference per node, and run the two builds side by side:
| build | engines per claim | llm calls × 1,000 claims |
|---|---|---|
| All-LLM | 6 × LLM | 6,000 paid reads — plus 6,000 chances to drift |
| Hybrid | 1–code · 2–code · 3–code · 4–LLM · 5–code · 6–both | ≈1,200 paid reads — the LLM only where a mind is needed |
Same thousand determinations, roughly eighty percent fewer LLM calls — and the point isn't just the bill. Every LLM call you didn't make is also a variance you didn't invite and an invention you didn't risk. The hybrid isn't the budget version of the all-LLM build. It's the more correct one, and it costs a fifth as much.
When it can't decide
A code the table doesn't hold, an alignment the record can't support — the case doesn't loop until something plausible emerges. It routes to your coder: recorded, queued, owned. The machine never guessed. It asked.
What leaves this method: the workflow running as an agent team — every handoff governed, every exit declared in advance, a person summoned the moment a determination can't be made cleanly.
Coming next: what every stage has been depositing into — the determination that arrives with its defense already attached.
Method six: Output Engineering — the standard every stage deposits into: decomposed, evidenced determinations that prove themselves.
06 · output engineering
In hand from Orchestration Engineering: the workflow running as a governed team — every handoff declared, a person summoned when a determination can't be made cleanly.
The answer proves itself along the way. Not at the end.
Here is the conviction this method stands on: if making the right decision is the hard part of cognitive work, evidencing it is the harder one. Output Engineering is the capstone of the prescriptive workflow — it makes EVIDENCE a manufactured deliverable instead of a luxury nobody has time for: declared in advance, deposited node by node as the work runs, uniform across every determination. By the time the final answer exists, its defense already does too.
the autonomous instinct
Let the model produce its best answer, then judge whether you like it.
the prescriptive move
Define the evidence standard before the work runs — its content, its shape, its attestation — and refuse anything that arrives without them.
The cognitive work to reach a decision is hard. Its evidence is even harder.
A skilled expert wrestles through the record and makes the determination. Proving it — naming the criteria it was judged against, quoting the record language that carries each one, showing where the support lives — takes longer than the deciding itself. That's why an answer you can't defend isn't finished, no matter how right it sounds — and why the defense has to be a property of how the work ran, not a report assembled later.
Nobody is paid to prove their work.
A claim codes for a few dollars. The workday is measured in encounters, and the quota decides how many minutes each one gets. Evidencing the decision was never in that equation — not because experts don't care, but because the economics forbid it. This is precisely where Gen AI earns its keep: authoring the evidence, at volume, is the one deliverable it can produce that no workforce ever could afford to.
There is no standard for evidence. Anywhere.
No universal method for capturing it, no criteria for what kind of evidence carries what weight. Where capture exists at all — an E/M checklist — it exists to compute a level, not to prove a decision. Even the workflows that demand evidence, like prior authorization, rarely design it to carry clarity and weight. So the Prescriptive methodology supplies the standard: declared per workflow — what counts, what it must cite, and what happens when it isn't there. Absence is a finding, reported as missing — never quietly supplied.
Uniform evidence is what survives the audit.
One-off evidence answers the question its author imagined. Uniform evidence answers the criteria the auditor actually holds — comprehensive, complete, attesting point by point to the standard the decision will be judged against. That's why the output's shape is a contract set before the run, every field named, every claim tied to its support, opening with proof its own checks ran. Uniformity isn't a style preference. It's how evidence stays complete at the thousandth determination.
EVIDENCE converts the expert from author to validator.
No domain expert who owns these workflows wants the human pulled out — that's the autonomous noise talking. But the expert can't match the demand either; the cognitive load outruns any workday, in volume and in complexity. Automation here was never elimination. It's scaling the domain expert — and EVIDENCE is how. Automate the determination, hand the expert its evidence, and their role changes: from finding and figuring to validating. Even when a determination is microscopically wrong — and this criteria is that exacting, that situational — the evidence shows the exact wrong turn, and the correction takes a moment instead of a re-read. Yesterday: a quota of encounters, none of them evidenced. Now: more encounters, every single one evidenced. The immovable metric just moved.
EVIDENCE is the bridge, not the paperwork.
Payers and providers both want the same two things — lower cost and better care — and they've spent decades building workflows designed to trap, catch, and stop each other instead. The conflict isn't bad faith. It's that evidence is so hard to capture and communicate that neither side can see the other's reasoning — and you cannot coordinate on behalf of the patient when you can't get past capture and communicate. A determination that arrives with its defense attached isn't ammunition for the fight. It's the first artifact both sides can stand on.
the thread · the determination, delivered What comes out the other end — the answer with its defense attached. Open the finale. open the case ▾close the case ▴
It opens with its own audit
What was read: two claims, one matched encounter, the record. What was verified: classifications per the table, alignment per the reference, modifier placement per the rule. What was missing: nothing — or named.
The six decisions, answered
- 01Same provider, same date, more than one E/M line? — Yes: two E/M lines, one provider, one datepass
- 02Exactly one problem-oriented and one preventive? — Yes: 99213 problem-oriented, 99395 preventive, per the tablepass
- 03Diagnosis linked to the problem line? — Yes: I10 and R07.9 on the 99213 linepass
- 04Diagnoses align with the service types? — Yes: active disease and symptom codes, no screening-only codes on the problem linepass
- 05Modifier 25 attached to the right line? — Yes: on 99213, absent from the preventive linepass
- 06All exception criteria pass? — Yes: dual E/M reimbursement authorizedpass
The evidence, as the LLM authored it illustrative
The final act — the LLM reads the record against the five determinations above and writes the defense, quoting the note itself:
Modifier 25 supported. The problem-oriented service (99213) addressed a significant, separately identifiable problem beyond the preventive visit: the record documents new intermittent chest pain — "patient reports intermittent chest pain over the past two weeks, worse with exertion" (HPI) — and uncontrolled hypertension requiring a management change — "BP 158/96 despite reported adherence; lisinopril increased to 20 mg" (Assessment/Plan). Diagnoses I10 and R07.9 are active-disease and symptom codes consistent with problem-oriented care; no screening-only codes appear on the problem line. Criteria attested: qualifying combination · diagnostic support · modifier placement.
Every quote pulled from the record, cited to its section, tied to the criterion it carries — the culminating cognitive step no coder is ever given the minutes to do.
Same facts next week, same determination, same evidence — and the payer's analytic now reads a claim that read itself first, and shows its work. That's the property the first page promised, arriving.
This method has no single station, and that's the point. Its levers are woven through every stage — the output contract each node carries, the evidence each determination binds, the attestation each prompt demands. Output Engineering is the standard the other five deposit into.
Coming next: where all of this leaves you — the method you just read, already running.