Ctx Merge

ctx-merge — Converge Without Losing or Distorting

Routing destinations (spec / decisions / scratch) follow the lifetime model in ../ctx.

Execution Procedure

converge(sources) → living_kb_update + conflict_choices

# STEP 0 — Scale check (before anything else)
if sources exceed one context, or constraint 2 (coverage split) is unexecutable at this scale:
    run this ENTIRE procedure once per batch    # see § Rolling batches
    # batches share ONE carried-forward framing; each batch still runs STEP 1–7 in full

# STEP 1 — Extract (provenance starts here)
claims = []
for src in sources:
    claims += extract_atomic(src)          # each conclusion decontextualized, tagged {source, span}

# STEP 2 — Cluster + relate (map-reduce, NEVER a recursive prose merge — see § What "NEVER recursive" bans)
clusters = cluster_paraphrastic(claims)    # dedupe equivalents
for c in clusters:
    relate(c)   # entail → keep one + merge provenance
                # neutral/complementary → keep both
                # contradiction → DO NOT reconcile → promote to a decision point

# STEP 3 — Ledger (make every disposition explicit; a drop is a recorded decision)
ledger = disposition_ledger(claims)        # each: keep→spec/§ | keep→decisions/NNNN | superseded | drop+reason
assert every_source_claim_has_a_disposition(ledger)   # GATE — no invisible absences

# STEP 4 — Assemble (information SUPERSET, only-more-never-less) + conflict register
draft = union(non_conflicting) + conflict_register     # every line carries its source

# STEP 5 — Human adjudication (LLM induces, human judges)
choices = choice_cards(conflict_register)  # choose A / B / keep both / UNSURE + comment
apply(human_clicks(choices))               # non-conflicting superset defaults to keep

# STEP 6 — Faithfulness audit (MANUAL discipline — there is no faithfulness_audit() tool)
#   YOU MUST re-decompose the draft and check every claim back to a source, using a
#   DIFFERENT agent/model than the merger (a model grading itself shares its blind spots).
#   This is a step you perform, not a function you call. See "Faithfulness audit" below.

# STEP 7 — Verify the four constraints, then sink
#   Walk the four-constraint checklist by hand (named target · coverage split · boundary ·
#   destination); fail any → fix the gap, re-walk. Then sink:
sink(draft, ledger)                        # edit spec in place / append decisions per destination
apply("../ctx/references/consistency.md")  # single-source · same-change · verify-canonical · gate — before committing

# STEP 8 — Self-verify, then hand back in VALUE terms (automatic, not on request)
landed = self_verify(batch)                # (a) did the round follow its OWN declared procedure?
                                           # (b) enumerate what is now IN the artifact — read it, not the ledger
handback = value_handback(landed)          # what the SOT now asserts that it could not before
Skill("ctx-report", handback)              # the format; this step owns WHAT goes in it
# The two halves are one step on purpose: you cannot state what a round was worth
# without first confirming what actually landed. See § The round-close self-check.
# A merge that ends at sink() is not finished. If the human has to ask "so what happened?",
# this step did not run — and no count of claims, losses, or agents answers that question.

The lines above are a procedure you execute by hand, not an API. The faithfulness audit and the four-constraint walk name disciplines you must carry out (below) — no such tool exists; do not treat them as callable.

The two failure modes (why naive merging fails)

• False negative = silent drop. A high-value conclusion gets dropped. Invisible — you can't see a missing thing by reading the output; it surfaces later at build time as "we keep making the same mistake." Empirically the harder class to catch (LLM recall ≪ precision; summarizers drop key items routinely).
• False positive = stain. Wrong or trivial content kept as if true. Visible, but only on careful read.

Human merging worked because of unspoken tacit judgment (Polanyi: "we know more than we can tell"). An agent can't replicate that, so you MUST replace it with an explicit harness — not a smarter prompt.

The merge pipeline (map-reduce, NEVER recursive)

1. Extract atomic, decontextualized conclusions from each source, each tagged {source, span}. Provenance starts at step 1.
2. Cluster equivalent/paraphrastic conclusions (dedupe).
3. Relate within a cluster: entailment → keep one + merge provenance; neutral/complementary → keep both; contradiction → do NOT reconcile — promote to a decision point.
4. Assemble = union of non-conflicting conclusions (information SUPERSET, only-more-never-less) + a conflict register, every line carrying its source.
5. Faithfulness audit (a discipline you perform, not a tool you call): re-decompose the output and check every claim back to a source — catches silent drops and inventions. You MUST run this with a different model/agent than the merger (a model auditing its own output shares its blind spots). There is no faithfulness_audit() function; it is manual work: dispatch a fresh agent, hand it draft + sources, ask "which source-claims are missing, which draft-claims have no source?", act on what it finds.

