Planners read facts, emitters read commands: dissolve the walk and the leaf zoo

The four points say what the new path is. This says what the condemned path is owed, because the instinct runs the other way and did during slice one.

The walk is condemned, not serviced. FieldBuilder, BuildContext, TypeBuilder, the walker/ package and the classifier passes beside them are the thing being deleted, so three rules follow.

Their size is not a metric. FieldBuilder growing while relations land is evidence of nothing. The number that measures this item is leaf dispatch inside plan/, which counts the new tree reaching into the old model. A line count over condemned code measures the size of the thing being removed, not the progress of removing it.

They never read the store. This holds by construction today: the fact writers and the store readers live in graphitron-model, the only file under rewrite/ naming the store’s tables or its handle is GraphQLRewriteGenerator, the pipeline driver that opens it, and the walk itself holds no reference to any relation. Plumbing a relation into a condemned pass buys one spelling in a file with no future, and reuse between the old path and the new one is exactly what makes a cutover hard. When a derivation inside the walk looks like it wants to be a relation, the relation lands when the new path needs it, stated from facts on its own terms, and the old pass dies untouched rather than being rewritten to agree. The worked example is the mapping-constant dedup pass: its grouping and its handler-list fingerprint are pure functions of captured facts and could be a relation today, and making it read one would be the mistake, because that pass is deleted rather than migrated.

They are not deduplicated or improved. A second spelling of a rule inside condemned code is not debt. It is scheduled for deletion, and touching it spends effort on the wrong side of the line.

One consequence worth stating because it reads as a problem and is not. The old spelling is never reconciled with the new one; it goes away when the new path covers the coordinate. The real finding is the opposite shape, a producer in plan/ deriving something the store could have stated.

A relation with no reader is not a slice getting ahead of itself. It is a relation nobody has priced, placed, or proven a consumer for, and the measurement is what settles this: of the 48 relations the conditions arc authored, 39 have no main-source reader today, because the producers they were authored for were never converted. Store deliverables landing ahead of the producers that read them need a bound on how far ahead, and the bound is one arc, stated under "What this item does not author".

And the pins are not monotonic gates: PLAN_LEAF_REFERENCES rises when a capability lands as leaf dispatch and falls when it dissolves onto facts, so a gate demanding it fall every slice would block the first half of every cycle. What it makes visible is a stalled relocation, which is a shape in the trend rather than a value in one slice.

The one thing both paths must share is what the output is called. Both emit into one output package during the cutover, so a generated unit or constant has to carry the same name whichever path minted it. That is why the naming vocabulary in GeneratedUnits is imported by condemned code and why that does not violate the second rule: it is an output contract, not a derivation. Nothing else crosses.

This item converts readers. It does not author facts, and the rule is absolute rather than a preference to be weighed per increment, with one exception fixed by kind rather than judged per increment: a validator check’s own detection, bounded below under "The one exception".

The store says so. The intent_ family header in graphitron-model.sql reads "DEPRECATED, THE WHOLE FAMILY" and states the rule for anything landing there: do not. A family with no owning gatherer is where a fact goes when nobody placed it, and the cost is that the fact arrives late, gets re-derived by the next reader from a slightly different angle, and ends up materialized because materializing is the only lever available at that depth. A missing fact is captured as early as it can be captured, in the family that owns the corpus it comes from, where every reader reaches it and none re-derives it. docs/architecture/explanation/fact-model.adoc carries the rule for deciding which family that is.

Which means a missing fact is a filing, not a deliverable. When a producer this item is converting needs a verdict no relation states, the increment stops and files the fact against the store programme, naming the producer as its consumer. It does not author the relation, and it does not convert the producer against a leaf in the meantime. The producer waits, and this item converts one whose facts are already there. There is always one: the availability check below ranks all five, and the readiest needs nothing authored at all.

And an arc ends at a producer conversion. No arc opens until the previous one’s producer reads the store. This is the stopping condition the conditions arc did not have, and it is the whole of what stopped it: every increment in that arc was individually defensible and the sequence had no terminating case. An arc that has authored a relation and not converted a producer is not making progress that the next increment will realise, it is accruing a debt that the census measures at zero.

The one exception: a validator check’s own detection. A validator check migrates by becoming a detection, a relation whose rows are the schema’s defects, and this item writes that relation. The reason it cannot be a filing is measured, not argued: the seven detection families StoreDetections feeds into ValidationReport today all read intent_ defect views, which the header closes, and the only detection a gatherer writes is graphitron_minted_conflict. So a validator half that only flipped checks onto detections the store already writes would flip almost none, and filing the rest would hand roughly seventy-seven checks to a programme with no arm that takes detections, leaving success criterion 3 with no owner. The exception is fixed by kind and bounded four ways, and each bound answers a way the conditions arc went wrong:

Most of the classify-time Rejection re-wraps sit at the edge of the second bound. A rejection is the declined side of a claim arm, and "validator mirrors classifier invariants" in the development principles asks that it derive from the same relation as the acceptance. Where the claim stratum states the declined verdict the detection reads it; where it does not, stating it is classifier modelling, which is an input and gets filed. The fourteen structural checks fit the exception cleanly, and the rejection re-wraps fit it only where the claim stratum already speaks.

Nothing here reaches into the store programme’s work. R958 (In Progress) converts six departures and walks into gatherer-written rows, five of which the conditions arc authored; R955 (In Progress) empties the register bottom-up behind it; R876 owns the ownership rule both apply. Those items decide what becomes of the 48 relations, including whether any of them retires unused. This item’s interest in them is as a consumer, and it states that interest by filing, not by editing their relations or pre-empting their order.

The four pins are trend telemetry, not the target. They are regexes over source text:

