Derive the never-unsorted-list verdict from facts, and pin the lowering the verdict cannot see

A schema that asks graphitron for an ordering it cannot deliver stops building, instead of generating without a word and serving rows in whatever order the database happened to return them. Graphitron states an invariant, a list result is never unsorted, and the two build-time checks that enforced it key on a population that misses most of the ways it breaks. Three things change over the item’s three phases; two of them have shipped.

Phases 1 and 2 have shipped and are signed off. Phase 3 remains, and the item is back at Spec for phase 3 alone: the plan section for it was written against a store that has since declared the family the section files its two new relations in to be going away. See "Reopened 2026-09-22" below for what has to be re-decided; the file is not deleted, and phases 1 and 2 are not reopened.

An ordering the coordinate cannot honour fails the build. Shipped in phase 1. Before it, this

generated silently and served every page in participant primary-key order, whichever direction the client asked for, because a field returning a multitable interface (one whose implementations each live in their own table) is read as one statement per participant and no ordering is lowered onto those statements, lowering being the step that carries a schema-level declaration down into emitted SQL. That schema now fails the build with two located messages, one per declaration, each naming the coordinate, the container’s participants, and both remedies. This is the reporter’s own fallback ask on https://github.com/sikt-no/graphitron/issues/523, and it is a breaking change for any schema that compiled with that declaration; see "Compatibility". The same rule sees a second shape, the list-returning @routine write, where the ordering that goes undelivered is the target table’s primary-key fallback rather than anything the author wrote; that rejection is built and held, and R660 turns it on with the fix, so no consumer meets it from this item.

A resolved ordering the generator cannot render stops the build too, with a generator-bug message rather than a schema error. Shipped in phase 2. CallWrap.Multiset, the command value behind a child list read as a correlated subquery, carries the whole resolved ordering while the renderer has a branch for one arm of it, so a client-supplied order on an inline child list was accepted and then dropped. The confirmation recipe found that shape live, and it is now refused at production; the lowering that empties the refusal’s population is R935. The same fold ratchets the launcher relation (the command rows saying how each root read is launched) so the ordering projections that shipped in August cannot regress. Nothing changes for a consumer whose schema carries no inline child list with an @orderBy argument.

The never-unsorted rule starts being keyed on the question it asks. Phase 3, which remains. It replaces the two capability-keyed validator checks with one fact-derived verdict per list-shaped read coordinate, so the rule stops depending on a read resolving against exactly one table. For a consumer this shows up as coordinates that used to slip past the check now failing it, each with a message that names which remedy applies.

Phase 3 waits on R682 and now also on its own re-spec. The In Review transition happens per phase, per the multi-phase convention in roadmap/workflow.adoc. === Why today’s checks miss most of it

Two checks enforce the invariant today, GraphitronSchemaValidator.validateListRequiresOrdering and its paginated sibling validatePaginationRequiresOrdering, and both key on the same pair of signals: the field’s resolved OrderBySpec landing on None, and the field being a member of SqlGeneratingField. Most known violations produce neither signal, so the check passes and the rows ship unsorted.

The membership half is not a forgotten declaration that a reminder would fix. SqlGeneratingField.returnType() is typed ReturnTypeRef.TableBoundReturnType, so a read whose target is not one table cannot implement the capability at all. The checks are keyed on "this read resolves against one table" while the question they ask is "does this read return a list". Nothing about a list needs one table, which is why the gap exists and why no amount of declaring membership closes it. Whatever replaces these checks has to be keyed on the question.

Six sites are known: three closed, two live, and one found while speccing and not yet confirmed. They do not divide the way a single enforcement mechanism would need them to, which is the reason this item is three tracks rather than one.

Sorted by what can decide them, the sites are three different defects. Two are live, and the three closures do not retire the classes: each closed one coordinate and left the class it belonged to unenforced, which is the whole reason this item exists.

Class A, an ordering is available and the coordinate’s read shape cannot honour it. Available means either side of the resolution: an ordering the author declared, or the target table’s primary-key fallback that OrderByResolver.resolveDefaultOrderSpec supplies where nothing is declared. The multitable root is this at the declaration grain: @orderBy and @defaultOrder classify clean, generate without a diagnostic, and produce participant-primary-key order at runtime, while @condition filters on the same field work. The list-returning routine write is the same comparison with the fallback standing in for the declaration, and it is why the class is stated as availability rather than as declaration; without the generalisation that coordinate falls between all three classes. Both sides of the comparison are facts: what is available is captured or one join away, and what the read shape is comes off intent_field_scope_table and intent_mutation_routine_seat.

