The Solver Was Always the Hard Part

The schedule is not the product. The contract is.

Every week, in thousands of skilled nursing facilities across the United States, someone sits down with a census printout, a list of therapists, and a stack of care orders and builds the week by hand. At a large building it takes hours a day. The person is the Director of Rehabilitation. The output is a grid: which clinician treats which patient, when, in which mode, for how long. Every cell in that grid is a small legal, clinical and financial decision.

I spent 2026 helping a small team replace that grid with a system that produces it, defends it, and can explain itself when it is wrong. This is a case study of that year: the domain, the algorithms, the platform around them, the regulatory boundary, and the way the code was actually written. The company is in stealth, so I will not name it, its customers or my colleagues, and I will not quote any number that describes their business. Everything else is fair game.

The thesis is in the title. The solver was always the hard part: a combinatorial problem with a payer in the loop, a time budget, a reproducibility requirement and a rulebook that changed nine times in a quarter. And a hard solver only becomes a product when the product rules, the input preparation, the three ways of calling it and the evaluation harness all mean the same thing by "a good schedule". Most of my commits sit at those boundaries, in service of the hard part.

What a week looks like inside a nursing facility

A skilled nursing facility houses two populations: short-stay rehabilitation patients coming out of hospital, and long-term residents. Therapy is delivered by three disciplines, physical therapy, occupational therapy and speech-language pathology, the third of which entered our scope later in the year. Within each discipline there are licensed therapists and assistants, and some work is therapist-only: evaluations, progress notes at a mandated cadence, plans of care.

Each patient carries a plan of care: a frequency such as three to five sessions a week, a session length such as thirty minutes, and a start-of-care and end-of-care window. Who pays changes the rules. Medicare Part A pays per day, requires a minimum number of therapy days per week, and caps how many minutes may be delivered in group or concurrent sessions. Medicare Part B pays per billed service, does not recognize concurrent therapy, and has its own minimums. Managed-care variants copy one of those and add their own twists. Under CMS's Patient Driven Payment Model, in force since October 2019, therapy minutes stopped driving Part A payment the way they used to, and CMS imposed a 25 percent limit on concurrent and group therapy per discipline, enforced with a warning edit rather than a penalty. The payer change had a measurable effect on care: a 2022 JAMA Health Forum cohort study of about 200,000 post-acute patients found individual therapy fell by roughly sixteen minutes a day after PDPM while concurrent and group therapy rose by about four, with no change in outcomes. Those are public facts about the payer, not settings in our product, and the difference between the two matters in this article.

Clinicians have employment types with weekly hour limits, paid time off that is a hard constraint, availability preferences that are soft, cost tiers, and in dense markets the ability to float between nearby buildings, which drags state licensure into the picture. Continuity of care, the same clinician across a stay, is a preference that clinicians and patients both feel strongly about. Productivity, therapy minutes over on-site minutes, has role-specific targets.

The planning unit is the facility-week. The solve runs nightly after the electronic health record export lands, plus on demand when the day changes. A schedule has a lifecycle, proposed, selected, actual, and divergence between proposed and actual is itself a signal: either a constraint is missing or the schedule was impractical.

The specification behind that table has dozens of hard rules, a handful of soft ones, three goals and a few exception types. A facility has anywhere from five to well over a hundred patients and five to thirty clinicians, and a facility-week is a few hundred sessions.

On size of the prize: one founder's back-of-envelope in a planning call put annual US patient spend on rehabilitation therapy inside skilled nursing facilities, under the payer types the product touches, on the order of thirty billion dollars, which makes a one-percent efficiency gain a nine-figure number. That is an internal estimate, not a market study, and I am quoting it as such. The public anchors are narrower and more solid. KFF counted 14,742 CMS-certified nursing facilities as of July 2025, housing about 1.24 million residents, and MedPAC reports that fee-for-service Medicare and its beneficiaries spent $31 billion on skilled nursing facility services in 2024. A large share of those facilities outsource rehab to contract-therapy companies; the rest run it in-house.

The team

Three founders. One is an ex-Google engineer, one of the most pleasant and humble people I have worked with, and one of the most knowledgeable and experienced. One is an ex-Meta product founder and a genuinely strong product manager; we spent the last week of August 2026 together in Medellín doing live design work and have another week planned there in October. The third covers business, startup and finance. I am the founding principal AI-native engineer with an end-to-end remit, and I brought in two staff engineers from Belgrade, friends and long-time colleagues, who work with me. Their onboarding rule was the one I would want for myself: build your own understanding of the domain first, then read my notes.