So they count spelling. The instrument’s own javadoc records a sixteen-point rise and explains it as arms that started naming their leaves in import-short form "where the previous fully-qualified spellings sat outside it; same dispatch, then visible to the count". Movement with no behaviour change, in both directions: merging two case arms into one lowers the count and relocates nothing.

The deeper limit is the one "What deleted, not migrated forbids" sets up. Leaf dispatch inside plan/ is scaffolding that disappears by construction when the leaves are deleted, so the count is a leading indicator of an event the terminal deletion guarantees anyway. Keep the pins for the one thing they are good at, which is making a stalled relocation visible as a flat line across several slices. Do not read a single slice’s movement as progress or regress, and do not gate on them.

Two numbers actually bind, and the first already exists at scale.

Behaviour holds. The gate this item opened with, byte-identical generated output and identical message, location and severity. It is instrumented by 3794 tests in the generator module alone, across 213 unit-tier and 177 pipeline-tier classes, the compilation and execution tiers above them, and graphitron-sakila-example compiling emitted sources at Java 17 and running them against a real database. Every slice runs the whole of it. Nothing else this item does is worth anything if that goes red, and no leaf count substitutes for it.

The condemned types become deletable. For each type in the seven hierarchies, how many files outside the condemned tree still name it. That is one grep, it cannot be moved by spelling, it only falls, and reaching zero is the type being deletable rather than a proxy for it. All seven rows, corrected: an earlier printing of this table listed the four largest and read as though the other three were zero, when each was nonzero at the same reading and two of them still are.

Every reading is grep -rlw <type> plan command render --include=*.java: the pickup column at ed6964d1, the middle column at 200fd26, today’s at 6e3f346bf. The nineteen sit in six files, the same six as at slice one’s close: ConditionCommands, EmitPlan, FetcherEdgeCommands, LauncherCommands, ProjectionCommands and TypeUnitCommands.

The third column is the reason this item was respecified. It is flat across 106 commits, 4,031 lines of DDL and 14,846 lines of test source, which is what a stalled relocation looks like when every increment inside it is individually sound.

That census is what "The closer" should ratchet, and it is what a slice’s reflection should report. A slice that leaves it unchanged relocated nothing, whatever the leaf counters did.

Every half below holds behaviour across its increments: output byte-identical for the emit tiers, message and location and severity for the validator. State once what that does and does not commit to, because the two readings differ and only one is this item’s.

Output identity is a refactoring invariant. It is asserted against checked-in pipeline-tier expectations, not against a second live derivation, so nothing has to be kept alive to compare against, no residue list accumulates, and it costs one thing for a reviewer of a 5,000-line conversion to check: the derivation moved, the behaviour did not. That is why it is the gate.

It is not fidelity to the walk, and the difference decides what happens when a conversion turns up a disagreement. Fidelity is not a goal here (roadmap/retire-oracle-diff-shadow-tests.md carries the argument): a coordinate where the store-derived answer differs from the leaf-derived one is either a walk bug the conversion fixes, in which case the expectation changes deliberately in the converting commit with the requirement as its specification and the changed output named in the commit message, or a conversion mistake, in which case it gets fixed. Reproducing a walk bug to keep an expectation green is the one outcome this item refuses, at all three halves. Where the store cannot yet state a verdict the consumer needs, the deliverable is the missing relation (strategy point 2: the leaf is never wrapped, adapted, or kept as a side channel), never a record of where the two derivations disagree.

plan/ holds eight producers, not the six an earlier draft of this section listed. Two were missing and they sit at opposite ends of the work:

The six in between. Sites counted under `CommandSeamRatchetTest’s own rule; at the Spec gate they summed to the plan-side pin (3 + 38 + 17 + 48 + 29 + 1, plus routine writes' 11, is 147), and the pin is 140 today, so the per-producer column is owed a re-take by the increment that first reads it. This is an inventory of the work, not a conversion order. What constrains the order is the availability check, and its answer inverts this list:

Each step is a complete unit: the relation’s rows are identical before and after, which the pipeline-tier output expectations assert transitively. A direct row comparison against the leaf-derived rows is a local aid while converting, never a shipped test (see Coverage).

The order this item has carried since the replan put conditions first, for three reasons: it has the smallest dispatch surface, its relation is the parameter three other producers take, and it was the cheapest place to prove the unified rowFor seam on a second family. None of the three survives. The third is spent: the seam was unified on its own, below, without a second family to prove it on.

Conditions has the smallest dispatch surface and, as the availability check found, the largest store gap of the five: it is the one producer of the five that needed a genuinely new classifier arm. Ordering by dispatch size therefore ordered by the wrong column, which is exactly the finding slice one recorded and this item then failed to apply to itself. And the parameter argument does not bind, because a command relation referencing another command relation survives conversion untouched: FetcherEdgeCommands.produce takes a ConditionRelation and will keep taking one whether or not ConditionCommands reads the store.

So the order is readiness, taken off the check:

The dial says the same thing arithmetically: fetcher edges 5, type units 2, conditions 3, projections 3, launchers 5, EmitPlan 1. The re-cut order takes 7 of the 19 in its first two steps, and its first step owes no store work at all, which is the property the previous order did not have at any step.

The chief risk to this item is not its size. It is that a wrong ordering story makes the work chaotic, each increment blocked on another, the tree parked in a half-converted state nobody can reason about. So the ordering claim has to be measured, and when it was, the constraint the earlier drafts leaned on turned out not to exist.

Command-relation dependencies impose no conversion order at all. Read EmitPlan.produce: of the seven producers, only ConditionRelation is consumed by others, and it feeds exactly three (LauncherCommands, ProjectionCommands, FetcherEdgeCommands). TypeUnitCommands and RoutineWriteCommands take no relation, and KeyProjectionCommands already takes store rows only. More to the point, that dependency is a parameter, and it survives conversion untouched: ProjectionCommands.produce(schema, conditions, pkg) becoming produce(store, conditions, pkg) needs nothing whatever from ConditionCommands. The item says as much in "Planners share relations, not queries", where command-referencing-command is explicitly the plan’s own foreign keys and not a shared read. Both statements cannot do work: if the reference survives conversion, it constrains nothing. It does survive, so it constrains nothing, and "in dependency order" was a phantom. Any producer may convert whenever its facts are ready.

Most of the production-path tier inversion is two call sites, and the counting rule matters. An emitter calls a producer’s produce* entry at thirteen sites across six files, which sounds like a thicket and is not one. Eleven are convenience overloads whose own javadoc says so, five of them in generators.schema ("derives the schema-shape rows through the producer so the rendered body set is the flagged-row set production uses") and six in TypeFetcherGenerator’s test-facing `generate and generateTypeSpec entries. They retire by pointing their tests at the plan, which is mechanical and orders nothing. The produce* production inversion is one line-pair in TypeFetcherGenerator’s fetchers fold: `LauncherCommands.produceWithoutSchema at its two sites (the routine-write twin retired with slice one), the nesting-reached fallback.

And that pair dissolves rather than blocking. produceWithoutSchema exists for exactly one reason, stated in its own javadoc: the fetcher generator reaches a nesting-reached type holding fields but no schema. A producer reading the store has no such hole, because the store is available everywhere the walk is not. So the converted plan produces the relation once and the emitter looks up rowFor(type, field), an API both relations already expose and which renderRoutineWrite already uses for the row it renders. Converting a producer deletes its inversion site; the coupling that looked like the hard ordering constraint is a symptom of the walk, and it goes when the walk does.

One production-path inversion falls outside that rule and does not dissolve with it. TypeFetcherGenerator.buildTableInterfaceReprojection calls LauncherCommands.discriminatedBranches and LauncherCommands.selectionRestriction mid-emission to mint a LaunchSource.DiscriminatedTable payload’s two planner-derived components, and hands it to render.DiscriminatedTableFragments; the fold is reached from TypeFetcherGenerator’s discriminated-interface assembly and again from `MultiTablePolymorphicEmitter, so it is production emission, not a test overload. Being neither a produce* call nor a schema-taking one, it is invisible to the census above and to all four ratchet pins, and neither retirement argument reaches it: there is no nesting-reached hole to close and no test to repoint. What retires both calls is the branch list and the selection restriction arriving on a command row instead of being derived at the emitter, which needs the discriminated-table reprojection to be part of the fetcher family’s command relation. That is inside this item’s declared scope but is not yet named as a deliverable of any increment, and the family that owns it should name it. It is also the item’s own motivating anecdote in miniature: a LaunchSource arm assembled where the emitter stands, because that is reachable and nothing forbids it.

What is left is one real constraint, and it is per-producer rather than a chain: a producer converts when the facts it reads are relations. That is a question asked once per producer, answered independently, with no ordering between the answers. Which is what makes the vertical slice below legitimate rather than wishful.

The routine-write vertical shipped between 083d9a6f8 (2026-08-20) and 9c31133 (2026-08-24): one family carried through every tier this item touches, so that the rest of the programme is measured rather than projected. It landed four relations, the tenancy acquisition carrier, the producer’s partial store read and RoutineWriteProducerStatementCountTest. Emitted output stayed byte-identical throughout, and no walk bug surfaced in what the generator emits. RoutineWriteCommands takes a StoreHandle today and still takes a GraphitronSchema beside it, so the family is the one partial conversion in the package.

Two of its findings still constrain the plan. The rest of what it measured was about authoring relations, which this item no longer does.

A conversion does not look like progress until its last commit. Of fourteen tree commits in the slice, exactly one was net negative: the one that made the producer read the store, at +342 and -622. Every commit before it was pure addition. A reviewer who expects the diff to shrink at any point earlier will conclude the work is going badly, and be wrong; a reviewer who never sees it shrink at all is looking at the arc above rather than at a conversion.

Dispatch sites predict emitter work and missing relations predict store work, and the two do not correlate. Routine-write carried 11 dispatch sites and converted in one commit; its 4,000 other lines were three facts that had no relation. The inventory’s dispatch column therefore ranks the emitter half and says nothing about the store half, which is why the availability check below exists and why its own answer inverts the inventory’s order.

Run 2026-08-24 against trunk 1e105c45, by slice one’s method: enumerate the facts the producer reads, then ask of each whether the store states it, states it inside another view’s CTE, or does not state it at all. Absence below is a reading rather than a failure of recall. Every captured population reported as underived was checked by scanning all 83 view bodies for a reader of it, and every relation reported as present was read in the DDL.

The two columns do not merely fail to correlate; over these five they invert. The producer with the densest dispatch in the package needs no new relation, and the producer with the thinnest needs a classifier arm. Slice one showed the inventory’s column predicted the wrong half of the work. This shows it predicts the wrong half in the wrong direction, which is worth more than the first finding: it means an order taken off the inventory would have started with the family that costs the most and ended with the one that costs the least.

The finding underneath all five: the claim stratum is eight arms, not seventy-two. intent_authored_field_claim carries seven claim literals (EXTERNAL_FIELD, INPUT_OBJECT, LOOKUP_KEY, MUTATION, NODE_ID, ROUTINE, SERVICE), intent_resolved_field_claim two resolution arms, intent_authored_type_claim two (ERROR, TABLE), and the structural intent_column_match_claim one verdict over five match tiers. The taxonomy these producers dispatch over is 72 leaves. So the stratum this item has been calling "the expensive population, and it is there" does not state a leaf kind and was never going to: a leaf is a composition of a claim, a delivery arm, a wrapper, a binding and a polymorphic shape, and the store states the components. That is not a gap. It is the reason the conversions are possible at all, because a producer needs the answer its switch computes and not the name of the branch it took. But it means "are this producer’s facts relations?" cannot be answered by looking for the leaves, which is what makes the question per-producer and why the five answers below differ as much as they do.