Class B, no ordering is available at all. A list-shaped read whose coordinate carries no authored ordering and whose target offers no primary-key fallback. This is what the current checks were written for, and it is decidable from facts too: the authored side is captured, and the fallback is a join. A and B partition the list-shaped read coordinates between them, which is what makes the pair exhaustive rather than two rules with a gap between them.

Class C, an ordering resolved and the lowering discarded it. The @splitQuery child and the @lookupKey child were this, and both are now closed at the command tier, which leaves the class with no live site anyone has found. No fact at any grain can see class C, because at the fact tier the ordering is present. These are generator defects, not schema defects. There is no schema for an author to fix and no source location for a message to point at.

The routine write path is class A, and placing it took the generalisation above. Two readings have to be refused before the third one lands. It is not class C: MutationField.MutationRoutineWriteField "carries no ordering slot, so there is nowhere for a resolved OrderBySpec to live even if @defaultOrder were honoured", as its own item states, so nothing resolved is ever discarded and a mechanism keyed on "an ordering resolved" cannot see the coordinate. Nor is it class B under a narrow reading of "no ordering resolves": Mutation.rentFilm: [Rental!]! navigates as Rental, which binds rental, so the coordinate takes a NAMED_TYPE_TABLE row in intent_field_scope_table and rental has a primary key. An ordering is available; the write’s family has nowhere to put it, because the visible rows are step 1’s captured keys re-fetched by a keyed SELECT that sorts by nothing. That is class A’s comparison exactly, with availability where the declaration usually stands, and it is why phase 3’s population would admit the coordinate and then verdict it ORDERED.

The worst case already recorded on the @splitQuery item is what happens when A and C meet: for a view-backed target with no primary key, the deterministic-order validator compels @defaultOrder and emit then discards it. The build makes a class-A demand and commits a class-C violation in the same run. Naming the two separately is what makes that combination stateable, and refusing it is a requirement on whatever ships.

An earlier framing of this item proposed re-sourcing the rule off the launcher relation’s ordering slot, on the reasoning that ResultShape.RecordList with an absent Ordering makes the whole population visible in one place. That anchor fails three independent tests, and the third is the one the earlier framing had already half-found on its own.

Pipeline position. GraphQLRewriteGenerator.runPipeline pronounces the verdict and throws before it calls EmitPlan.produce. The launcher relation does not exist until the build has already decided the schema is valid. Worse, the plan never runs on the other two entry points at all: validate() and buildOutput() are both load, classify, capture, validate, with no plan anywhere. A rule sourced off commands would be absent from graphitron:validate and invisible in the editor. A store-derived rule reaches all three, because the capture window runs ahead of the verdict on every path (FactCapture.detect inside GraphQLRewriteGenerator.captureAndRead, whose continuation runs the validator and fuses StoreDetections.violations() into the error stream) and the diagnostic view already carries intent_authored_claim_conflict as a view arm beside the walk’s own errors.

Tier direction. PackageImportDirectionTest pins facts below command below plan below render, stating on the facts leg that "facts sit below commands; the corpus will read facts without a plan". The validator lives in no.sikt.graphitron.rewrite. Making it read commands adds a consumer of commands that is neither a planner nor a renderer, which is the seam roadmap/planners-read-facts-emitters-read-commands.md exists to close. That item’s closer names two import dials, plan and render; a build-time rejection sourced from commands would need a third.

Population. The launcher relation excludes the multitable root by the same keying the current checks use one tier down: LauncherCommands.verdictOf anchors on the target-axis fact TargetShape.Table, and the multitable family carries Interface or Union, so it takes no launcher row and its UNION-ALL stage belongs to the polymorphic-emit family. Re-sourcing off the launcher relation would leave the site exactly as invisible as it is today while the framing read as having closed it.

At the fact grain there is no carve-out to be outside of, because there is no capability interface. Every ingredient is already captured: graphql_field.is_list for list-shapedness, graphitron_default_order_entry and graphitron_default_order_field_entry and graphitron_order_by_entry for the authored ordering, intent_bound_table joined to sql_primary_key for the fallback, intent_field_chain_terminus for the routine terminus that has no primary key to fall back on, and intent_mutation_routine_seat for the write shapes, whose population is every mutation-root field carrying @routine and whose verdict column already sorts its values into the ones an author fixes and the ones the generator owes an emitter. The polymorphic root is an ordinary row of every one of those relations.