Prompt rule: instruct the merging agent to emit atomic claims with source IDs and, on conflict, output both variants tagged CONFLICT — never silently pick one.

What "NEVER recursive" bans — and what it does not

It bans recursive prose compression: summarizing a summary, then merging that summary with the next source, so that whatever finally decides never sees the original wording. Every reduce step reads source-tagged atomic claims, never a previous step's prose.

It does NOT ban handing every mapper the same shared context — a carried-forward framing, a glossary, the current conclusion set. That is not compression, it is a common vocabulary, and the mappers still read their own sources verbatim. Reading this line as "each mapper must work blind" produces piles of mutually untranslatable fragments and pushes the translation onto a reduce step that never read the originals — which is the exact loss this skill exists to prevent, arrived at by way of obeying it.

Rolling batches (when the corpus exceeds one context)

Trigger. The sources do not fit one context, or constraint 2 (coverage split — state per source what is covered vs not) cannot actually be executed at this scale. Against 35 sources that constraint is unenforceable; against 3 it is natural. That is the tell.

Shape.

1. Order the sources newest-first. The newest carry the current vocabulary, and they become the lens the older ones are read through.

   This ordering is a one-way contract, and it is the load-bearing invariant of the whole method: a backward batch may only RECOVER what was lost. It may never overturn a conclusion a later source already reached. The reason the newest are read first is that they are closest to the truth; reading an older source afterwards cannot make it closer. So an old source's material has exactly two legitimate fates — it fills a gap the later sources never addressed, or it is superseded. There is no third. A datum found in an older source does not reopen a reading that a later source demoted, even when the datum is genuine. One merge violated this at close-out: a lower-tier report carried an experimental figure showing a safety score falling, the orchestrator added it, and wrote alongside it that hardening lowers the very dimension it claims to raise — which was precisely the reading a later revision had demoted from a gate to a diagnosis, on the owner's own argument that gating by category is wrong. The number was real; the inference restored a retracted position. The test before adding anything from a backward batch: does the framing already answer this question? If yes, the only question left is whether the old source adds evidence for the answer that stands — never whether it revives the answer that fell.

   And check it mechanically, because "the framing already answers this" is a lookup, not a memory. Nothing in the procedure makes a batch read the conclusions already landed before it writes. Add one step: for each entry a backward batch is about to write, take its load-bearing terms and the ctx-internal components it names — folders, decision IDs, lifecycle classes, shipped files — and look each up in whatever disposition lists the artifact already carries. On one merge the artifact held three such lists (a 25-file rewrite table, a 23-ADR A/B/C grading, an execution checklist), and no batch had ever queried them; the join was one script. A verdict already recorded in the artifact is not background — it is the incumbent, and the new entry has to answer to it.

   A corollary about quoted blocks, learned by breaking it. A block labelled verbatim is a claim about what one passage of one source says, not about a topic. The same close-out appended a fourth data row to a block attributed to a specific revision — a row that revision never contained (measured afterwards: zero occurrences of either figure in it). The figures were accurate and came from the underlying paper; the block still became a forgery, because its label promises provenance rather than correctness. Never add a line to a verbatim block. If the extra material belongs, it goes in a new block with its own attribution.

2. 3–4 sources per batch.

3. Batch 0 produces the framing — a structured statement of the current conclusions, written in the destination format (so the format gets its first real test on the smallest batch, not after the last one).

4. Every later batch takes previous framing + its own sources and returns an updated framing.

5. The entire procedure above runs INSIDE each batch. N batches = N complete extract→cluster→ledger→assemble→adjudicate→audit cycles. This is not a decomposition of the procedure — it is the procedure at the scale it was designed for.

The comparison object is claim ↔ framing, not claim ↔ claim. Each batch's agent holds the already-converged half and reads the old sources through it, translating yesterday's wording into today's on the spot. There is no "organize it all at the end" step, because organizing started at batch 0.