Fetcher edges needs nothing authored, and the reason is two relations it does not yet take. A row’s targets are three facts the store states: the table-bound participants of a polymorphic coordinate (intent_poly_member joined to intent_bound_table, the joined-table and unbound arms contributing no target), the return type name of a routine write (graphql_field.named_type), and the coordinate’s glue classes, read off the condition relation at the multi-table polymorphic roots and the mutation coordinates, which are the only arms that add glue today (a child’s condition rows are not its fetcher’s reference). Which coordinates get a row is the other half, and it is what the 48 sites decide: their null arms are membership, and a converted producer has to reproduce every one of them. Read against the tree, every arm reduces to a fact already stated or a command relation the plan already holds.

Both new parameters are command relation referencing command relation, which "Planners share relations, not queries" names as the plan’s own foreign keys, and neither orders any conversion: the parameter survives whichever producer converts first. The arms also stop restating the launcher’s membership in a second place, which is a small gain the conversion buys by accident. This producer is the clean confirmation of the replan’s predictor claim, from the extreme end, provided the check is run over membership and not over targets alone, which is where the first reading of it stopped.

Type units is second-readiest, and one of its two halves collapses on contact. The schema-shape kind dispatches over all 18 type permits to pick one of five graphql-java forms, and the mapping is graphql_type.kind verbatim: object permits to OBJECT, both interface permits to INTERFACE, union to UNION, input to INPUT, enum to ENUM, with two exclusions the store also states (scalars, which register off a resolved constant, and _-prefixed federation internals). The 18-arm switch is a re-derivation of a captured column. The input-record half is already a relation and nobody noticed: argumentReachableInputs is the transitive closure of input types reached from field arguments, and intent_input_occurrence_path’s population is that walk keyed by occurrence, so the fold is that relation’s type projection. The `@error population is intent_field_error_channel and intent_errors_field_member, which slice one landed for the routine-write family and which serve this one for free. What remains is the nesting reach fold and the connection pair, both shared with projections.

Conditions is small and carries the one genuinely new classifier arm. Its authored half is comprehensively there: the @condition capture with its context args and argMapping pairs, normalised across sites by intent_argmapping_pair, resolved by graphitron_argmapping_match and intent_argmapping_bound_parameter_type, with the method identity on intent_field_producer_method; the input-surface expansion and its override cascade on intent_input_occurrence_path and intent_input_occurrence_override; the FK-target reach on the reference-step relations. The generated half is not. A generated condition filter is one predicate per column-backed argument, and while intent_argument_scope_table answers which table an argument’s content binds against, nothing answers which column it resolves to. No view in the store joins graphql_argument to sql_column. The relation to author is the argument-site twin of intent_column_match_claim, and the pairing is already written down in the store’s own comments: intent_argument_scope_table’s comment calls itself "the argument-site counterpart of the reading `intent_field_column_scope makes at a field site", and the column half of that pair was never built. This is modelling work of the seat verdict’s kind, not a fold.

One thing dissolves here. The producer recurses into nesting fields because a nested coordinate has no fieldsOf entry, deduplicates the rows a nesting type reused across parents produces, and fails hard if two reuse sites disagree. In the store a nested coordinate is a coordinate: graphql_field holds it once, the reuse multiplicity never arises, and the recursion, the dedup and the divergence throw all go. The walk was paying for a shape the relation does not have.

Projections and launchers are the expensive pair, and they are expensive together. Four of the five relations each needs are the same four. Both need the operation-member fold (projections read the SERVICE_CALL and LOOKUP arms to pick a contribution; launchers join members with anchor-hood to reach a verdict at all), both need connection synthesis, and launchers additionally need ordering and tenancy, which projections need through the launcher rows they call into. Converting either one first pays for most of the other’s store work. Their own halves are in good shape: the correlated chain’s source facts, the reference paths and their foreign-key pairs, the column resolution for column-backed fields, and the routine chain relations slice one landed are all present.

Delivery is two thirds of a relation, and the missing third is documented. This is the check’s one partial finding, and it is the shape slice one’s chain deliverable had. intent_field_separate_fetch states which fields are fetched by a statement of their own, in five rule arms, and two of DeliveryFact.Batched’s three triggers are among them: the authored markers (@splitQuery, `@tenantFanOut) are the view’s two marker arms, and the record-handing parent is its own arm. The third trigger, the list-valued polymorphic fan-in, has no arm, and DeliveryFact’s own javadoc says why: that trigger "was surfaced by this fact’s materialization", after the view was written. The view’s remaining two arms (a non-root `@service, a root operation field) are not batched delivery at all, which is the reader-side care this promotion needs. So the deliverable is an arm plus a projection, not a relation.

Captured populations with no derivation over them are the cross-cutting result, and that is a better statement of the gap than "four relation-shaped folds have no home in the store yet", which is what this item has been saying. The population this paragraph counted has since moved and the count with it, so what follows is the current reading rather than the one the item was written on.

Ordering is no longer inert. graphitron_order_by_entry is read by four views and graphitron_default_order_entry by two, but only one of the six readings is a rule a consumer reaches through, graphitron_carrier_data_field_rule; the others detect a defect, state an unlowerable-ordering verdict, or belong to the retiring intent_ family. What is read by nothing is graphitron_default_order_field_entry and the transcribed graphitron_ast_order_entry, graphitron_ast_order_field_entry and graphitron_ast_index_entry, which replaced the decode relations this sentence used to name and are transcription, where having no view reader is the normal condition rather than a gap.