The store forbids the shape a "population observable in one place" framing invites. intent_field_separate_fetch’s relation comment ends: "A reader may say a field with a row is separately fetched, and may not say a field without one is inlined." The never-unsorted invariant is an absence check, so building class B as a `NOT EXISTS against an ordering fact table would violate that rule directly.

Class B has to be a positive population carrying a verdict, on the intent_resolved_field_demand model: rows are the list-shaped read coordinates of the classification domain, one verdict per row from a closed vocabulary, and a coverage gate counting resolved rows against the population so the construction stays honest. That view is the item’s one piece of genuine modelling work; everything else it needs is already derived.

Deliberately no depends-on. Classes A and C shipped independently of each other and of everything else, as phases 1 and 2; class B is what remains.

Class B lands after the launcher step of roadmap/planners-read-facts-emitters-read-commands.md, or alongside it. Deciding "does an ordering resolve for this coordinate" from facts is the same derivation LauncherCommands performs today and that item moves store-side; doing it twice from two sources is how the two ends drift. Whether class B can go green before every per-site fix lands, or needs a temporary exemption list, is a Spec question. An exemption list is acceptable only if each entry names the item that removes it.

Class C was not blocked on class B and was not sequenced behind it, which the delivery bore out. The two read different things: class C compares a resolved ordering against the command row that was supposed to carry it, which needed nothing new; class B asks whether an ordering is available at all, which is the fact-tier question and the one that waits.

Each one is a constraint the phases below are built against.

Shipped at d61dc6b. intent_field_unlowerable_ordering is the rule, UnlowerableOrderings the decode, UnlowerableOrderingRejectionRows the capture-cadence writer, and the diagnostic view gains an eighth arm over the pair. Six things the delivery settled that the plan did not, each a premise for phase 3 and for whoever picks up R660:

Shipped at d61dc6b, in the same commit as phase 1. LauncherCommands.requireResolvedOrderingsAreLowered is the fold, called from EmitPlan.produce once both relations exist, with LauncherCommands.orderIsEntailedBySource as the one home of the exemption set. Four things the delivery settled:

The one piece of genuine modelling work, and the only track that waits. It answers one question, "is an ordering available at this list-shaped read coordinate", over a population that needs no capability membership; whether an available ordering is then honoured is phase 1’s question and not this one’s.

Shape. A positive population carrying a verdict, on `intent_resolved_field_demand’s model, because absence is not the complement’s claim (see the section of that name above):

The population is "list-shaped read coordinate": graphql_field.is_list, in intent_type_domain, with a row in intent_field_scope_table (any basis) or a routine terminus in intent_field_chain_terminus. Note what that population does not need: membership in a capability interface. That is the whole point of the track: SqlGeneratingField stops being the gate, so a list-shaped read that resolves against no single table is inside the rule rather than invisible to it.

What the wider population does not buy is the routine write path, and the plan says so here rather than letting the phase’s test list imply otherwise. Mutation.rentFilm takes a NAMED_TYPE_TABLE row on rental, rental has a primary key, so PRIMARY_KEY_FALLBACK fires and the reduction reads ORDERED. That is the correct answer to the question this view asks; the coordinate’s defect is that the available ordering is not delivered, which is phase 1’s KEY_CAPTURE_SCATTER verdict.

The dependency, and the reopen trigger. R682 (planners-read-facts-emitters-read-commands, In Progress) moves the launcher relation’s derivation store-side. Deciding "does an ordering resolve for this coordinate" is the same derivation LauncherCommands performs today, and doing it twice from two sources is how the two ends drift. So phase 3 does not start until R682’s launcher step has landed, and if that step lands the ordering derivation under a different name or grain than this section assumes, this item returns to Spec before phase 3 is implemented rather than being reconciled in flight. Phases 1 and 2 are unaffected by that trigger: neither reads a launcher fact. That step has not landed, and a second premise gave way first; see "Reopened 2026-09-22" below.

What phase 3 retires. validateListRequiresOrdering, validatePaginationRequiresOrdering and listOrderingDiagnostic are replaced, not kept beside the view: two rules with two populations is the drift this item was filed against. The requiresReFetch() exemption goes with them, replaced by the INPUT_SCATTER rule, which is the same carve-out stated positively and per coordinate rather than per capability.