But that comparison runs on conclusions, and a claim can die at its premise while its conclusion still looks live. Tier rules and superseded-by-newer both ask does the framing say the opposite of this? Neither asks is the framing in the middle of demolishing the thing this stands on? On one merge a batch adopted an older source's admission test and anchored it to a line in the product's own README — while two entries already in the framing recorded a newer, higher-tier source proposing that that exact line be torn down, and a third concurring. Nothing contradicted the conclusion. The ground under it had been condemned. So before writing any entry that carries normative weight, take the anchor it rests on — the quoted README line, the ADR, the existing criterion it invokes — and search the framing for it. The test is not "has this been said before"; it is "is anything here retracting what I am about to stand on." A conclusion is no more alive than its premise, and the premise is the half nobody compares.

A related check on the same entry, and it is cheaper: does the source itself route this to the human? Reports that end in a decision list mark their own items — needs your call, already settled, no action, not a product action at all. That list is an enumerable block. A claim the source flagged as awaiting the human's judgement cannot be written as a chosen answer, and the tell that this went wrong is self-contradiction inside one unit: a normative prefix asserting the answer, beside an open-question field recording that nobody has approved it. One batch shipped three of those. Enumerate the source's decision list at extraction and carry each item's status onto whatever it becomes; an unapproved proposal is a quotation or an open question, never a rule.

And when the thing being adopted is a taxonomy, ask what criterion sits under it. A four-category scheme applied as an admission gate is a lookup table; it is useful as shorthand and it is not a criterion, because it cannot say why those are the categories. The same merge had already recorded a source retracting an earlier gate for precisely this reason — classifying by category and routing by category is the thing this round just abolished — and the next batch wrote a category gate into the framing anyway, describing "turning a judgement call into a lookup" as the improvement. Which is the more general lesson: a rule that has landed in the artifact does not thereby govern the next batch. Rules bind when they are an action someone runs at the start, not when they are a sentence someone could have read.

Verification burden scales with how much was written after a source, and that number is exactly computable. For an old source's conclusion to still hold, nothing published since can have overturned it — so the set that must be checked against is everything downstream of it, and reading newest-first means that set grows monotonically as the batch number rises. On one 35-document corpus it ran 5, 8, 11, 13, 15, 18, 21, 24 across the first eight batches and 26, 29, 32, 34 for the last four. The control case is sharp: the one batch whose sources were contemporaneous with the newest material had a downstream set of 2, and it was the cheapest and cleanest batch of the run — not because its sources were simple, but because almost nothing had had the chance to retract them. So the two failure modes need separate budgets: extraction loss scales with source volume, stale-premise risk scales with downstream mass, and staffing a batch off the first number alone leaves the second unfunded — hardest exactly on the last batches, which is where it is easiest to assume the work is winding down.

Three things make a rolling merge cheaper without removing a single check, and all three were found too late to pay off on the run that found them. Measured on one 13-batch merge: 97 hours wall-clock, 37 hours of actual activity, 47 agents.

1. Put the audit's verbatim requirement in the FIRST batch's spawn prompt, not the eighth. Every lost-content finding must carry the source's own words, quoted, alongside the row it came from and the destination it belongs in. That one sentence is what turns closing from generation into transcription, and transcription needs no agent. On that merge the first seven batches averaged 4.5 agents each and the last five averaged 2.4 — a 47% cut, from one line. It was written down at batch 8. Written at batch 0 it would have saved roughly fourteen agent-rounds.

2. Carry a gate-hygiene rule from batch 0, because the same defect recurs in a new costume every time. On that merge, a check that only sees what its pattern assumes fired at least eight times — bold-only markup, one arrow glyph out of four, case sensitivity, an HTML tag splitting a phrase, a regex eating BQ-024 as Q-024, a table indexed by term used to verify things that have no term, a write whose assertion checked its anchor but not its output, and an identity satisfied by both the right and the wrong answer. Not one was caught by a check; every one was caught by the next agent. The rule that stops all eight is three mechanical steps: enumerate the full set, subtract what was covered, report the complement with its denominator beside it. Cheap, and it retires whole rounds of rework.