The facets are no longer inert either: graphitron_facet_binding resolves what an @asFacet application binds, which is a derivation over graphitron_facet_entry and not a detection. The connection registry is read by four views now rather than the one this paragraph claimed. Of the five, the tenant column (store_graph_tenant_column) is the only one still read by nothing at all, and graphitron_pivot_entry is unchanged, read by one view and only as a column-scope input, never resolved as a pivot.

So the shared-cost argument does not rest on five inert populations any more, and the recount is owed to whoever takes this item: what has to be re-derived is whether the readings that exist answer a consumer’s question or merely touch the rows, because only the first kind closes the gap.

The fold count is eight, not four. GraphitronSchema carries arrivals, reachableSourceShapes, tenantScopes, tenantBindings, argumentReachableInputs, connectionSynthesis, operationMembers and deliveryFacts: eight post-walk folds, computed once after the walk and read by the emit side, which is the exact shape of a derived relation living in Java. The item named four. Of the eight, one is already a store relation (argumentReachableInputs), one is two thirds of one (deliveryFacts), and two were never named here at all (arrivals, reachableSourceShapes). Any future statement of what the store still owes this item should count from this list.

What this check decides about the order. Its strongest finding is the one that binds: dispatch density and store readiness invert across these five, so readiness is the ordering column and dispatch density is not. Conditions owns the one genuinely new classifier arm among the five, which makes it the last of the five to be ready rather than the first, and the arc above is what that arm cost when it was paid early. "The order, re-cut" above states the result; this check is its evidence.

Delivered. The replan called this the second deliverable and said it lands while there are two copies rather than three. Reading the tree to do it found the third was already there, which makes the argument stronger than the one that justified the work: the duplication is not the lookup, it is the key, and three relations were each restating it.

LauncherRelation, RoutineWriteRelation and FetcherEdgeRelation are keyed by the coordinate alone, and each carried its own compact-constructor loop rejecting a coordinate that appeared twice, in three near-identical spellings with three different messages. Two of them additionally carried a linear rowFor scan and one of those a byCoordinate() that rebuilt a LinkedHashMap per call. All of it now lives on CoordinateIndex, the row set a coordinate-keyed relation holds: the rows in producer order, the rejection (which now names the offending coordinate, where none of the three did), the lookup, and the coordinate list. The relations keep the invariants that are actually theirs, which is the useful division the change surfaced: the launcher’s case-folded method-name census and the routine-write relation’s tenancy-coverage check stay where they are, because neither is a statement about the key.

ConditionRelation deliberately stays out. Its key is (coordinate, table), so a coordinate maps to several of its rows, and this index’s contract is that it maps to at most one. That is the boundary to hold when the conditions conversion lands: what that family wants is a coordinate-to-rows multimap, not this.

Two things were fixed rather than moved. RoutineWriteRelation.rowFor’s javadoc claimed the fetcher generator dispatches on its presence; it does not, `renderRoutineWrite reads the row with orElseThrow and the one presence read is `EmitPlan’s key-projection reachability check. The sentence was true of the launcher relation’s twin and had been copied. And the seam is now pinned by a test of its own rather than through three relations' delegation, including the ordering guarantee, which is load-bearing: consumers fold these rows into emitted files, so a map reading out in hash order would make generated output depend on coordinate names.

This change makes no performance claim, and the first version of this section made one it should not have: that it was "better or equal by construction". Better or equal is a measurement, and there is no honest instrument here for it. The relations hold dozens of rows, the repo has no microbenchmark harness, and reactor wall-clock is not evidence. A map read replacing a scan and a per-call map rebuild going away are descriptions of the diff, not results; the reason to make the change was that three relations were restating one key, which is an argument about duplication and stands on its own.

The Java-side cost here that is measurable is the one deferred below: two producers scanning the whole condition relation once per coordinate. That is the same shape the store’s own comments warn about, a relation re-evaluated per driving row, and it gets measured in the increment that fixes it.

One thing the reading turned up and this change does not address, recorded for the family that inherits it: both LauncherCommands.conditionRowOf and FetcherEdgeCommands.addConditionGlueTargets scan the whole condition relation once per coordinate. That is the multimap above, and it belongs with the conditions conversion rather than here.

Twenty-seven increments between 7d571f947 (2026-08-24) and 6062f1e19 (2026-09-05) authored the condition family’s fact layer: 48 relations, 4,031 lines of DDL and 14,846 lines of test source across 106 commits. Each increment’s reasoning is in its own commit message, which is where a retrospective belongs; four facts from the arc constrain what this item does next, and they are the whole of what the plan below needs.

The availability check under-priced the family by an order of magnitude. The check ran conditions at three relations to author. Increments one through four landed those three. Twenty-three more followed and the producer is still not converted. The tenth increment records the turn in its own words: nine increments in, the shape a write surface is most often written in "was outside all of them", and the arc then spent increments ten through sixteen building a mutation write payload substrate the check had not named at all. An availability check enumerates the facts a producer reads. It cannot see the facts those facts turn out to rest on, and nothing in the method made the difference visible until it had been paid.

The arc had no stopping condition. From the sixteenth increment onward, every increment’s owing note names the producer conversion as the one remaining step, and the last three each name the same next relation as what stands in its way. An increment that ends by naming one more relation will always find one more relation; that is the defect, rather than any judgement made about any single relation in the set.

It moved neither of this item’s own dials. The deletable-types census stood at 19 when slice one closed and stands at 19 today, in the same six files. PLAN_LEAF_REFERENCES fell 147 to 140, and the three generator-side pins did not move at all. By this item’s own rule, that an increment leaving the census unchanged relocated nothing whatever else it moved, the arc relocated nothing.