Whether it can go green. Open, and honestly so: it depends on how many coordinates the wider population turns out to catch, which is measurable only once the view exists. An exemption list is acceptable if each entry names the item that removes it, and unacceptable otherwise. Take the count before writing the rejection, on the sakila example schema and on the fixture corpus.

Phase 3 was picked up for implementation on 2026-09-22 and put back at Spec without a line of it written. Two premises the round-3 sign-off rested on no longer hold, and the section above cannot be followed as written. The reopen is Ready -> Spec per the unguarded transition in roadmap/workflow.adoc, so the next Spec -> Ready needs a fresh independent sign-off on whatever replaces the shape section. Nothing here touches phases 1 and 2, which read no launcher fact and mint no new relation.

The stated dependency is still unmet, which is the lesser half. R682 is In Progress and its launcher step has not landed. LauncherCommands.orderingOf still computes the slot in the plan tier off the leaf’s own OrderBySpec, LauncherCommands reads no store relation at all, and no relation in graphitron-model.sql answers the launcher question. So the reason phase 3 was sequenced behind that step, that deciding "does an ordering resolve here" twice from two sources is how the two ends drift, is exactly as live as it was at Spec time. On its own this would leave the item at Ready waiting, not send it back.

What sends it back is that the intent_ family is being retired. Landed 2026-09-21, one day before the pickup, in the commit whose subject is that the family says it has no owner. The family header in graphitron-model.sql now reads "DEPRECATED, THE WHOLE FAMILY" and states the rule for a rule arriving after it: do not. The shape section above mints intent_field_ordering_rule and intent_resolved_field_ordering, two new relations in that family, and that is not a naming detail to fix in flight. The ownership section of docs/architecture/explanation/fact-model.adoc replaces the prefix with a rule that decides where each part of a rule goes: a view reading relations from one family is a view of that family, a rule whose facts appear to cross families has a single-family part inside it that has not been separated out, and the cut is made by expanding through every intent_ relation the rule names until only captured relations are left. Phase 3’s population is a crossing read by that test, naming graphitron_default_order_entry and graphitron_order_by_entry in graphitron_, sql_primary_key in sql_, and intent_type_domain, intent_field_scope_table, intent_bound_table and intent_field_chain_terminus in the family being dissolved. So the phase’s one piece of genuine modelling work is precisely the work whose filing rule changed underneath it.

Two precisions, so the re-spec is not argued against a stronger claim than the tree supports:

Round 3’s first non-blocking finding is answered, and the answer survives the reopen. The finding was that phase 3’s population still names graphql_field.is_list, the relation ExpandedPopulationReaderGateTest refuses to a new reader, and that phase 1 had already hit and answered that wall. The answer is the one phase 1 took: graphitron_field carries is_list as a column of its own, with item_non_null beside it and a CHECK tying the two, so the population reads the route relation and names no transcription. Whoever re-specs should write that into the population predicate rather than leaving the question open a second time. The other two findings are about phase 1 and 2 code and are untouched by this reopen; the third in particular, the empty OrderBySpec.Fixed on a list multiset, is still the unmeasured one.

Handed over by R382 at its Done gate (2026-09-24). R382 now lowers @defaultOrder and @orderBy onto list-shaped root Query fields over a multitable interface or union, and it did that by adding an exclusion to the PARTICIPANT_FAN_OUT arm of intent_field_unlowerable_ordering. So the statements above that the root "accepts and discards" the ordering, and that the rejection’s population "empties on its own" with nothing to un-write, no longer hold at the roots. They still hold at child multitable fields and at single-valued roots, which keep their rows. The re-spec inherits two things from that exclusion. Its SQL comment carries the rationale.

Per phase, and each named test is what answers "how do we know the item is complete".

Phases 1 and 2, shipped. Four files, and what each answers:

Phase 3.

Shipped with phase 1, at both pages the draft named.

docs/manual/how-to/sort-results.adoc, "Sort across polymorphism". The section as written described ordering across a multitable union as working and warned about a hazard that cannot arise ("every participating table must agree on the order’s shape"), so a reader following it wrote a schema that silently ignored their order. It now says what is true: the emitter sorts on a synthetic key built from each participant’s primary key, a declared ordering is not lowered, and declaring one fails the build. The single-table paragraph beneath it was accurate and stays.

docs/manual/how-to/polymorphic-types.adoc, "Constraints". One bullet, in the register the existing bullets use ("is rejected at build time as a deferred capability" was already the house phrasing there), cross-linking the sort page.