3. Do not let the spawn prompt become a second copy of this document. On that merge the merge-agent prompt went 448 → 647 → 737 → 815 lines across four batches as each batch's lessons were pasted in, and every agent reads all of it before starting. Measured per section: 564 of those lines (69%) were batch-invariant — and every one of them was a rewritten restatement of rules already in this file, which was 357 lines at the time. The saving is not cutting the lessons; the lessons are load-bearing and none can go. The saving is deleting the duplicate: have the spawn prompt name the sections of this document the agent must read, then carry only what is genuinely specific to the batch (which sources, which same-tier pairs, which named obligations, which numbers). ⚠ And the stronger argument is correctness, not speed: a hand-made restatement drifts from what it restates. The agents were reading a paraphrase while the canonical rules were being maintained elsewhere — the single-source violation this whole procedure exists to prevent, committed against its own tooling, for thirteen batches.

And be honest about what the wall-clock number is measuring. On that merge 62% of the elapsed time was nobody working — the orchestrator waiting on the human. Reporting "it took three days" when it took 37 hours of activity invites cutting the checks, which is the one thing that cannot be cut: on the final batch alone the audit found six content losses and the third pass found two more plus eleven permanently mis-routed pointers, and after the final batch there is no later batch to catch them.

The framing is a SUPERSET per batch (STEP 4): a batch only adds. Removing something requires a conflict card — never an in-passing edit.

But "only add" does not mean earlier sentences stay true. A framing accumulates self-referential claims — "this is the only place X is used as a criterion", "X appears seven times", "nothing here covers Y" — and every later batch can falsify one by adding. The superset rule protects the content and says nothing about these, so they rot silently while the document is formally correct. Before finishing a batch, re-check every claim the framing makes about itself — counts, uniqueness, absence — and restate the ones your own additions broke, leaving a line saying what it used to assert. Do not delete them: they carry real information and merely need recomputing.

Two of those self-referential claims look identical and MUST NOT be updated the same way. A framing accumulates sentences of the form "scope: what we have read so far, sources 22 through N." Some are facts about the merge's own progress — bump them. Others are the boundary on a claim (earliest / only / most complete), and bumping one asserts that the claim was re-checked against the newly-read sources. On one batch, seven such sentences were stale and four of them could not honestly be advanced, because advancing them substitutes "we have read those sources" for "we looked for this claim in those sources" — an order of magnitude of evidence, one character apart in the file. Advance a claim's scope only where the same measurement was actually re-run on the new material; otherwise mark it as lagging and leave the number. The corollary is cheaper and easier to miss: content read in a batch does not update other places' statements about what has been read — one file still said a source was outside the reading range while the same batch's ledger built an argument on it. Sweep that phrasing as a class.

The structural defect, and its hedge. The framing evolved out of these same sources, so it inherits their blind spots; filtering old material through current conclusions is structured confirmation bias. That is the price of rolling, and it is real. The hedge is the mandatory unplaceable field (below), which asks the opposite question — what is in here that the framing has no place for?

The hedge has a characteristic signature, worth recognising because it looks like a defect in the framing and is not. Newest-first means the framing inherits the newest sources' agenda, including the topics they had stopped discussing. Read far enough back and you reach the rounds where those topics were live — and they arrive with nowhere to go, because the skeleton was built by writers who had moved on. On one merge this surfaced as four terms in the merge's own glossary having zero occurrences anywhere in the framing. Nothing was wrong with the framing; it was the bias becoming visible at the one moment it could be caught. Expect it when the batch order crosses the point where the corpus changed subject, and treat it as the field succeeding.

Audit every batch, not once at the end. An end-of-run audit has to re-read the whole corpus to answer "which source claim never arrived" — the same arithmetic that forced batching in the first place, merely postponed. Per batch, the audit reads only this batch's sources plus the framing delta, and STEP 6's "must be a different agent" is satisfied for free by opening a fresh one each batch. It asks exactly two questions, which are the two ways a rolling merge loses things:

• Q1 — which conclusion in this batch's sources never reached the framing and has no disposition in the ledger? The classic silent drop.