It is a small, distributed, AI-native team and a pleasure to work in. It also runs on one-week cycles, plans on Fridays and works async.

A feasible schedule is not a correct one

The output of a scheduler is easy to mistake for an answer. It is a proposal, and it is only as good as the promises it keeps to three parties. To the payer: every placed session is allowed under that patient's coverage on that day. To the clinician: the week fits their hours, their license, their time off and, where possible, their preferences. To the director: anything that could not be placed is named, not hidden.

The first thing the domain teaches is that "optimal" is not a useful word. An optimizer will happily produce a schedule that satisfies every constraint you wrote down and violates three you did not. Four design decisions around the solver decide whether its answer can be trusted.

Source facts, capacity assumptions and prepared inputs are different objects. A recorded historical visit proves that a clinician was in the building for that visit. It does not prove they had a full shift. Early scheduling systems, ours included at one point, are tempted to infer supply from history. We refused: supply is shift-first, and missing data can never quietly become invented capacity. The prepared inputs carry the assumptions explicitly, with a policy identity, so a run can say which assumptions it was allowed to make.

One physical session, projected to patient rows. A concurrent session is one clinician, one time block, two patients. If you model it as two independent clinician blocks you double count time and cost, and a reviewer will catch the discrepancy in the cost report and stop trusting the whole thing. The canonical schedule stores the physical session; assessment projects it into per-patient rows.

Hard, soft and goal never share a scale. Compliance first, then preferences, then objectives. Unmet demand and capacity-constrained situations stay visible in the output rather than being absorbed into a score.

Exceptions are routed, not failed. Some cases should be a decision for the director of rehab. Producing no schedule because one patient's situation is ambiguous is worse than producing the schedule and a question.

The solver, and why it is hard

Start with the size of the thing. A facility-week is a few hundred sessions to place across five to thirty clinicians, five or six days and a minute-level grid, under dozens of hard rules that interact. A Part A patient's group cap changes what is legal for the clinician standing next to them. An assistant's supervision cadence depends on when the therapist last saw the patient. Continuity pulls against capacity. Every run has to finish inside a budget and return the same week for the same inputs and the same budget, because a director who gets a different schedule on a rerun stops trusting all of them. Personnel scheduling is NP-hard in the general case, and this is a version of it with a payer in the loop. The engine went through three generations in six months before the team trusted it in production, and the evaluation harness spent the year telling us where it was still wrong.

The technical founder designed and built the current engine; my commits inside it are rule and cadence corrections, and the pipeline around it is where my footprint is. The objective order, weights and thresholds are proprietary, so I will describe the families and the reasons, not the recipe.

In slightly more detail, and still generically. The dynamic program explores a heap-ordered frontier of partial days and caps how many candidates each clinician-day may contribute; a process pool can fan the generation out. The master problem picks at most one candidate per clinician-day while covering ordered care under weekly capacity, and it walks a lexicographic ladder of objectives by reusing one model with solution hints rung after rung. Group and concurrent sessions are then coalesced, and CP-SAT repairs what the coalescing disturbed: repacking, same-day retiming, and employment-tier reassignment with the earlier objectives locked. A greedy residual pass inserts what still fits and audits its own insertions, and a final legality audit checks cadence, overlaps and that no later stage increased a protected hard violation. All of it runs inside per-stage budgets on one monotonic time origin.

Two decisions in that design are worth defending. The first is time. Every stage has its own budget object, validated at construction, all sharing one monotonic origin, and the production adapter reserves a fixed slice for finalization. Solver timeouts are a design input, not an error case. The second is determinism. One production repacking path runs CP-SAT with a single worker on purpose. More workers overran the timeout and added parallel-search variability, and the code comments say what solver documentation tends to say quietly: a feasible incumbent stopped by the wall clock is not a determinism guarantee. OR-Tools' own parameter file promises deterministic search only for its experimental interleaved mode, "independently of num_workers", and the default multi-worker portfolio makes no such promise.

None of this is exotic on its own. Google describes CP-SAT as a constraint programming solver that uses SAT methods, and personnel rostering has been a benchmark problem for operations research for decades: Burke and colleagues surveyed the state of the art of nurse rostering in 2004, Brucker, Qu and Burke laid out the models and their complexity in 2011, and branch-and-price for huge integer programs is Barnhart and colleagues, 1998. What is specific to this product is which combination survives contact with payer rules, inside a time budget, reproducibly. No single technique is the difficulty. Making them agree is.