The store has since ruled the form out. The intent_ family header in graphitron-model.sql, as of c4afb033c, reads "DEPRECATED, THE WHOLE FAMILY" and states the rule for anything landing there from now on: do not. A fact that is missing is captured as early as it can be captured, in the family that owns the corpus it comes from. 116 relation comments carry the matching notice. Of the 48 relations this arc authored, 37 are intent_ views still standing under that header, and 39 of the 48 have no main-source reader at all, because the producers they were authored for were never converted.

So the arc stops here, and the relations it left are not this item’s to re-place. That work is owned: R958 (In Progress) takes six departures and walks into gatherer-written rows, five of which this arc authored, and R955 (In Progress) empties the register bottom-up behind it. This item files against that programme rather than reaching into it.

The recipe per family: mint the command relation in plan from the leaves it covers, move the emitters to render reading only that row, extend the borrow dial by the refs the row carries, delete the leaf-reading bodies. Output is held byte-identical throughout, which is what makes each family a verifiable unit with nothing to argue about.

The census owed a re-take (an earlier one totalled 129 against pins of 131, and carrying two totals for one quantity is the same species of blind spot as the pin corrections below). Re-taken against trunk 7f2ff35 under the pins' own rule, it totals 131 and reconciles exactly: 69 instanceof plus 62 case, no residual.