• Q1b — for each claim the ledger dispositions as keep → <destination>, go to that destination and read: is the content actually there? A ledger row asserting a landing is the one kind of absence an auditor will not go looking for — the row itself says the checking is done. Empirically the sharpest of the three: in the first batch that ran this procedure, four of eight losses were catchable only by this question, and every one of them sat behind a row reading keep. Verify per ledger row, not per destination. Several rows routinely name the same Question, and checking destinations makes that Question look landed as soon as any one of them arrives. One batch sent four rows to a single Question, one landed, and the destination sampled clean — three losses behind a green check.

  Running the same check three times is running it once. One merger executed its landing read-back three times and reported 164/164; an auditor opened the destinations and found 26 rows absent. It had not been careless — it had used one method each time (take a distinctive string from the source, search the output for it), and that method can only surface what is in its probe set. Two entire classes had no probes, so all three passes were green. Worse, it had written this exact limitation into its own ledger before the third pass and then ran the third pass with the same candidate list; naming a failure mode feels like handling it. So the repeat MUST be non-isomorphic: enumerate from the ledger side — every keep row gets its destination opened — rather than from the source side. And match the granularity to the unit: one source block held two to seven independent questions, landing the first made the whole block read as landed, and two rows the auditor itself had passed turned out to be one-of-two and one-of-five.

  There is one absence this question cannot see at all, and it is structural rather than careless: a ledger row whose destination is not a unit of the artifact's addressing scheme. The read-back enumerates the artifact's units — numbered Questions, sections, whatever the scheme is — so a row pointing at a sibling file, an appendix, a prose paragraph, or nothing is never in the candidate set. It is not reported missing; it is not reported at all. On one merge the class ran to dozens of rows and a cross-batch pass found four losses inside it. Add a gate that enumerates the complement: every non-drop row whose destination does not name a unit. Report the number even when the rows are legitimate — several are, and saying so is the point, because an unstated zero and an unlooked-at zero are again the same file.

  Then watch the gate itself, because this is exactly where a hard-coded pattern rots. Such a gate gets written as a one-line grep anchored on the row-ID shape of the ledgers that existed the day it was written. Ledgers written later name their rows differently — the sources change, so the prefixes change — and the gate then matches zero rows in the whole file and reports a clean zero for a ledger it never read a line of. On one merge the gate had been quoted in four documents as "repo-wide N, and the last three batches are all clean"; re-derived with the row-ID scheme detected per file, three of those clean zeros turned out to be files where the pattern matched nothing at all, and the total was nearly double. Detect the ID scheme per ledger rather than hard-coding it, and print the denominator next to the hit count — a gate that reports 0 hits without also reporting 0 rows examined is indistinguishable from a gate that works.

  That sentence is not enough on its own, because a destination-level check can satisfy it while reading as compliance. A later batch quoted this very line, ran the check by destination — did this Question receive any of this batch's edits? — and reported it as row-level verification. Its first pass did find three losses, which is what made the method look sound; but those three destinations had received nothing at all, the one case where the two checks agree. Every destination that took eight blocks and dropped two passed clean. That batch lost eleven rows this way, more than every other failure mode in it combined. So state the assertion in a form the wrong check cannot satisfy: this row's own content is readable at the destination — not the destination changed. The tell that you are running the weak version is a destination that received other content in the same batch and was therefore never opened at the paragraph level. Read the destination; do not grep for it. A merger that self-checked by grepping each destination reported 59/59 landed; an auditor who opened 30 of them found 9 empty. Grep proves the heading exists, which is not the claim being made. It errs in both directions, too: a later batch got a zero for content that was there, because the search string came from the ledger's wording rather than the framing's — and acting on that zero would have written the passage in twice.

• Q1c — for each assertion carrying normative weight in the framing, go find the sentence in the sources: is it there? Q1 and Q1b both hunt the silent drop; this one hunts the other failure mode this skill names — the stain. Without it the audit tests one of the two and reports clean. In the first batch it was the only question that caught six fabrications, among them an unsourced design decision and a MUST contradicting its own figure two lines above.

• Q1d — which OPEN did an earlier batch name this batch to answer, and did it? Before answering, check the question is answerable at all: newest-first means later batches read earlier material, so an OPEN asking what became of something afterwards can never be settled by any batch that follows. Two such pointers went unanswered for three batches before anyone noticed they were malformed at the moment they were written, not merely neglected. A backward-looking question ("where did this come from") routes to a later batch; a forward-looking one ("what happened to it after") routes to the phase that reads forward, or to the human.

  Routing to the human is a routing decision too, and it fails in exact mirror image — which is why nobody audits it. A pointer to a batch looks like a claim and gets checked; → the human reads as a neutral fallback, as though escalation were the absence of a routing choice rather than one of its outcomes. On one merge, four backward-looking questions — which round retracted this, where did that reservation come from, why was this candidate picked, where does this idea live now — had all been handed to the human while a scheduled batch could answer each. One was answered in full by the very next batch, from sources already on the plan. So apply the same test before writing → human that you apply before writing → B0X: is the answer in newer material or older? If older, it belongs to a batch. Sweep the class by machine (grep for the escalation marker across the artifact) rather than catching them one at a time: that merge had thirty such pointers and had never read them as a set. A framing routes its own unfinished business forward ("→ decide in B04"), and nothing walks back to close those. They expire in silence: the batch runs, the question stays open, and the pointer now names a batch that has already finished. Enumerate them by machine at the start and account for each at the end.