Three verdicts, not two

The evaluation harness returns pass, measured failure, or not assessable. Missing evidence is reported as missing and never rounded up to a pass. The CI lane compares the protected base against the pull request on the same deterministic synthetic fixture; metric movement is advisory, while report health and identity failures block. Everyone on the team can recite the caveat: a regression fixture shows whether a change moved behavior on that fixture. It does not establish business value.

The harness earned its keep twice in ways I can share. A Saturday evaluation run caught a change, suggested in review and perfectly reasonable on paper, that dropped feasibility on the evaluation set from over ninety percent of facility-weeks to under fifteen before it reached anyone. And a retrospective comparison, with the hindsight bias running in the solver's favor, still found humans outperforming the solver on one payer type because the rules encoded for it were too coarse; the evaluation is what surfaced it, and the fix was a spec change, not a solver change.

The rules rail: prose in, contract out

This is where most of my attributable work sits. The product rules are written by the product founder in ordinary documents. They change often. Code that hard-codes those rules rots in days.

So the rules got their own repository and their own release process. An authenticated ingestion step reads the document, normalizes it into rule artifacts, and lays a name-stable overlay over them so that a rule keeps its identity when its wording changes. Retired rules get tombstones rather than deletion. Schemas are generated. Releases are versioned with a changelog and amendments, and ingestion is idempotent when only timestamps moved. The scheduler pins exactly one release, in one place.

The pin alone is not enough, because a valid JSON response can still describe an invalid schedule. Verification is a ladder, and each rung asks a different question.

parity ladder (each rung is a separate check; a rung may return
"pass", "measured failure" or "not assessable")

 1. binding     every rule implementation binds to a real rule ID
 2. values      every configured value matches the pinned spec,
                or an explicit, named override
 3. defaults    every runtime default comes from the generated schema
 4. output      every emitted schedule satisfies the rules
 5. structure   every emitted schedule is structurally valid
 6. behavior    soft objectives produce the intended aggregate effect
                on a fixed fixture

 gaps   := rules with no implementation    (enumerated, never assumed)
 extras := implementation with no rule     (enumerated, never assumed)

Known gaps and extras are enumerated rather than silently treated as parity. Pull requests cite rule identities. CI fails on drift. Nine breaking versions in a quarter sounds like churn. It is the opposite: each one was a rule the humans got more precise about, and the pin made every change a visible, reviewable diff instead of a quiet edit to a constant. The effect on the team was cultural as much as technical: the product founder edits prose, the pipeline turns it into a contract, and an engineer who wants to argue with a rule argues with a version number.

One entry contract

The scheduler can be invoked from a command line, an API and a cloud job. Early on those three paths drifted in their defaults, which produces the most expensive kind of bug: an engineer reproduces an API result with a CLI command that is subtly solving a different problem, and spends a day chasing a ghost. The fix was a common preparation and invocation contract, the canonical prepared week as a single immutable object, and an entry-point equivalence integration test. The repository rule is that any new entry point adds an adapter to that test or documents its divergence. Boring, and it ended a whole category of wasted afternoon.

One run identity, everywhere

Run identity is propagated through structured logs, OpenTelemetry spans, persisted run statistics, pinned prepared-input replay artifacts and a demand ledger. A report that says "this schedule looks wrong" arrives with a run identifier and becomes an inspectable engineering problem: the exact inputs, the exact policy, the exact budget, replayed. I have watched teams lose weeks to screenshots. We do not accept screenshots.

Time is an adversary

Healthcare data has a temporal trap that most optimization write-ups skip. The team wants to know whether the machine beats the human. The obvious experiment is to take last month's data, run the solver, and compare. The obvious experiment is wrong, because last month's extract contains things the human scheduler did not know at week start: the discharge on Wednesday, the therapist who called in sick on Thursday, the order that changed on Friday. Retrospective data hands the optimizer a crystal ball.

We separated what was planned, what later happened, and what was actually knowable at each point, and the codebase refuses to fabricate a prospective snapshot identity for a later extract. Making the evaluation honest about time was a change that touched two hundred files and took nine review passes. That is what a change to how evidence is labeled should cost.

The platform around the solver

An optimizer becomes a product through its boundaries. This is the stack, and then the parts of it I am proudest of.