Phase 3 adds no page: it changes which coordinates the existing deterministic-order rule catches, and sort-results.adoc’s "Constraints and pitfalls" list already states the rule. Re-read that list at phase 3 and correct any bullet the new population makes wrong. Phase 2 has no user surface, and neither does phase 1’s held `KEY_CAPTURE_SCATTER verdict; the page that shape needs (the routine write’s list return and what it does or does not guarantee about order) belongs with R660’s delivery, which is what decides the sentence. === Compatibility

Phase 1 breaks builds that passed before it. That is the intent, and it is what the reporting consumer asked for, but it is a real upgrade cost for anyone who has @defaultOrder on a multitable field and has not noticed it does nothing. Three consequences for the delivery:

Measured. intent_field_unlowerable_ordering reads in 53 milliseconds and 25053 scans on DerivedReadCostTest’s twelve-unit fixture. The seat relation is the whole of it, as the plan suspected: `intent_mutation_routine_seat reads in 55 milliseconds on its own, so the availability side and the participant arm add nothing measurable on top of a read another consumer already makes. The lever the plan held in reserve, keying the write arm off graphitron_routine_entry and the seat verdict alone, is therefore not worth taking: it would be the same relation. What the read does cost is two rows in DerivedReadCostTest’s pinned non-monotonic set, both inherited from the seat’s own row against `intent_spelled_table and both recorded there with their figures; the second is the diagnostic view, which reached no registration at all until it joined this rule.

The view is not registered, on the plan’s own reasoning: two readers per build, so a registration would pay a refresh to save two evaluations. Phase 2 is one pass over rows already in memory. Phase 3’s cost is unknown until the population exists and is the phase’s own measurement to take.

Phase 3 only; phases 1 and 2 retire nothing. Phase 1’s own KEY_CAPTURE_SCATTER verdict retires with its population if R660 lands the lowering rather than the rejection, and that retirement is R660’s to declare, not this item’s.

Three items independently reached the class and none carried it. The routine chain item stated it as "an ordering the model resolved does not reach the emitted SQL, and no check compares the two ends", noted that its own fix cannot make the invariant true, and said the shared enforcement question should be "its own item rather than as a rider on either". The @splitQuery item repeated it. A third (roadmap/root-family-validator-mirror-gaps.md) proposed a re-sourcing scoped to the routine-chain membership gap rather than to the invariant, and that bullet has since been closed by removing the carve-out, which left the invariant exactly where it was.

Note what all three were reaching for: a check that compares two ends. That is class C, and it is the half none of them could site because the validator is the wrong place to stand. Splitting the class three ways is what gives each half a home, and two of the three homes already exist. Siting class C took one more step than splitting it: the comparison only earns its name where the two ends are derived independently, which in today’s command tier is the multiset alone.

Filed 2026-08-14 as a re-sourcing of the enforcement off the launcher relation’s ordering slot, after three items named the shared enforcement question and none took it. Rewritten 2026-08-19 at the owner’s direction, in light of the fact-oriented pivot and roadmap/planners-read-facts-emitters-read-commands.md in particular: the launcher anchor put a build-time rejection one tier above the verdict it had to fail, on a population that excluded the site the item had already flagged against itself, and the same pass found the census splits three ways rather than two. The honesty half survives unchanged as class A. The re-sourcing half becomes class B at the fact tier, sequenced behind the launcher step. The comparison of two ends that all three predecessor items were reaching for becomes class C, which needs no new source and no new tier and can ship now.

The class A half is the reported half: https://github.com/sikt-no/graphitron/issues/523.

Specced 2026-09-01. Four things the spec pass changed rather than elaborated, each worth a reviewer’s attention because each is a departure from the body it was written against:

Phases 1 and 2 delivered 2026-09-08. Three things the delivery changed rather than elaborated, each recorded in the phase notes above with its reason: the fallback route’s location moved from the field to the @routine application, because a new view may not name the transcription; the rejection writer’s cadence moved after the materialization refresh, because the view reads a materialized relation; and both relations are declared in meta_relation, which is what forces their short comments and puts the essay in the declaration’s own rationale. The confirmation recipe found the sixth census site real, which is the one open question in the plan the delivery answered by measurement rather than by argument.

Reopened 2026-09-22 at pickup, Ready -> Spec, for phase 3 alone. The section of that name records both premises that gave way, the unmet launcher dependency and the intent_ family’s retirement, and what the re-spec does and does not have to re-decide.