• Q2 — which entry present in the previous framing is absent from this one? Squeezed out during carry-forward — the failure mode rolling has that a single pass does not. Mechanize it: keep the framing in git, and git diff's deletion lines are the candidate list; the auditor only judges "replaced by better wording" vs "gone". Judge that by semantic units, not by prefix and length. The obvious mechanization — a deletion is safe if some added line starts the same way and is longer — accepts a narrowing as an extension: one deletion replaced v13/v14/v15/v16 with v10–v16 and passed, safe only because the new range happened to contain the old one, not because anything checked. Split each deleted line at its separators and confirm every unit survives somewhere in the hunk. The cheap check and the real one agreed on all thirty deletions that day, which is exactly why the cheap one read as verification.

Any question returning a finding → the batch is not done. Backfill, then re-audit.

Backfill discipline — the second pass has its own two failure modes. Both were observed on the first batch ever to run this procedure, in this order:

• The fix injects what the sources never said. Round one dropped content; round two invented it. Filling a hole is generative work, and a merger that marks its inferences scrupulously in normal operation will state them flatly while patching. So the re-audit MUST ask "does the backfill contain anything with no source?" — not merely re-check the original findings — and the backfilling agent MUST be told to mark an inference as an inference. This is the worse direction: an invented claim leaves no trace that it was ever absent, while a dropped one at least still exists in the source.

  One batch fabricated once per repair round, weakening each time: a fact (a claim about a source, refutable by one grep), then a reading (a reconciliation the source never proposed, in the same argumentative slot), then a count (a number where the source gave none, headed by the word "verbatim"). None was a knowledge error. All three filled the same kind of gap: a passage of reasoning that needed one more piece to read as finished, where supplying it was easier than leaving a hole. That makes it a property of the writing, not of the writer, so "be careful" does not address it. What does: three sentence shapes account for all of them — the reconciliation ("these don't actually conflict", "it's a division of labour"), the count ("N locations", "all four"), and the connective ("taken together", "therefore"). Reaching for any of them is the cue to go back to the source, because each one asserts something no single quoted line contains.

• The loop has a fixed point, and you have to notice it. Each repair round costs an agent and carries a fresh chance to fabricate, so it is only worth spending while the findings are still about lost content. Once an audit's remaining findings are mechanical and precisely located — a wrong count, an unmarked inference, a pointer to the wrong row — apply them directly instead of dispatching another pass. The signal is an auditor writing some version of the evidence is broken, not the content, usually alongside an independent sample that came back clean. Two batches ran this way: the first looped to seven agents before closing by hand, the second closed by hand at four and delivered more. The generative step is what introduces stains, so removing it is not a shortcut — it is the fix.

  Closing by hand removes the agent, not the generation — and nothing audits the orchestrator. The whole apparatus points outward: spawn prompts, a different model for the audit, three forbidden sentence shapes, an honest reach count. All of it constrains agents. The orchestrator writes too — every finding transcribed by hand arrives with a connective sentence explaining what it means, and that sentence is generation under a different name. On one merge every defect the owner later caught had been produced during a hand close-out, by the orchestrator, after an audit had certified the batch: a line added to a block labelled verbatim that its cited revision never contained, an inference reviving a reading a later revision had demoted, and two passages recorded that changed no decision. So when you take the hand path, take the audit's constraints with it — state the reach count for your own additions, keep the anchor lookups, and treat any ⇒ you write beside transcribed material as a claim needing the same grounding as the material. Removing the agent halves the risk; recording it as zero is what turns the other half into shipped defects.

  And grade the audit's findings for relevance, not only for recall — nothing in the pipeline does. A faithfulness audit is built to find everything: it reports each loss with its rarity, and "unique source — this exists nowhere else" reads as a reason to restore it. It is not one. Uniqueness says nobody else recorded it; it says nothing about whether anyone needs it. On one cross-batch pass eighteen findings all carried that label, all were transcribed, and the owner struck three on sight — one overturned by a later source, one an external work's internal analogies, one supporting a conclusion nobody disputed. Add a second gate before transcribing: delete this and ask which decision in the artifact loses its grounds. If none does, it belongs in the audit report and not in the artifact — the report is where it stays findable at zero cost. The audit optimises recall by design; the orchestrator owes the precision pass, and "it is a genuine loss" does not discharge it.

  The lost-content-versus-mechanical split is a proxy, and once you improve the audit the proxy comes apart from the thing it stood for. What actually decides whether another pass is worth an agent is: does putting the content back require anyone to reopen a source and decide what to extract? That is the generative step, and it is the only thing a backfill agent adds. So once the audit's spawn prompt requires every lost-content finding to carry the source's own words verbatim, alongside the row it came from and the destination it belongs in, the closing work is transcription — and transcription does not need an agent. One merge ran five batches on the ratio, then hit a batch at nineteen content losses against eighteen mechanical — a split that had dispatched a backfill round twice before — and closed it by hand in one pass, because all nineteen arrived quoted. The earlier dispatches were still correct: their audits had no such requirement, so the content genuinely could not be replaced without re-reading. The criterion never changed; the input did. And the risk of dispatching anyway is measured, not theoretical: one backfill round introduced two fresh elisions of its own, because an agent handed a report still reads the source and still edits while it copies.