Ingest fails closed. The feeds that arrive from a facility are not under our control. We accept extra columns. We fail closed the moment a load-bearing column disappears, name every dropped column in the delivery receipt, and explain a facility that a feed omitted instead of showing an unexplained empty week. We stopped deriving clinician identity from an absent-name placeholder after it produced a clinician that did not exist. Support intake inside the product is designed so that a report never has to carry protected data to be filed; turning a report into a reproduction without protected data is the next step, not a finished one.

ingest contract (per feed, per facility)

 for column in required_columns:
     if column not in feed:  fail_closed(reason=column)   # no partial week

 extras  = feed.columns - known_columns                   # tolerated
 dropped = known_columns - used_columns                   # named in receipt

 if facility not in feed:  explain("omitted by feed")     # never an empty week
 if name is placeholder:   reject_identity()              # never a synthetic clinician

 receipt = {accepted, extras, dropped, reasons}           # always emitted

Authorization is four checks, not one. A successful sign-in establishes an identity. Every request then has to carry an organization, a role, and a facility scope, and each is checked separately against the database's own tenant isolation. Session tokens are random and stored as hashes. Production explicitly disables the development login path; environment parity is a behavior we verify, not a configuration we copy.

The database is part of the release. The same migrations run locally, in CI against a real Postgres service container, and in deployed jobs. CI applies the vault migrations with the restricted production roles so that a permission failure shows up in a pull request instead of a release. Promotion is immutable: image digests, migration execution read-back, schema before consumer, forward-only repairs. The wrong order here is not a bug, it is an outage with a compliance memo attached.

Background work reports its own death. The orchestration plane has an exactly-once effect contract, a state machine that CI attacks with fault injection and zombie writers, run workers, a dispatch plane, a sweeper and dead-letter handling, fan-out with shadow dual-write, and a queued-versus-direct equivalence gate. Its metrics are zero-filled so that "no series" means something different from "no work"; queue age, stuck work and missing heartbeats reveal failures a process cannot report after it has died. We load-tested it with thousands of synthetic tasks before the first real one.

A configured dashboard is not evidence. The availability SLO looked correct in code and was matching nothing, because the monitoring resource selector did not match the type the deployed service actually emitted. The fix was small; the lesson is that an alert's query has to be verified against the live metric stream, and the verification date goes in a comment next to it. In the same spirit, after a week in Medellín with the product founder we retired around 174 alert policies and ten budget thresholds that nobody had ever acted on and replaced them with three signals, login, ingest, schedule, and one incident channel with one thread per incident. The frontend error reporting, which a teammate built, scrubs outbound envelopes and tests the SDK's real outgoing traffic rather than mocking its internals, because a scrubber unit test cannot prove that another SDK feature never sends sensitive context.

Compute is elastic when evaluation is the bottleneck. The multi-facility evaluation took 45 to 60 minutes on a laptop. On an on-demand 176-vCPU VM it took under ten; right-sized to 88 vCPUs it takes about fourteen at roughly three quarters of the cost. Evaluation that takes an hour gets skipped. Evaluation that takes a quarter of an hour gets run on Saturdays.

CI never holds a cloud key. GitHub Actions obtains short-lived Google Cloud authority through OpenID Connect workload identity federation, constrained to the repository, with distinct plan and apply identities. Plans are saved, validated and checked for the alert content they would produce before anyone approves an apply. Cloud development environments are converged from a single source SHA with an isolated deployed slice of the product, so "works on my machine" now means "works in a real environment that looks like production".

Merged is not deployed. Deployed is not verified.

Two incidents made this a rule rather than a slogan. A ticket sat In Progress for ten days after its change had merged, because nobody had re-read production; when we did, the change had shipped nothing, and every check was green. And for several days every production promotion failed while merges piled up on main, because the release had widened to include components production could not serve. Now a ticket closes on a live read-back, not a green check, and the tooling that posts lifecycle events to the tracker only has one event that can close a ticket: verified. A regression reopens it, and the fix goes through a new reviewed pull request.

HIPAA without the theater

Healthcare engineering attracts a specific kind of vagueness. "We are HIPAA compliant" is said by a lot of vendors and certified by nobody, because there is no such certificate: the Department of Health and Human Services does not certify compliance with the Security Rule and does not recognize private certifications either. What exists is a set of obligations and a set of mechanisms, and the honest sentence is that a system is designed and operated for HIPAA-regulated workloads. Here is how the obligations map to what we built.

