Part 11 ended by saying the queue was finally honest. It held 40 re-issues that tier 1 declines on purpose, the pairs a scorer would settle if anybody trusted its weights, and sixty father-and-son records that a confident model had merged at 0.93.
Honest, and never once opened.
Eleven parts have described a platform whose entire purpose is to decide what it can and hand the rest to a person, and not one of them has shown the person. This part is written from that chair. The build added a queue, and then the queue was worked — every item in it that needed a decision — against a rubric fixed before the first item was read.
Start from what the machine had already done, because the rest of this only makes sense against it. All 7,064 of the corpus's member loops ingested. Thirty-six files of thirty-six, every transaction set, 5,217 people and 1,847 re-arrivals written and queryable, with tier 1 linking 974 of them and getting none of them wrong. The file went in clean.
What the queue holds is what survived that. Nine hundred and ninety records out of 7,064 — fourteen percent, in a corpus built to be hostile — that the platform declined to settle on its own and handed over instead.
What came back from working them narrowed the argument this part was written to make, which is the most useful thing a run has done in the series so far.
The Five Percent Is Somebody's Week
A mid-size payer moves something like fifty thousand enrollment transactions a month. Three to five percent of them will not process cleanly — a span that overlaps itself, a subscriber id that resolves to two people, a termination that arrives in the file after the one that should have carried it, a plan code the companion guide never mentioned.
That is between fifteen hundred and twenty-five hundred records a month landing on a human being.
A platform that decides ninety-five percent has produced a job out of the other five. That job is somebody's week, every week, and the shape it arrives in is a design output of everything upstream of it. Every confidence threshold, every gate severity, every auto-approve band this series has set is a decision about how many records land on a person and in what state they land.
Eleven parts have been setting that number without ever naming it.
The exception queue is where a data platform hands its hardest cases to the most expensive resource in the building, and then stops paying attention to them.
And the expertise in that chair is real and almost entirely unwritten. The SSN matches and the date of birth is off by one digit, which is the keying error that happens when someone reads a form upside down — that is judgement. This payer back-dates its terminations into the next month's file, every month, and has done for three years — that is institutional memory. Neither one is a rule anywhere in the platform. Both are correct. A platform that treats the queue as an overflow bucket throws them away, one decision at a time, for years.
Where This Pays for Itself: The Exception Queue
The arithmetic is what decides whether the queue is a feature or a staffing line.
Two thousand records a month. A working month is about a hundred and sixty hours. That allows four to six minutes per record — and four to six minutes has to cover opening the item, finding whatever context the platform failed to attach, making the decision, and recording why.
A record that arrives with its evidence assembled is a decision. Both candidate people side by side, the fields that agree and the fields that do not, the file it came from, the rule that refused it, the identifiers each one holds. An analyst reads it and acts.
The same record arriving as an identifier and a status code is a research task. Open the admin console, look up the person, look up the other person, find the file, find the transaction set, pull the rule definition, then decide. Fifteen minutes, and most of it is retrieval.
Across two thousand records a month, the difference between those two is the difference between one analyst and three. The queue design is a hiring decision that gets made in a schema.
Follow one member through it.
A dependent — call her Rosa — is terminated effective the thirty-first of January by a payer with a known habit: its terminations ride in the following month's file rather than the one they belong to. The February file arrives without her termination. The March file carries it, back-dated. The platform now has a coverage span that contradicts what it already recorded, and the gate refuses the write rather than silently overwriting a belief.
That refusal lands in the queue on the fourth of March.
If the item carries the span, the file it came from, the previously recorded span and the rule that fired, an analyst who has worked that payer recognises the shape in about four seconds. The habit is known. The decision is routine. Four minutes, and the correction is recorded with a reason attached, and Rosa's February claims settle against the right answer.
If the item carries an entity id and a rule name, it waits. Nobody can clear what they cannot read, so the hard items sink and the easy ones get worked, and Rosa's record is still there in August when somebody runs a reconciliation. By then her February and March claims have paid against coverage she did not have. The provider gets a recovery letter six months after treating her. Rosa gets a balance bill. Someone opens a dispute, and the dispute costs more to work than the original item by an order of magnitude.
The cost of an exception is the time it takes to work it multiplied by the probability it gets worked at all — and that second term is set entirely by how legible the item is. An illegible queue does not slow a team down evenly. It sorts the work into the part that gets done and the part that becomes next year's reconciliation.
There is a third cost, and it is the one this build found by accident. Before this part, nothing anywhere in the platform recorded that a person had picked an item up. No claimed_by, no claimed_at, no claims table, in any of the four lanes. Two analysts working the same queue on the same morning would land on the same item, both work it, and one of them would lose — silently, with no record that the work had been done twice. A platform that cannot say I have this cannot be worked by more than one person, which means the staffing model the economics above assume could not have existed. That is an economic fact long before it is a schema gap.
What the Platform Owes the Person
Four obligations. Each one became a build step, and each one is an obligation rather than a feature.
One list, not four. Everything awaiting a human, in one place, in one shape, in one order. A person working a queue should never need to know which of four subsystems produced the item in front of them.
The evidence, attached. An item arrives with what is needed to decide it. Never a uuid the analyst has to go and resolve.
A way to say "I have this." Assignment, so two people do not do the same work and one of them quietly loses.
A way to say "I could not settle this." Uncertainty as a recorded state rather than an item that keeps reappearing in someone else's morning.
The fourth one had been half-built since Part 3 and nobody noticed. disputed has been a legal value of an identifier's status since migration 002 — written into the CHECK constraint alongside active and superseded, in the same commit as the person model. For nine parts, nothing in the codebase ever wrote it. The vocabulary for uncertainty was in the schema from the beginning and the verb was never built, which is a specific and slightly embarrassing kind of gap: the design knew what it owed and the code never paid.
The first one had a more interesting shape. Four lanes feed the queue — the AI's resolution proposals, the gate's refusals, the identity links a scorer or a steward wrote, and identifiers two people hold. Exactly one of them had a complete read path when this part started. GET /agents/proposals/pending lists both the unjudged and the judged-but-pending proposals, pages, and has been there since Part 5.
The other three could be read only through the side door. Gate refusals, one file at a time, by raw_file_id. Identity links, one person at a time, by person id. Disputed identifiers, not at all, because nothing could create one.
The one lane with a front door was the lane serving the AI's output. The three without were the ones that come from the domain.
The endpoint that fixed the worst of those took twenty-three seconds from first edit to a passing call and is seventeen lines of SQL. It was never difficult. It was never asked for, because the thing asking was a person and the person was not in the room.
What the Queue Actually Held
Part 11's corpus is a seeded enrollment year: thirty-six files, 7,064 member loops, 5,217 people and 1,847 re-arrivals, with a ground-truth manifest that is the only reason any number below can be checked. Tier 1 and tier 3 both ran against it, with no weight set active and no auto-approve rule, and then the queue was opened.
| Lane | Items | Worked |
|---|---|---|
| proposal — two person rows the agent thinks are one | 950 | 916 |
| identifier — a number two people hold | 40 | 40 |
| link — a merge somebody wants reviewed | 0 | — |
| Decisions awaiting a person | 990 | 956 |
Nine hundred and ninety records needed a human. Against 7,064 member loops that is fourteen percent, and the corpus was built to be hostile: a third of its households are resent by construction and sixty father-and-son lookalikes were planted on purpose. A payer's real traffic sits at the three to five percent this part opened with.
So the queue is a week of work, which is exactly what it was supposed to be.
Then there is a fourth lane, and it is the first thing the queue got wrong.
Alongside those 990, the view returned 7,064 refusals, and every one of them is a warning. The record carrying it is already written, already queryable, already answering eligibility questions. The gate raised a flag and let the record through, which is what severity: warning means and what every one of these three rules is set to.
| Rule | Payer | Records |
|---|---|---|
payer_schema_registered | two payers with no companion-guide schema registered | 4,187 |
acme_department_code_present | ACME | 2,877 |
payer_extensions_known_keys | ACME, the same 2,877 records | 2,877 |
Not one of those is a decision about a member. payer_schema_registered fires on every coverage row belonging to two payers whose companion guide nobody has entered — two configuration entries, repeated 4,187 times. And payer_extensions_known_keys says in its own description what it is for: a key that shows up here every month is a column somebody has not written yet. It is a backlog generator. It is working.
None of which belongs in a work queue, and the view put it there anyway. The work_items union was written to bring four lanes into one list and drew no distinction between a lane of decisions and a lane of observations, so a person opening this queue meets 8,054 rows of which seven thousand can only be read. That is a scoping bug in a view seven days old, and the fix is to give advisories a surface of their own and let the queue hold the 990.
The valuable part is what was sitting underneath the bug. Nobody had ever looked at what that lane contained. When somebody finally did, seven thousand rows resolved into three configuration decisions — which is the subject of a later section, and the best thing in this part.
The Pass
Here is the honest shape of the experiment, because it changes what the numbers mean.
The queue was worked by the model that built it, not by an analyst, and that was decided before the work began. A model's seconds per item are not an analyst's minutes, so no time per item is reported, and the records-per-analyst-per-month figure the claim above turns on is not given. That column is left empty for a human pass. Inventing it would have been the easiest number in the series to fake and the only one nobody could check.
What the pass measures instead is the question obligation two exists to answer: was the evidence on the item enough to decide it correctly?
The method, in the order it was done. A decision rubric was written first, before any item was read.
| Rule | Reads | Says |
|---|---|---|
| R1 | Both rows hold a subscriber id from the same payer, and they differ | Two people — two contracts |
| R2 | Date of birth differs beyond a transposition and the first name differs; or gender and date of birth both differ | Two people |
| R3 | Date of birth same or transposed, SSN-4 same, swapped or absent, first name same or a known nickname, gender same | One person |
| R4 | Anything else | Cannot say — leave it, and record what was missing |
Every clearable item was then decided from the work item alone — the two parties' names, dates of birth, gender, last four of the SSN, active identifiers and coverage; the agent's decision and its field comparison; the identifier's assertions. Nothing was looked up anywhere else. One line was logged per item as it was decided. Only after all 956 were closed was the manifest opened to score them.
Of the 921 items decided from the item alone, 866 came out right — ninety-four percent. The detail is where it gets interesting.
The identifiers: forty of forty correct. All forty were re-issues — a number that moved to a new person in a later file, which tier 1 declines to link on purpose. Every one was the same human, and every one was settled by R3. A re-issue at one payer moves a household's subscriber id and every dependent's member id at once, so one household arrives as two to four separate items; merging the pair through any one of them cleared the rest. One decision, several items, and the queue cannot tell you which items are the same decision.
The proposals: 826 right, 53 wrong, 35 left. Of the 35 left under R4, fourteen were nicknames the rubric's list did not hold, thirteen were dates of birth a person reading two dates would have caught and a transposition test did not, and eight were genuinely different people sharing a name. Twenty-seven of those thirty-five are the rubric's failures rather than the evidence's — the evidence was on the item.
And the number that answers the obligation: not one item of 956 needed anything looked up elsewhere. The second obligation held.
The Claim, Cut Down
The plan for this part made a specific promise, and it is worth quoting against itself, because the queue was built to prove it:
The platform cannot tell those 25 wrong merges from the 35 right ones. A person can, in seconds, because a father and a son on one contract is a shape they have seen a thousand times — if the queue puts the two records next to each other instead of handing over a uuid.
All sixty father-and-son pairs reached the queue, as 68 proposals. The agent called match on 56 of them at 0.85 to 0.93 and uncertain on 12. So the first half of the promise held: the queue surfaced every one, and it put the two records next to each other with every field the platform knows.
The worked pass then approved fifty of the sixty-eight.
R1 caught eighteen — both men holding a subscriber id at the same payer, and two contracts are two people. That rule never misfired once. The remaining pairs did not have that shape. In this corpus a son carrying his father's demographics is usually enrolled with a different payer, or one of the two rows carries no subscriber id at all. On every field the item can show — given name, middle name, surname, date of birth, gender, last four of the SSN — the two rows are identical. And two subscriber ids at two different payers is also exactly what one person with two coverages looks like.
The claim the evidence actually supports is narrower, so here it is in the place the claim was made: attached evidence turns a research task into a decision when the evidence distinguishes the case, and in this corpus it distinguishes one father-and-son pair in four. For the other three, the right answer was I cannot settle this — and the proposal lane has no way to say it.
None of which is an artifact of a seeded generator.
A few months ago, in a production Medicare system, one member's benefits were sent to a different member.
Same first name. Same last name. Same gender. Same date of birth, down to the day. The two people differed in exactly one field — the middle name — and the middle name did not carry enough weight to stop the match.
Everything downstream of that match behaved correctly. The benefits were delivered promptly and in full to the member the system had identified. They belonged to someone else.
That is the father-and-son shape outside a corpus, with real benefits attached, and it shows where a scoring model goes wrong — which is rarely in the arithmetic. Four strong fields agreeing will out-score one field disagreeing under almost any weight set, because averaging a disagreement into a population of agreements is exactly what a weight is for. The one field that mattered was the only one that disagreed.
The obvious escape is to stop matching on demographics and match on the identifier instead. In Medicare that identifier is the MBI, and on paper it is perfect for the job: eleven characters, no intelligence encoded in it, one per beneficiary, replacing the SSN-derived number precisely so that it could be unique and meaningless at the same time.
It is unique, and reassignable.
A beneficiary can request a new MBI. An authorized representative can request one for them. CMS can issue a new one unprompted when it believes a number has been compromised, which after a breach it does in volume. And the old number does not go invalid the day the new one appears — for dates of service before the change date either number is correct, and for a span claim that begins before it and ends after it, either number is correct. Two different strings, both legitimate, both belonging to one human being, with a date deciding which one applies.
The first warning most organisations get is an eligibility response carrying AAA 72, invalid member ID, on a patient who is plainly enrolled. Recovering from it means a historic eligibility search to find when the old number terminated, then a secure lookup at the contractor to get the new one. The contact centre will not read it out.
So the escape closes from both ends. The demographics could not separate two people, and the identifier cannot be trusted as a single current value, because unless every change in that number's history has been followed, the MBI in the file in front of you may be the right number for last March and the wrong number for today.
This platform has an answer to the second half of that, built in Part 3, and no part has described it in these terms. An identifier here lives as an assertion rather than as a column on a person — a payer, a type, a value, a start date, a status, and a clock recording when the platform came to believe it. A reissue earns its own row and supersedes the old one rather than overwriting it, which is the fix Part 11 shipped after a resent member made a reprinted card look like a data-quality incident. Forty of this corpus's queue items are that exact event. So the platform can answer which number belonged to this person on the tenth of March rather than only which number belongs to them now, and the span claim that straddles a change date has a defensible answer on both sides of the line.
It has an answer to the first half too, and the answer is a refusal. Tier 1, the exact-identifier match, is the only tier allowed to link on its own. The probabilistic tier stays switched off because no weight set has earned a threshold, and the agent's auto-approve band was never enabled. A pair with four fields agreeing, one disagreeing and no shared identifier therefore cannot be auto-merged by this platform at any confidence at all. It lands in the queue.
Which is where the good news stops, because landing in the queue only helps if the queue shows a person the middle name. That is the whole of obligation two: both records side by side with every field the platform holds, the agreements and the disagreement rendered at the same size, so the one differing field is the first thing a reader sees rather than a 0.03 adjustment buried inside a score. An analyst looking at that pair needs no instruction about what to look at.
And then, having seen it, they would need a way to say that two people this alike cannot be told apart from a file.
Which is the finding this part turns on. Obligation four got built for one lane. dispute exists for an identifier; a proposal can be approved, rejected, or left where it is. Leaving it records nothing at all. The item reappears tomorrow in front of a different person, with the same evidence and the same impossibility.
A person who cannot settle a pair and is offered only yes or no will, at volume, pick one. Diligence has nothing to do with it. A queue that counts throughput and has no word for doubt is built to produce exactly that, and it produced it here fifty times over, in a corpus where the truth was knowable the whole time.
The fifty wrong approvals are now written into the corpus database as links, under the worked pass's actor. And because a link a person approved is not in the link lane, nothing will ever surface them again. The queue removes the item a wrong decision closes along with the items the right decisions close. A merge that should never have happened looks, from the queue, exactly like work completed.
There is one consolation in the scoring, and it is a real one. Of the 710 proposals the agent called match, 58 were two people. The pass approved 46 of those anyway — but it also caught seven two-person pairs the agent had only flagged as uncertain, and on the uncertain band as a whole it beat the agent comfortably, because 94 of those 206 proposals were SSN keying errors. A swapped pair of digits is a rule to a person and a source of doubt to a model.
Where This Pays for Itself: The Rule That Came Back
Go back to the 7,064 advisories.
They are three decisions. Register companion-guide schemas for the two payers that have none, and 4,187 warnings stop. Declare ACME's extension keys, and 2,877 records carrying two warnings each stop. Each of those is a ruleset_versions publish — versioned, activated, and dry-runnable against last month's files before anybody commits to it. Part 6 built exactly that machinery and this is the first time anything has pointed at it.
Which is why putting them in a work queue was the wrong instinct twice over. An analyst who recognises the shape on item one has nowhere to record it and 7,063 rows still beneath it — and the thing they recognised was never an item at all. It was a configuration change, and it belongs in front of whoever owns the rule set, once.
The proposals say the same thing from the other direction. A hundred and one approvals in this pass rested on the SSN has two digits swapped. Fifty-two rested on the date of birth has two digits transposed. Both of those are R3 — a rule, written on paper before the work started, that the agent does not apply and the gate does not hold.
Forty pairs resolved the same way is one rule, discovered forty times and paid for forty times over.
This is the argument for the human in the loop that the series has been circling for eleven parts without landing, and it has nothing to do with the model being temporarily insufficient. The chair is where new rules are discovered. A platform that routes its hardest cases to a person and never reads what that person did is burning its best source of rule candidates to keep a queue count down.
The queue is the instrument. Nothing in this platform currently connects what it collects to the place rules live, and that is now the clearest thing on the roadmap.
What the Chair Is Worth
Nine hundred and twenty-one items were decided from the item alone. Fifty-three of them were wrong, and every single one was a pair the platform cannot distinguish either. That is 5.8 percent — concentrated entirely in the cases where the evidence genuinely does not separate two people, and zero percent everywhere else.
The corpus is not a month of real traffic. A third of its households are resent by construction, so fourteen percent is an upper bound rather than an exception rate, and it is not offered as one.
But the shape holds, and the shape is the point. When the evidence is on the item, a person settles it correctly and fast. When the evidence is not on the item, no amount of confidence calibration upstream helps, and the only safe verb is the one the platform had not built.
Eleven parts of this series have been about getting the machine to decide more. This one is about what happens to everything it cannot, and the answer turns out to be an argument for building the queue first rather than last. Every threshold in the preceding ten parts was a decision about this chair, made without looking at it.
The four obligations are met, three of them completely. The platform can hand a person one list instead of four, with the evidence attached and a way to say I have this. It still cannot let them say I could not settle this about the one lane where that sentence was needed fifty times in a single afternoon.
Part 13 is the second format: the 270 eligibility inquiry, the 271 that answers it, the AAA segment that explains why it cannot, and the dependent who arrives with no identifier of their own. Eight hundred and thirty-nine of this corpus's re-arrivals are exactly that person — a true duplicate the platform cannot currently catch, because the only thing that would identify them is the household they belong to.
They are in the queue right now. Nobody can tell them apart from the people who are already there.
This is Part 12 of Building the Platform, a build-in-public series on a healthcare enrollment data platform. The corpus, the people in it and the payers are synthetic; the generator is seeded and reproducible, and the ground-truth manifest is the only reason any of the numbers above can be checked.