• The fix patches the instance, not the class. When a finding names two examples of one pattern — say, the truncated second half of a bulleted source note — the backfill repairs exactly those two and leaves the rest of the pattern standing. Name the class in the finding and require a re-sweep of it, or the same shape returns next batch wearing a different line number.

  Then size the class from the source, never from the ledger — this is where the sweep quietly fails even once you are doing it. One batch swept every class it had named and reported each one clean; an auditor re-derived the same classes from the source documents and got: owner-quote blocks 11 → 24 (thirteen of them landed nothing, and eight had no ledger row at all), §Sources entries 3 → 22, whole tables 6 → 16 (three landed nothing), editorial ellipses "zero" → 165, scope-limiting sentences 13 → 50. Nothing was lied about. A class defined by counting ledger rows has exactly the ledger's field of view, and what is missing is by definition outside it — so the sweep confirms the ledger against itself and returns clean with the losses untouched. Enumerate the class's members from the source with a command, then check each against the artifact. The tell is a class whose size is a round-ish small number that matches how many rows mention it.

The round-close self-check (STEP 8a) — verify your own round before you value it

Every batch and every round ends by checking its own work, before anything is handed back. Not the faithfulness audit — that is STEP 6, it runs on a different agent, and it asks did the content survive. This one is the merger's own, it asks two questions the audit does not, and its output is the input to the value handback.

• Did this round do what it said it would? A round declares checks — a landing read-back, a class sweep, a contradiction screen, a stop-signal self-check. For each one: did it run, and did it produce output somebody can re-run? A declared check with no transcribed output did not happen, however sincerely it was intended. The failure mode is specific and repeats: naming a limitation feels like handling it, so a round can write down exactly why its method is insufficient and then run that method again.
• What is actually in the artifact now? Enumerate it by reading the destination, not by reading the ledger. The ledger records intent; the artifact holds the result, and the whole reason STEP 6 exists is that those diverge. This enumeration is not a count — it is a list of the conclusions the artifact can now state.

Why the two halves are one step. You cannot say what a round was worth without knowing what landed, and a value claim built on the ledger's word inherits every gap the ledger has. Coupling them also makes the check self-interested: the merger now needs an accurate landing list for its own report, rather than producing one because a rule says to. A round that cannot enumerate what it deposited has not finished, no matter how clean its counts are.

It also makes the checking better-aimed, which is the second reason to do it. A generic audit asks "is anything missing?" against the whole surface. A round that has just written its own value statement knows exactly which conclusions it is claiming credit for — so it can verify those first, and hardest. The claims a round is proudest of are the ones whose loss would be least visible, because everyone assumes the headline landed.

The value handback (STEP 8b) — a merge is for the conclusions, not for the merging

The unit of value is a conclusion the SOT now carries that it did not carry before, stated in the product's own terms. Not a Question that was added, not a claim that was dispositioned, not a loss that was recovered — those are the machinery. The owner commissioned a merge to make the product know things; the artifacts are how, and nobody asked how.

The failure is stable and worth naming because it survives every other kind of quality. A batch closes, the merger reports agent counts, landing rates, l

…(truncated)