The team also made sure engineers could work on realistic data shapes: a nightly mirror of production, with identities replaced under an expert-determination-style process, runs in the development environment so that the shapes are real and the identities are not. I describe it that way rather than as "de-identified" because that word is a legal status, and this article claims none. The decision came from the founders' insistence on a production quality bar, and it changed how fast we could find the class of bug that only appears when the data is shaped like a real facility.

How the code got written

Now the part people ask about first. Most of the code in this system was written with coding agents in the loop. My share was written under rules I wrote, reviewed by humans and by other agents, and verified in the environment that matters. DORA's 2025 report found ninety percent of respondents using AI at work and thirty percent with little or no trust in the code it produces. The gap between those two numbers is where a harness lives, so here is mine.

One policy, three agents. I run Claude Code with Fable 5.1 at maximum reasoning, Codex with GPT-6 Astra at ultra, and Grok Build with Grok 4.6 at xhigh. They read one policy file and one set of procedures. Per repository, a manifest lists the canonical instruction files, every command's source and its generated per-vendor adapters, the references each task must read, and literal model invariants. A sync command generates twelve-line hash-stamped adapters that say "read the canonical file and use your own native tools"; a check command fails when anything drifts, including a forbidden model pin in a launcher script. Skills are compiled artifacts. Client repositories are a declared no-write zone: the harness runs there and stores nothing there.

Hooks enforce what prose could not. Every lifecycle event of all three agents runs one small deterministic program with no model calls and no network: it checks adapter drift, appends the session's token usage to a private ledger, delivers any message queued for that session, and watches the vendor's usage limit. A pre-tool hook denies grep, rg and git grep over the knowledge directories and tells the agent to use the local semantic search instead, because the rule kept being ignored while it was only a sentence. It fails open, so a bug can never brick the shell, and every block is audited. The other two agents reach the same guard through a payload translator.

Knowledge stays local. About 1,400 markdown documents across nine collections, roughly 100,000 embedded chunks in a one-gigabyte index, searched by keyword, by vector and by hypothetical-document expansion with a local reranker. The embedder, the reranker and the query expander are small local models. The index and the search never leave the machine. Every commit queues a re-index; a lock stops two repositories from running the embed pipeline at once.

Independent review comes from a different vendor. When a piece of work needs an independent review, a runner picks one of the other two vendors at random and spawns a child process of that CLI with no tools, no memory, no hooks and no project discovery, at that vendor's strongest model. If the vendor is out of credits or rate-limited it tries the other. If both are unavailable it falls back to a fresh child of my own vendor and the receipt says same_provider_fallback, so "two models agreed" is never claimed when one ran. A wrong model, an exposed tool or a malformed stream is a hard failure, not a reason to try someone else. Every article on this blog, this one included, goes through that runner before it ships.

Limits become handoffs. Each vendor's usage limit is watched from its own signals. Past a threshold the session stops starting work, commits and pushes, updates the ledgers it was using, and writes a takeover record that captures git state, every loop's stop marker and lane, and the project's declared pointers. The next agent, from any vendor, resumes with "take over from X". This article was researched by one vendor until it hit its usage limit and finished by another, through exactly that record.

The loop only closes on verified. For unattended work there is a headless loop: a bash scheduler around the ticket tracker asks an oracle which tickets are truly done, tracker state rather than the worker's word, picks the ready set from a typed dependency graph, and launches one fresh, memoryless worker per ticket in its own git worktree. A worker's finish line is one ticket verified live. It waits for the development deploy, dispatches production, reads the live revision, and only then posts the one event that can close a ticket. A blocked ticket must name a machine-checkable release condition or its gate expires in two hours. When a vendor's limit hits a lane, the loop refunds the attempt, probes the others, fails over after an hour and fails back on ten-minute probes. When it would otherwise stop, it first runs a self-heal pass that may patch its own harness template but never the verifier, whose files are hash-checked before and after every scheduling decision. Stop is a file the loop never removes. Dozens of batches ran over the summer.

Provenance is derived, never self-reported. The model that did the work is read from the launcher's process arguments, not from the model's memory of itself. A local commit hook writes a trailer; one line in the pull request body carries it. Absent beats wrong. There is no cost tier, because a usage bar is not a bill. Team-facing pull requests carry no other AI attribution and read in my voice, because I own them. Where trailers survived squash merges, roughly a third of my early commits carry an AI co-author line, and about a third of my scheduler commit messages since July name the agent that did the work. The more reliable record is the provenance line on the pull request.