Five files carry all 131, 125 of them in the fetcher family: TypeFetcherGenerator 83, FetcherEmitter 30, FetcherRegistrationsEmitter 12. The tail is GeneratorUtils 5 (all on GraphitronType’s result-type arms; one result-Java-type fact on a command row retires them together) and `TenantDslEmitter 1. That last count is honest and misleading at once: the one counted site is the TenantBinding switch, and it serves roughly forty call sites across five emitters, so the file is not a tail to knock off early. The fan-out half of the tenancy dial is already command-shaped as TenantStrategy/CarrierDsl for migrated hosts; the acquisition half becomes command-shaped starting with slice one, and the file retires with the fetcher family when its last caller moves.

The re-take moved two things, and neither moves the order. ObjectTypeGenerator is off the list entirely: its three sites were a six-leaf instanceof chain over the form-carrying arms, and the render-side form resolution folded them into one read of CarriesObjectForm, which the arms opt into. That is the shape this item wants generalised, a declared capability read instead of a restated arm list at each consumer, and it landed without this item owning it. The 129-to-131 gap is therefore not the discriminated interface child’s batched half, as the earlier text guessed; TypeFetcherGenerator grew from 78 to 83 while ObjectTypeGenerator went to 0. The fetcher family is heavier than the earlier census said and the tail is one file shorter, which sharpens rather than changes the ordering argument below.

The other 52 files in the package have no leaf dispatch; most of them are membership already decided by TypeUnitCommand and GlobalCommand rows over fixed-text or carrier-driven bodies, and they are the guard extension’s concern rather than a migration’s.

So the order: the one true tail first, GeneratorUtils (the object generator having folded already, and TenantDslEmitter having turned out not to be a tail: its switch retires last, with its last caller), because it is an afternoon and retires its sites whole; then the fetcher family, which is the item’s real weight and subsumes what remains of the launchers. "The launcher family is done" was true at the body tier only: the rows methods render through RootLauncherRenderer and its fragments, but TypeFetcherGenerator still emits the DataFetcher entry points that wrap them, drains the per-class scatter helpers (SplitRowsMethodEmitter) and the DataLoader registration wrappers (RowsMethodCall, DataLoaderFetcherEmitter), and invokes planners mid-emission, which the tier rule forbids. That host tier is not a separate family; it is part of the fetcher family’s cutover. The fetcher family’s membership rows exist (TypeUnitCommand.FetchersUnit), but no relation says what a coordinate’s fetcher method body is, for the read entry points or the DML write statements alike, so the per-coordinate fetcher command is the relation to mint, and the dispatch arms in TypeFetcherGenerator and FetcherEmitter are exactly the derivation that moves into its producer. The routine-write slice of that family is scoped as a worked example on another item (below). Alongside the leaf work, the schema-shape and util generators' model-taking entry points (15 of the pin’s 18) retire as their reads become store reads or command columns, largely with the planner half’s sixth step.

Two instrument corrections the census surfaced, each owed to the first increment that touches it:

The validator’s three input channels (the Rejection each Unclassified* leaf carries, the structural checks over classified types and fields, and schema.diagnostics()) converge on one move, and its channel already ships: StoreDetections (now in graphitron-model, under no.sikt.graphitron.model.derive) folds seven detection families into ValidationReport through violations(), minting user-facing errors with no leaf anywhere in their derivation.

Reaching the editor and the MCP is not free, and must not be claimed as such. The diagnostic surface is a hand-written UNION ALL with one arm per source relation, and intent_argmapping_projection_defect is not an arm of it today, so of the existing families not every one reaches the LSP squiggle. Each migrated check’s commit therefore states where its rows surface: joining diagnostic is part of the migrating commit wherever the defect is author-facing, and the union’s arm set gains a mechanical pin so an unjoined detection is a build failure rather than a silent editor gap. And since this item retires rejection_validation_error, the arm the editor’s build diagnostics ride today, the migrated verdicts' stated permanent home must exist before that transcription family can go.

One class of check is the stated exception to success criterion 3, and it is two checks, not one. validateProjectionUnitAddresses and validateLauncherMethodNames (through ProjectionCommands.addressCollisions and LauncherCommands.methodCollisions) assert that two minted unit names do not collide after case folding. A store detection for those would put the naming formula in SQL beside the producer that mints it, one invariant with two mints, which is the drift shape the single-mint naming regime exists to prevent; and the alternative homes are closed by this item’s own rules (a check over committed command rows reads a record family upward, and validation-after-planning is a pipeline reorder). So the collision invariant stays at the mint, as the producer’s hard failure, and any author-facing rejection for it derives from the inputs to the formula, a folded-name agreement between captured SDL coordinates, which is a schema-grain fact needing no minted name. The validator’s upward reads dissolve either way: no plan or emitter import survives in validation.

The classify-time rejections are the same move seen from the other end. Today a rule the schema breaks demotes the coordinate to Unclassified* inside the walk, and the validator re-wraps the carried Rejection; store-side, the rule that demoted it becomes a detection that reports the same error at the same location, reading the claim stratum’s declined verdict where it states one and waiting on a filed verdict where it does not. The Rejection hierarchy’s vocabulary (16 leaves plus 9 error sub-seals) is re-expressed as those detections' closed literal vocabularies, the way rejection_validation_error.kind already transcribes it for the editor.

Two properties keep this half honest. Each check migrates one at a time, behaviour held: message, location and severity survive on the fixture that trips the check, and a check with no fixture gains one in the migrating commit. And the ordering is already paid for: validation runs downstream of capture today, so no pipeline change is needed for any of it.

This half needs a counter of its own, on the item’s own argument. The four ratchet pins measure plan/ and generators/ and, as stated above, do not see the validator at all, which leaves the half with the least mechanical protection running on 2,175 lines and its validate* methods with nothing to make a stall visible. "A ratchet with no owner is a flat line" applies here more than anywhere: a validator check is easy to leave for later precisely because no count moves when it is. Add a validator-side pin in the same CommandSeamRatchetTest mould with the first migrated check (leaf references in GraphitronSchemaValidator, or its methods taking a leaf, whichever the scan can state without ambiguity), never-raise on the same terms, retired when the terminal deletion makes it unraisable.

When the plan, the emitters and the validator read the store, the walk’s remaining readers are the tail census above, and each either migrates inside the family that owns it (EntityResolutionBuilder with federation’s slice, CatalogBuilder and PlanCompileGraph with the planner half’s last steps) or retires with the walk outright (RejectionFacts and the rejection_ relations, the walk_ family and its derive/ projections; their DDL comments state that lifetime already). Then the deletion lands: the sealed classification taxonomy in rewrite.model, GraphitronSchemaBuilder, TypeBuilder, FieldBuilder, BuildContext and the walk-only resolvers around them, on the order of tens of thousands of lines. Deletion is not a big bang; it falls out family by family as each last reader moves, and the final commits remove what nothing references.

Four obligations are owed before the last cut, named now so nobody discovers them at the end. A fifth is listed first and is already discharged, kept because it is the shape the other four are read against:

Extend PackageImportDirectionTest over both packages once they are empty of leaf readers, giving each the same positive dial render already has: an enumerated allow-list of what the package may import, everything else a finding, the closure pinned by reflection the way borrowDialComponentClosureIsPinned does it. render keeps its restriction to commands plus the named pure-data refs; plan gets store reads (StoreHandle and the generated store tables, deliberately not bare org.jooq.DSLContext; see "Where a producer’s SQL lives") plus the command vocabulary it produces. A deny-list of the seven leaf hierarchies is explicitly the wrong shape: an eighth hierarchy, a relocated leaf, or a leaf taken as a parameter and never dispatched on all pass it, which is the same blindness the pins have. The positive dial also makes the guard permanent by construction: when the terminal deletion removes the hierarchies, nothing about the dial changes. The ratchet pins retire in the same commit that extends the guard over the package each pin measures: a zeroed pin the guard makes unraisable is a second mechanism for one invariant, and two mechanisms for one invariant drift apart.

Prove each extended dial non-vacuous at the gate, the way the MCP’s boundary guard was proven at its Done review: plant a forbidden leaf reference, watch the build fail, remove it. A guard that has never fired is a claim, not a gate, and the precedent for what an unproven needle misses is live: the MCP guard shipped scanning one package prefix of the five the generator publishes (filed as roadmap/mcp-boundary-guard-generator-package-coverage.md), which naming the forbidden hierarchies and packages explicitly, then probing them, avoids.

Settled: the planner half leads per family, not globally. A family’s command relation becomes store-derived first, then its emitter moves onto that row. That keeps both halves advancing on the same family instead of two fronts crossing, and every emitter cutover verifies against a plan that is not simultaneously changing its own inputs. Where a family has no command relation yet, minting it from the leaves it covers is a legitimate intermediate step (the plan-side pin rises, as its comment anticipates), but the re-sourcing follows within the same family’s arc rather than being deferred to a global second pass; a minted-from-leaves relation is transitional state, not a resting place.

The family is therefore the unit of work throughout, and the earlier drafts' three competing decompositions collapse into it. The planner half used to be ordered by relation, the emitter half by file, and this section by family, with no mapping between them, which is what made "what is the first commit" unanswerable. The inventory of producers stays an inventory; the schedule is families, and a family is done when its facts are relations, its producer reads them, its emitters render its rows, and its dispatch sites are gone. Conditions and projections are families whose emitter side already sits in render (ConditionGlueRenderer, ProjectionUnitRenderer), so converting their producers completes them outright. Fetcher edges is the third such family, for a different reason: its one reader is PlanCompileGraph, which turns its rows into declared recompile edges and emits nothing, so its producer conversion is the whole family. Launchers, type units and routine writes feed the one large fetcher family, which is why that family is the item’s real weight and why slice one takes the corner of it that detaches cleanly.

The validator half is independent of the emit tiers and advances beside them, check by check; no emit-family increment waits on it and it waits on none of them. The terminal deletion comes last by construction, since it is defined as what happens when nothing reads the walk.

It files. The mechanics, so that an increment does not have to invent them:

The filing names the consumer and the grain, not the shape. A producer needs a verdict; the filing says which producer, which coordinate grain the verdict sits at, and what one row would assert. It does not propose a view body, a prefix or a registration, because those are the owning gatherer’s decisions and this item is not that gatherer.

It goes to the store programme, which has a live arm for each kind. R958 (In Progress) is taking six column-scope departures and two @reference walks into gatherer-written rows. R955 (In Progress) empties the register bottom-up behind it, fourteen rungs. R876 owns the ownership rule both of them apply and the computation that says every registered target belongs to the graphitron gatherer. A fact this item needs is a rung for one of them or a new filing beside them.

And the producer waits rather than converting against a leaf. A half-converted producer that reads the store for four facts and a leaf for the fifth is not an increment of progress; it is a second reachable path to the same fact, which is the defect in the opening sentence of this item. The availability check ranks five producers so that there is always one to convert instead.

What this item still owes the store programme is the reverse direction: a reader. Of the 48 relations the conditions arc authored, 39 have no main-source reader, and a relation with no reader is a relation whose grain nobody has tested against a real question. Each producer conversion that lands here is the first real consumer of some of them, and that is the one thing this item can give that programme which it cannot get for itself.

The validator half writes store relations and the planner half is banned from asking the store for plan-shaped ones, which reads as a contradiction and is not. A defect is a fact about the schema: permanent, many-consumer, so it belongs in the store as a detection relation, filed in its owner’s family. A command row is a fact about this run: one-consumer, run-scoped, so the store never serves it, and MULTISET composition stays in the producer’s SELECT. That line, not the identity of the consumer, decides where a derivation lives. Who writes the relation once the line is drawn is a separate question: a planner’s missing input is filed, and a validator check’s own detection is written here, under "The one exception", with its inputs filed like the planner’s.

Read against trunk 2ba9c9d, the whole plan and not only the respec delta. The goal passes: consumers see nothing change, and the payoff, one way to reach a fact instead of two, is stated plainly enough to judge. The pins (18/69/62/140), the nineteen-reference census across six files, the 37 IMPLEMENTED_LEAVES entries and the intent_ header quote are what the body says. Two findings block the gate. Each one sits under a rule the respec itself introduced.

1. The readiness claim the re-cut order rests on does not hold for fetcher edges (question 1, viability). "Fetcher edges first" depends on the availability check’s row saying the producer needs nothing authored. The check listed the facts that fill a row’s targets (table-bound participants, a routine write’s return type, condition glue). It did not list the facts that decide which coordinates get a row. Those are the 48 sites, and the null arms are membership decisions the converted producer has to reproduce. They are not emitter work. FetcherEdgeCommands gives ChildField.TableInterfaceField a row and ChildField.BatchedTableInterfaceField none, and FieldBuilder separates those two on list cardinality. That is the list-valued fan-in trigger this body says has no store arm. QueryInterfaceField gets a row and QueryTableInterfaceField none, so the producer needs a single-table versus multi-table verdict. MutationRoutineWriteField and MutationRoutineWriteRecordField differ on the seat verdict, and QueryNodeField / QueryNodesField membership needs a node-field fact. By this body’s own nature test, a verdict gets a named view even with one reader, so these cannot be inlined into the producer’s SELECT. Under the non-authoring rule they are filings. That is the conditions arc’s under-pricing again: the check saw the facts the producer reads and missed the facts those rest on. A second problem sits beside it. FetcherEdgeRelation’s only reader is `PlanCompileGraph, where its rows become declared-superset recompile edges. They are not emitted source. So "Output identity, per planner increment", the gate Coverage names for every conversion, cannot see this producer at all, and "launchers, fetcher edges, type units and routine writes all feed the one large fetcher family" is wrong about fetcher edges. Satisfied by: re-running the fetcher-edges check over membership as well as targets. It should say, for each membership verdict, which relation states it or that it is a filing, and re-rank if it is a filing. It should also name the gate that pins this producer’s behaviour (PlanCompileGraphTest, `IncrementalCompileHarnessTest’s three-leg oracle, or a stated alternative), since byte-identical output does not.

2. The validator half contradicts the non-authoring rule (question 2, fit). "What this item does not author" calls the rule absolute. "The one line this item still draws for itself" says a detection is "filed like any other fact". Coverage says no relations are authored here. But strategy point 4, success criterion 3 and the whole "Validator half" section still describe this item’s increments authoring detection views: "a check expressible as a relation becomes a view", in the intent_authored_claim_conflict mould (a family the header now closes), with the migrating commit joining diagnostic and adding the fixture. R876’s rule, which this item says it obeys, says a rule the last gatherer can compute in a stage is not a view. And neither R958 nor R955 has an arm that takes detections. An implementer picking up the first validator check cannot tell whether they write a relation or file one. If they file one, criterion 3 depends on roughly seventy-seven checks for which no owner is named. Satisfied by: the author deciding one of two ways. Either the validator half is a stated carve-out from the non-authoring rule, naming the family and owner detections land in. Or it files like the planner half, and then strategy point 4, criterion 3 and the validator section have to say where those filings go and what this item does while they wait.

Non-blocking. LauncherCommands.selectionRestriction is a second mid-emission planner call beside discriminatedBranches in TypeFetcherGenerator. The inversion census does not count it, and it is owed the same named retirement. Corrected in passing as stale: the validator’s line and method counts, TypeFetcherGenerator’s and four producers' line counts, R958’s status, and the `RoutineWriteCommands signature and inversion-pair prose. produceWithoutSchema on that class retired with slice one, and StoreHandle is now used under graphitron/src/main.