Since the numbers describe my own commits in private repositories rather than anyone's business, here is the shape of the year. They measure accountable ownership and cadence, not quality, and the solver core is not in my column.

Verification is a chain of receipts. Before code, the required outcome and the evidence that would prove it. In the pull request, a four-field simplicity disclosure that a script checks, required outcome, smallest viable shape, what was removed or avoided, net-new operational surface, plus a manual test recipe. A credible smaller design blocks a merge even when CI is green. Every finding from every review bot gets a written disposition; threads resolve when the fixing commit lands, never in a batch at the end.

Memory is files in git. One tracked folder is shared by all three agents through a symlink, so a correction given to one agent is the next agent's rule and the tool's protected-directory prompt never fires. It took three iterations, and the earlier public version was wrong on the key point and was corrected in place. A hand-curated graph of decisions and their supersession, each node citing a file and a hash, sits after search rather than instead of it; on a small pilot it did not beat plain search-plus-read, so it stays small.

Budgets became an engineering constraint. The policy says maximum model at maximum reasoning everywhere, headless workers and subagents included, and a weaker model is never a fallback. The same policy lists the cost tricks I refuse: capping output, skipping review, forcing compaction, paid cache keepalives, claiming savings I did not measure. That stance has a price, and during the year the price showed up as usage limits in the middle of work. The takeover mechanism exists because of it. I would rather engineer around a limit than around a worse answer.

The team's own practice runs alongside mine. Specs come first and the ticket is the spec. Bot code review and security review run on every pull request, and the scheduler requires human approval on every one, a rule that arrived after one month had shown how much agent-written code could land without a human reading it. There is a monthly agent show-and-tell, a per-release artifact written so that the team's AI tooling can consume it, and a stated release goal of a sustainable AI software factory. The technical founder also asked, in September, for a manual review of the codebase with no AI in the loop and a higher production quality bar. Both requests are right. AI accelerates; it does not replace judgment, and a team that cannot read its own code no longer owns it.

Hot takes

The solver is the hard part. The boundaries are where it gets betrayed. A brilliant engine fed invented capacity, or judged against a crystal ball, produces a confident wrong schedule. Guard the boundaries as seriously as the engine, and keep them boring.

A schedule you cannot replay is a rumor. If a run identifier cannot reproduce the inputs, the policy and the budget, the schedule is a screenshot with extra steps.

Structural validity is the floor. If your only check is a schema, you have tested the serializer.

"Not assessable" is the most important verdict in healthcare evaluation. Two-valued checkers lie by omission. The moment missing evidence rounds to a pass, the pass is worthless.

Retrospective comparisons against humans are usually cheating. If your extract contains Friday's discharge, your optimizer had information the human did not. Seal the bundle or do not publish the number.

Tokenization is a security control, not a legal status. "Anonymized" is not a HIPAA term; "de-identified" is, and you probably did not satisfy it.

Maximum model, maximum reasoning, then engineer around the limit. A cheaper answer to a healthcare scheduling question is not cheaper; it moves the cost to the director of rehab. In my experience, cheaper models produce equally confident code, and in a payer-rule domain confident code is the expensive kind.

Your agents should not be allowed to grep. A keyword hit is not the current rule, and a model will not volunteer the difference.

What I have not measured, and what I have left out

Realized value. That thirty-billion figure is an estimate. Modeled coverage or labor gains are not realized gains, and a gain is only real when a facility follows the schedule, measured week by week against what humans actually delivered. That measurement is the work of the coming months. The loop checks merged, deployed and verified, ticket by ticket; whether the product is good is checked by a facility, week by week, and that is the number this article does not contain.

Compliance status. Nobody certifies HIPAA compliance. I have described mechanisms. I have not claimed a status and I would distrust anyone who did.

Fresh test results. The tests, fixtures and gates above describe intended behavior as it exists in the repositories today. I did not re-run them for this article.

The customer, the numbers, the names. Stealth is a constraint I accepted, and the gaps in this text are where it bites.

Sole authorship. The solver core, the frontend error reporting and large parts of the evaluation harness are colleagues' work. My share is the boundaries, and I am comfortable being judged on them.

What comes next is the second in-person week in Medellín in October, scoping the next order of magnitude of operational scale: onboarding that does not need an engineer, support triage that turns a filed report into a reproduction an engineer can run without ever seeing protected data, and monitoring that scales with the fleet instead of with the on-call rota. The solver will still be the hard part. Everything else has to be easy enough to let it be the only one.