Derived intent

Dissolving, and closed to new residents: what follows below describes what these relations are and how they came to be, not a standard to build another one against. The third and topmost layer of the SDL depth ordering, graphql_ under graphitron_ under this name, whose upper two layers are both derivation over what graphql_ captured: what gets derived once something resolves and combines those readings into what the generator will actually do. The residents are views plus the few tables hand-written producers fill, each of which says in its own comment why no view could express its rule; a rule SQL can state and a gatherer can run is that gatherer’s stage and leaves this family when it becomes one. That changes nothing about the name, since a family is named for whose vocabulary its rows are written in and storage is not the discriminator. The stratum has two layers, and a new resident picks one deliberately: the base derivations (the authored claim views, one per grain; the structural classifier views, one per classifier so each carries exactly its own witness columns; the resolutions those classifiers stand on, which earn their own relation as soon as a second reader asks them and which layer among themselves on that same rule, a resolution keyed on a written name sitting under the ones keyed on a coordinate; the demand and exemption rule views, stated at the grain their rules are authored at), and the reductions over them (intent_resolved_field_claim and the resolved demand views, the resolution expressions a planning reader joins). No relation may acquire this prefix at all. A crossing rule belongs to the gatherer that runs last, in a relation named for that gatherer’s vocabulary, which is what every departure from here has turned out to be. Nothing is admitted here any more, and the test that used to admit one is recorded because it is what a reader needs to understand the residents rather than to judge a candidate: an owner that is the gatherer running last rather than any one corpus’s own, decided by expand a candidate through every relation of this family it names until only captured relations are left, reading a materialized target as its rule so a registration cannot hide a crossing underneath it, and count the families those captured relations sit in, where graphql_ and graphitron_ are one family because they are one gatherer. Two or more is what this prefix is for. One means the rule belongs to that family instead, filed and named there and refreshed by the gatherer that owns it, which knows when its own corpus is complete and may therefore store the rule as one of its own stages or leave it a view. A rule that does cross still owes the cut: the part of it reading one family belongs to that family, and what stays here is the join. The contributor-facing statement of this rule, and the transaction control it presumes, are on the fact model page under the architecture docs.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The Java type the left side of an argMapping pair denotes: what the value the path resolves has to be assignable to. The missing half of every type question about this family, and the reason one existed to be missing is that the two populations answering it are unrelated relations. A @routine parameter is a position on a generated Routines method and its type comes from the catalog census, while every other site’s parameter is a position on an authored Java method and its type comes from the classpath census; a reader wanting "the type of the parameter this pair binds" had to know which of the two to ask, and therefore had to switch on site, which is the switch this relation performs once. One row per pair whose parameter resolves, at graphitron_argmapping_entry’s own grain, so it joins that relation and everything derived from it on site, use_site and position with no reshaping. Two arms over that vocabulary, and the split is not the pair view’s: one resolves an authored (class, method) pair against the classpath census, and the routine arm is the other and reaches sql_routine_parameter through intent_field_routine_method instead. It was eight arms until graphitron_method_reference_entry existed, seven of them resolving an authored pair the same way and differing only in which owner relation carried it. Those seven were one join all along, and what made them seven was that the class and the method were spelled in seven places instead of one; the reconstruction is now a join on the site key the pair relation already carries. A ROUTINE pair names a database routine and no Java method, so it draws no row from that relation and the inner join drops it, which is what the seven site literals used to do by enumeration. Matching is by parameter name on both sides, which is the same match the generator itself makes and inherits the same dependency: a consumer compiling without -parameters has no names to match, so a pair resolves nothing here and every reader sees that as absence. One vocabulary on both arms, and reaching it is the reason the classpath arm joins one relation further than it looks like it needs to. The catalog arm’s binding type is fully qualified, while code_type.display_name drops the package by design; comparing the two would never match, and the mismatch would look exactly like a genuine type disagreement. So the classpath arm takes the root of the parameter’s declared-type decomposition instead, code_type.root_class, which is the qualified binary name. That relation has no row where the position names no class, so a primitive parameter resolves no type here rather than resolving int. The join to it is therefore an outer one and such a parameter is a row carrying a NULL intent_argmapping_bound_parameter_type.java_type, which is the membership question and the type question being kept apart on the terms intent_node_id_decode_slot states for the same chain: the name-matched code_method_parameter row is what makes the pair a member, and the type is a payload the row may not carry. intent_argmapping_key_column_candidate.column_java_type is the other operand of the very same equality and already reads this way, its comment arguing that such an absence is a payload absence rather than a missing row. Absence of a row is therefore three facts and this relation distinguishes none of them: the reference resolved no method, the method declares no parameter of that name, or names were not compiled in. A fourth, the parameter’s type naming no class, is a NULL payload on a row that is here. That is deliberate, each being a condition other relations already state or reject, and it is what keeps this relation one answer rather than a verdict; what a reader does where the answer is missing is the reader’s own decision, and the projection’s own comment argues its choice. What it must not do is decide the reading, which is why candidates is a column: an overloaded method or a class declared by two classpath entries resolves two rows, and a reader requiring one type requires candidates = 1 rather than picking. DISTINCT within each arm collapses the ordinary duplicate, one method reached through two graph sources naming the same type, so candidates above one means the types genuinely differ. No assignability rule lives here and none should: this states one type per pair and comparing it to another is the asking reader’s predicate, the widenings worth admitting being a use-site question rather than a fact about a parameter.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The key column an argMapping binding of a node id projects out of the decoded key, with that column’s Java type beside it where the catalog can say: the name half of the projection resolution, before the type half decides whether the value can reach the parameter. Two arms over populations that are disjoint by whether a name trails the binding, because there are two ways to arrive at one key column and they are one destination rather than two. The authored arm is a trailing name naming a key column, which is the capability this family shipped with. The inferred arm is a binding that names no segment at all against a node type whose key is one column: nothing else it could mean, so the sole column is the projection and the author did not have to spell it. Whether the author named it is provenance and not shape, readable from trailing_name beside it, and both arms yield the same column with the same type reached the same way, which is what makes the emitted decode one emission rather than two. Their disjointness is a nullness rather than a precedence: a trailing name against none, on the match’s own column. The inferred arm reaches arity through intent_resolved_node_key_shape rather than counting the key list here, so the arity this population turns on is the same number the decode relation’s slot arm turns on, and the sole column’s type comes off that relation’s own payload rather than being a second spelling of the same catalog reach. Two or more key columns is no row on either arm and the detection beside this states why: one binding carries one value, so there is nothing to infer. Split out from intent_resolved_node_key_projection rather than living inside it, and the split is what lets a type mismatch be its own verdict: the detection beside it states an unknown column as the absence of a row here and a type disagreement as a row here with no projected row, so the two arms are disjoint by construction and neither has to re-test the other’s predicate. Absent this relation, adding the type predicate to the projection’s own join would have collapsed both into the unknown-column message, which names the wrong thing and offers the wrong remedy: an author who spelled the column correctly would be told it does not exist. The name match is the membership condition and the type is a payload, which is why the reach for it is an outer join and its absence is a NULL rather than a missing row. Requiring it would have re-broken exactly what the split fixed, and for a case the key-column relation deliberately admits: the pinned-SDL tier answers with no table at all, its own comment saying that a name resolving against nothing is a row there and a detection elsewhere, so a pinned key column under an unbound or ambiguously-bound node type would have stopped being a candidate and been reported as a column that does not exist. It stays a candidate with no type, and the gate downstream stands aside. Case-insensitive on both crossings, the authored spelling against the resolved key column and the resolved key column against the catalog. Neither operand of the first is a stored fold any more: the authored name is graphitron_argmapping_entry.tail_name and is folded there, on the relation that owns the spelling, so this side of the comparison is a stored column an index can serve. The key column is the side with nowhere to fold, coming out of a three-tier pick no single base relation owns, and it is folded per row here. The inferred arm crosses only the second of them, having no authored spelling to fold.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. What is wrong with an argMapping binding that descends past an input object: one row per defective entry, in a closed verdict vocabulary of five, over the match and the resolved key columns alone. The rejections that close the silent hole this family had, where a path bound a node id and the base64 wire id went to the database verbatim with nothing in the build saying a word. Every arm is a positive statement about a captured population rather than a negative space maintained by hand: the match relation says what each path bound, whether that thing declares a decode and what type it is, and the entry beside it says what was written, and these are the five ways such a path fails to become a projection. Which arm fires is decided by node_id_declared, whether the bound path is the whole written path or one name short of it, and two existence tests against the candidate relation, one in each of those two buckets, so the arms are disjoint by construction and no precedence rule is needed. That first comparison is the resolution against what the author wrote rather than a name this relation was handed: the match states what bound and the entry states what was written, and the difference between them is the question. A whole path bound under a declared decode is where the arity rule reaches this family, and BARE_NODE_ID is what is left of it. A one-column key needs no name, the sole column being the only thing such a binding could project, so it resolves as an inferred candidate next door and draws no row here. What remains is a binding with nothing to infer, and there are three ways to be one. They share a verdict because the defect is one and differ in a clause the consumer composes from node_type_ref and the key list: a directive naming no type, so there is no key list to count; a named type resolving no key columns on any tier, so the count is zero; and a named type whose key is two or more columns, where one binding carries one value and nothing says which. The arm is spelled as the absence of a candidate rather than as an arity test of its own, which is the same anti-join UNKNOWN_KEY_COLUMN uses one bucket over, so what resolves and what is refused are decided by one relation and cannot drift into two arities that disagree. One trailing name means the author named the column themselves, and then the resolution either succeeds (a row of intent_resolved_node_key_projection and no row here) or names what stopped it: MISSING_TYPE_NAME where the directive carries no typeName: and there is no containing table at this position to infer one from, UNKNOWN_KEY_COLUMN where the trailing name matches no resolved key column of the named type, KEY_COLUMN_TYPE_MISMATCH where it matches one whose Java type the consuming parameter cannot take. That last arm is the one the arity rule widens rather than shrinks, and deliberately: it drives off the candidate relation, so an inferred candidate whose sole column disagrees with the parameter draws the same refusal an authored one does, and a binding the arity rule stopped rejecting for being bare is not thereby allowed to hand a parameter a value it cannot take. Which of the two ways the column was reached is trailing_name’s to say, and it says it by being NULL, that column being read off the entry rather than forwarded through the resolution. This relation is where all of it is decided, and that is the whole of the design rather than a convenience. The schema walk that mints the binding runs before capture, so it has no store to consult; a rule spelled there would be an earlier, unfalsifiable second copy of one of these arms, and it would win by rejecting first, which is exactly how a family ends up with two answers that agree until one changes. So the walk carries every segment it cannot resolve against SDL and judges none of them, and every judgment about them is here. UNDECLARED_NODE_ID exists because of that division and would otherwise look redundant: it covers a path opening something with nothing to open, an ID carrying no @nodeId, and equally a String or an enum, the leaf_named_type column being what lets one message offer two remedies. A sixth verdict stood beside it for a path spelling two or more names past what it opened, and it is gone rather than unreported: the candidate relation now holds every legal spelling at a coordinate, so such a path names nothing there and is refused with every other unresolvable spelling instead of being a partial resolution with a count. Telling the two apart again would mean storing a decomposition of the written path, which is the relation this shape removed. Two shapes deliberately stay out, and both are stated because each was once mistaken for an arm. A list-shaped node id with one trailing name is not a defect: it names the list of that key column across the decoded ids, which is a coherent request, so it resolves as a projection and carries leaf_is_list, and what stands between it and emission is that no emitter builds that shape yet. And a projection that resolves at a site whose emitter is not wired is the same kind of fact. Both are deferrals rather than author defects, and whether an emitter exists is a fact about the generator’s own code and not about the schema, so their arms live with the consumer that knows the wired set (no.sikt.graphitron.model.derive.ArgmappingProjectionDefects) rather than being asserted by a view that cannot see it. An entry that bound nothing at all also has no row: nothing at its coordinate is spelled that way, which is the one rejection the walk still owns because it is a question about the SDL surface in front of it rather than about captured facts. Every arm is use-keyed rather than definition-keyed, which is the point of resolving at the pair’s grain: one input type can be consumed by a routine call with no containing table and by a table-bound mutation where inference works, so an author told to add typeName: is being asked to satisfy a use-site constraint and the message has to name the use site that is asking. Locations are the owning directive application’s, carried from graphitron_argmapping_entry, so a message points at the argMapping the author wrote rather than at the input type’s declaration. There is no message column: the closed vocabulary plus the witness columns are the fact base, and the prose belongs with the consumer that composes it. Nor is there a rendered candidate list, though a message about a named type wants one: a consumer joining graphitron_node_keycolumn on the graph and node_type_ref gets the columns as rows in key order, and a render here would have to be split apart to be used, which is the one thing no reader of this schema does.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Which rule resolves what one argument contributes to the filter surface of the field it sits on. The argument-grain counterpart of the field-grain claim stratum, and the relation a consumer building a generated WHERE clause reads before it reads any of the rules' own relations, because what it needs first is which of them applies. The classifier’s argument switch is an ordered fork rather than a set of disjoint tests, so this is a ranked collapse and not a union: @orderBy first, then a pagination-role name, then an input-object type, then the node-id decode, then the name match. Stating it as a union would let a @lookupKey-marked @orderBy argument surface twice, and picking either row would be a precedence this relation invented; the rank is the switch’s own order transcribed. Absence is where no rule answers, and every one of those sites is a rejection’s population rather than an argument that quietly contributes nothing: an unresolvable name, a repeated @reference, an @asFacet-style misuse. What the roles mean. ORDER_BY and PAGINATE contribute no predicate at all, the ordering and pagination facts consuming those arguments; PAGINATE reads the four reserved names, which is a generator constant rather than a captured fact and so is stated here in the derivation where the capture doctrine puts such things. INPUT_EXPANSION means the contribution is the argument’s input type’s own fields, resolved at their coordinates and not at this one, so a reader following it changes grain. NODE_ID means the predicate’s columns come from the resolved node key rather than from a name, and the population is the NODE_TYPE rows of graphitron_node_id_instruction rather than the directive: that relation already carries both readings, the authored @nodeId and the implicit one at an ID argument literally named id on a field returning a node type, with the type resolution and every decline it makes already applied. Reading that relation whole is what the kind column ended. An authored @nodeId may name a polymorphic container at a @service slot, so an instruction no longer promises a node type, and the kind predicate is this relation’s own rather than something the instruction relation already applied on its behalf. Restating either rule here was the first draft of this relation and it was wrong twice over, duplicating a rule the store states and getting the implicit one’s reach narrower than the store’s. What this relation adds is the wiring the instruction relation deliberately does not state: an instruction says the decode applies at a site, and whether the classifier can build a filter from it is a separate question with three exits. A @field(name:) binding beside it names two binding axes at once and the site resolves to nothing. On the implicit reading only, a column of that name on the argument’s own scope shadows it into nothing, a composite key without @lookupKey is unwired and resolves to nothing, and a list at arity one without @lookupKey falls through to the name match, which is the one exit that lands on another role rather than on silence. Those three are the implicit reading’s because the authored directive’s equivalents are the decode’s own forks, which graphitron_node_id_instruction and the decode relations below it already answer. Where a named type resolves to no key at all the fork is on the kind and not on the arity. A container is excluded by what it is, ahead of the three exits above: it resolves no key of its own, its members' keys being the decode’s business rather than a column this relation could project. A node type is read as the single-column shape, which is the shape a node has when nothing says otherwise, and no arity this relation could invent would change that. NAME_MATCHED means the predicate compares the column graphitron_argument_column_match resolved, and it covers the @reference-pathed argument and the plain one alike: the two are one rule here because the column resolution already tells them apart, its scope’s basis saying whether the predicate lands on the field’s own table or a join away. It also covers the argument of a multi-table polymorphic root, which it did not before the participant fan-out reached the column resolution: such a coordinate is rooted in one table per branch, the name resolves against each of them, and this relation had no row at all where the classifier lowers a predicate per branch. Which is where the grain of this relation and the grain below it deliberately part. The rule an argument falls under is the argument’s and is the same on every branch, so this stays one row per argument, and the branch-specific answer, which column on which table, is the resolution’s to give; a reader assembling a branch’s filter surface joins the match on the table it is assembling for. That division is the one this relation already declares for the monomorphic case, that it chooses the rule and does not assemble the predicate, and the fan-out only makes the reason visible. Two consequences worth stating rather than leaving to be met. A name that reaches a column on one participant’s table and none on another’s carries NAME_MATCHED here on the strength of the branch that resolved, which is a rejection’s population and reads as one only against the match rows, per the reading of absence this relation already takes. And the implicit node id’s shadowing modifier is an existence test over those same rows, so it reads "shadowed on some branch"; branches disagreeing on it is the same detection over the same pair, not a second vocabulary here. Two columns beside the role are modifiers and not arms, because the classifier treats them that way. lookup_key says the argument is consumed by the keyed lookup instead of the WHERE clause, which it can be on the node-id and name-matched roles alike, so folding it into the vocabulary would have split two roles into four. suppressed says an override cascade suppresses the generated predicate, from @condition(override: true) on the field or on the argument; it is not an absence because a suppressed argument carrying its own @condition still contributes that authored filter, and on an INPUT_EXPANSION row it is the cascade’s starting value for the walk into the input type. What this relation does not state is the predicate itself. Which column, which comparison and which reach are the resolution relations' answers, read through the role; putting them here would make this a filter-surface relation at the wrong grain, an argument being where the rule is chosen and not where the predicate is assembled.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. One argument-site @reference path element’s local resolution: the field-site sibling’s rule at the other coordinate a @reference can be written on. Every arm, every namespace precedence and every orientation is that view’s, and its comment is where they are argued; what differs here is only the relation the elements come from and the key they are keyed by, an argument being its own site. A sibling relation rather than an argument_name column on the field-site view, on the discipline intent_input_occurrence_path_step states for its own shape: the two sites' coordinates are different lengths, so one relation over both would carry a column that is NULL by kind on half its rows and every reader of either site would then have to say which kind it meant. Two relations say it once each. The duplication is the rule’s statement and not the rule, which is the trade this schema makes wherever a rule is coordinate-shaped. The two statements are no longer comparable as text: the field-site hop is the two jOOQ statements FieldReferenceStepHops runs into two keyed tables, and this one is a view, so the anchor test asserting that the two answer the same path shape the same way is the whole of what keeps them in agreement rather than a check on something a reader could also see. Where a resolution genuinely is shared it is already a relation of its own and both views join it, graphitron_spelled_table for a written table name, sql_name_matched_key_column for a function result’s column pairing and graphitron_condition_method_route for the route a condition method’s signature declares, so what remains here is the coordinate-shaped part alone. Separate from graphitron_argument_reference_step_target for the reason its field-site counterpart is: the local resolution has no recursion in it, and keeping the two apart lets that view’s recursive term be a single join rather than a copy of these arms. A view rather than a stage beside the walk that reads it, and that is a measurement rather than a reading of the shape. The walk names this relation in its recursive term, which is the position that re-expands a view once per accumulated row, and its arms are a four-way union over the catalog where the field-site hop is two keyed tables, so the asymmetry is real. Measured on a capture of the example schema, 915 fields and 305 arguments, eleven argument-site path elements, eighteen rows here, three sweeps with result reuse off: this relation alone visits 2870 rows in 4 to 5 milliseconds, and each of the walk’s two arm statements visits about 3010 in 10 to 12 with this relation a view, against about 175 in 3 with it snapshotted into a table, the snapshot filling in 6. So the recursion expands it about once rather than once per row, the chains there being eight, three of them two elements long and none longer, and storing it would buy about fifteen milliseconds a capture. A consumer whose argument paths run several elements deep is where that reading changes, and the reading to repeat there is the same pair.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The authored-claim conflict rule as a resident of the intent_ stratum: one row per violated coordinate, both grains, the store-native pilot of the diagnostics stratum’s derivation arms. A coordinate violates when two or more distinct classifiers claim it, and that is the whole predicate: the relation is total over the authored claims and carries no population filter of its own. An authored contradiction is a contradiction wherever it sits, so each consumer applies the population its own question needs (the build-error surface joins intent_type_domain, type grain directly and field grain through the claim’s owning type, because only the emitted surface can fail a build; the editor’s diagnostic arm reads these rows ungated, a type no field reaches being precisely where an author most needs the signal). What this relation does not carry is any accept line: a filter wearing the view’s name would substitute one consumer’s population for the fact. Nor does it carry the claiming directives or the violation’s message. The claims are rows on the two claim views under this relation’s own key, so a consumer wanting their names joins them and asks membership as well as set equality; the message is a render whose naming order is AuthoredClaim’s declaration order, which is not a captured fact and so is no view’s to express, and it is minted post-capture into intent_authored_claim_rejection instead. One piece of Java logic still lives in this SQL and is pinned by the registered agreement anchor (no.sikt.graphitron.rewrite.derive.AuthoredClaimConflictsTest): the routine-plus-lookup carve-out, exactly that claim pair being the recognised-but-unsupported combination, which yields DEFERRED instead of CONFLICT. Locations join as the legacy mint did: a field violation carries the field’s own declared position, a type violation the type’s base declaration site at merge ordinal 0.

The rejection each row of intent_authored_claim_conflict mints, minted post-capture rather than derived: one row per violated coordinate, carrying the sealed Rejection hierarchy’s verdict on it and the message a report would print. For example a field two directives each claim to produce draws one row, at the ordinal its conflict was minted in, carrying the message a build report prints.

Primary key: (graph_name, ordinal). Foreign key: (graph_name) references store_graph (graph_name). Check: "KIND" IN('INVALID_SCHEMA', 'DEFERRED').

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The author’s field-grain classification claims. One arm pair per claiming directive (@service, @externalField, @nodeId, @lookupKey, @routine, @mutation): the decoded arm reads the semantic relation, the presence arm falls back to the raw application where the decode declined. The per-arm type_name masks transcribe the walk’s per-position detector gates: @service claims at every position, @externalField and @nodeId nowhere on a root, @routine not on Mutation or Subscription (a Mutation @routine is the walk’s own typed deferral, never a conflict slot), @lookupKey only on Query, @mutation only on Mutation. The @lookupKey arm fires on the whole argument surface, matching LookupFacts.triggersFor: a directly marked argument, or an argument whose named type is in the transitive lookup-bearing input closure (the recursive path-guarded closure above, seeded from the retired input-field site, so on accepted schemas the recursion never expands). That closure recurses over input_object_field_edge, the field edges deduplicated to the pairs they denote, and not over graphql_field: the hop joins on the named type and projects the declaring type, so two fields of one named type are identical output rows that UNION ALL keeps and re-expands at the next hop, doubling the frontier per level of input-object nesting. Consumption is through EXISTS, so deduplicating the edges changes no answer. The @routine arms collapse the repeatable ordinal grain to the minimum-ordinal application’s row.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The author’s type-grain classification claims: @table and @error, decoded arm plus presence fallback each, with the root names masked out (transcribing the walk’s root short-circuit, which classifies a root before any type directive is read). That a conflict here can only occur on an OBJECT is guaranteed upstream by assembly (@error is declared on OBJECT), the same assembly dependency graphitron_undecoded_argument_entry records; a lone @table claim on an INPUT_OBJECT or INTERFACE is an honest single claim that conflicts with nothing. The applications sit at the type grain even when applied on an extension site; the presence arms collapse a base-plus-extension double application to the minimum-ordinal row.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Which catalog table an @table-bearing type is bound to: graphitron_table_entry’s reference resolved through graphitron_spelled_table, one row per candidate table. The reference is the name argument as written, or the type name where the argument was omitted, which is the derivation graphitron_table_entry.table_ref’s own comment defers; how a spelling then meets the census is the spelling view’s rule, stated once there and not restated here. What this view adds over that one is the keying: a type, not a string, which is what every reader of a binding actually holds. The three root names are masked, transcribing the walk’s root short-circuit that classifies a root before any table binding is read, which is the same mask the authored type claims carry. A base derivation rather than a resolved_ reduction: it stands directly on a transcription pair and nothing reduces over sibling views to produce it. It is one arm of such a reduction, graphitron_resolved_type_binding coalescing it with the binding a @routine chain’s return derives, and that is where a reader asking which table stands for a type points; this relation answers the narrower question of what the author wrote @table for, which is what an editor locating a written site and any reader of the directive population itself asks. Ambiguity is rows, never a decline: two candidates are two rows and the count says so, so a reader can transcribe the walk’s Ambiguous verdict (require candidates = 1, as the column-match classifier does), offer every candidate (as an editor does, since each is a table the author might mean), or report the ambiguity, without any of them re-spelling the resolution. The reference as written and the application’s position are one join back to graphitron_table_entry, which holds both.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The hop a routine write’s payload carrier takes to re-read its committed row, for a data field that declares no path. A @routine write on a mutation root may return a payload wrapping one data field beside an error channel; the routine call is the write, and the data field owns the post-commit re-read. That hop is inferred from the payload’s shape rather than written, which is precisely why graphitron_field_reference_step_hop holds no row for it: that relation’s population is authored path elements, and this coordinate authors none. So the same keying rule is reached from two relations, and it lives in neither of them. This one states the two ends and joins sql_name_matched_key_column for the pairing, exactly as the authored arm does, and for the reason the referenced-side discipline gives: the pairs are reachable from the triples this row already carries, and repeating them here would be a denormalisation. The departure is the routine the producing mutation field names, resolved as any written table name is and then required to be FUNCTION-typed. The arrival is the data field’s own named type’s binding, demanded unambiguous, an arrival that is not certain not being the one the re-read would run against. The producing field is required to carry no @reference, which is not a narrowing but the carrier’s own boundary: the chained form returns the terminus table type and has an authored element to resolve through, and @routine with @reference over a carrier return is rejected outright, so a row here would name a hop the generator will not emit. Ambiguity is rows, and here it is a real one the generator currently hides: two mutation fields returning one payload are two candidate departures, where the grounding memo keeps whichever field classified first. Absence covers several things and none of them is "this carrier has no hop": the payload is not a carrier, or its element is not table-backed, or its data field’s type binds ambiguously, or the routine name resolves to nothing FUNCTION-typed. One narrowness is inherited rather than chosen. The element_kind gate is graphitron_carrier_data_field’s, and that relation reads the @table population alone where this one reads the resolved binding, so a data field whose type is bound only by being what a routine returns is excluded upstream of here; the gate follows that relation when it moves, rather than this one reading past it.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The column-match structural classifier: a field whose name resolves against the table its site navigates to claims TABLE_COLUMN, no directive involved. Usually that is the parent’s own bound table, and where an authored @reference path moves the site it is the path’s terminal, which graphitron_field_column_scope answers for both and this view no longer decides for itself. One view per structural classifier, so the row’s columns are exactly this classifier’s join witnesses. The reading transcribes the classification walk’s fall-through arm: the field’s named type has kind SCALAR or ENUM, the site resolves against exactly one table (the resolution is graphitron_field_column_scope’s, which requires a single candidate on its parent-binding rule and so is how this arm transcribes the walk’s Ambiguous verdict; distinguishing that decline from a name not in the catalog at all is a future resolution-stratum detection over graphitron_table_entry, not something this view’s absence encodes), and the effective name matches a column, generated-Java-name tier before SQL-name tier, both case-insensitive, collapsed to the first match in tier-then-ordinal order. The effective name is the @field binding where one decoded, else the field name; the arm needs no undecoded presence fallback because a declined @field decode leaves the COALESCE on the field name, which is the walk’s own fallback. The scope drives the join and that is load-bearing rather than stylistic: H2 re-evaluates a joined derived relation once per outer row, so reading the scope from underneath graphql_field costs the whole relation per candidate field and measured seventy times this shape on a store holding a dozen graphs. Any relation joining a derivation this deep wants the derivation first in the FROM clause. Deliberately mask-light: the only exclusion is the three root names, and it arrives through the scope view’s own binding read rather than being restated here, roots classifying before any table binding is read. The scope’s parent-binding rule is mask-light for the same reason, so a coordinate an authored directive claims still produces the structural reading here and the reduction is what drops it. No parent-kind gate and no directive knowledge: masking against authored claims is the reduction’s job, and the raw structural reading surviving here is what lets a diagnostic say "would classify as a table column; @service overrides it".

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Which tables a coordinate contributes a WHERE clause against, one row per coordinate and table. The condition family’s membership fold: a consumer minting the generated filter glue reads this to know which glue exists, and every other relation in the family answers a question about a row this one admits. Membership is presence and nothing else, which is what makes it a fold rather than a payload: what the predicates are, which columns they compare and which arguments carry them are the resolution relations' answers, read through this one. The rule is that the coordinate’s lowered filter surface is nonempty, and it is nonempty when any of five sources contributes. Three are authored and cannot be suppressed, a @condition being a method the author wrote and asked to have called: one on the field itself, one on any argument of it whatever that argument’s role, and one on any input field the field’s arguments reach at any depth. Two are generated and can be: an argument whose role resolves a predicate, and an input field whose role does. The generated pair is where the modifiers matter, and they are read at the grain the classifier reads them at. An argument contributes only when its role is one that resolves a predicate, which is NODE_ID or NAME_MATCHED and not the four that resolve something else; ORDER_BY and PAGINATE are consumed by the ordering and pagination facts, and INPUT_EXPANSION contributes nothing of its own, the contribution being the fields below it, which arrive here as the input-field sources instead. An input field contributes under the same two roles, and additionally not when the override cascade suppresses it, which is intent_input_occurrence_override read at the occurrence rather than at the field, and not when a @lookupKey consumes it. That last exclusion propagates: a @lookupKey on the argument consumes the whole expansion beneath it, so an occurrence under such an argument contributes nothing at any depth, which is a rule about the argument applied at the grain of the field under it. Four kinds of coordinate are excluded outright because their filter surface is not a filter surface. A mutation’s predicates come from the write partition and not from here, and the write payload argument that would otherwise read as a filter is the largest part of what that exclusion removes. A @service field generates no SQL at all. The relay node field resolves a node and never filters, its shape carrying the node-resolve member and no condition member however its id argument classifies. And an argument consumed by a keyed lookup is the VALUES-and-join path rather than the WHERE clause. Each is stated as its own exclusion rather than folded into one predicate, because they are four different reasons and a reader debugging a missing row wants to know which one fired. The table side is graphitron_field_scope_table at its own grain, which is why that relation’s grain had to be corrected before this fold could exist: a @condition on a field with no arguments has a table to filter and no argument to carry it. A multi-table polymorphic root gets one row per branch here for free, that relation carrying a PARTICIPANT_TABLE row per participant table, and the branch fan-out is therefore the scope table’s and not this relation’s. Membership itself stays a property of the coordinate: a name that resolves a column on one participant and not on another is a build failure at that participant rather than a membership difference between branches, so the fold has nothing to decide there and deliberately does not fan the sources out. A consumer minting the per-participant glue method, whose name is the participant’s, joins intent_field_participant_scope_table on the table. Three populations are missing from this relation and each is measured rather than supposed. The store has no read-side refusal: a coordinate whose argument classification fails is refused whole and has no filter surface at all, and where the write partition states its refusals in two relations of their own the filter surface states none, so a refused coordinate has a row here that no consumer will find glue for. On a schema that builds, that population is empty, every refusal being a build failure; it is the fold’s one structural gap and closing it is a relation of its own. One more is a silence one rung up, found by diffing this relation against what the producer emits for the example schema and filed: a field returning an author-declared connection type has no scope row, so a coordinate whose only table would come from that row contributes nothing here that the generator does contribute. That diff is no longer run by hand. no.sikt.graphitron.rewrite.derive.ConditionMembershipShadowTest holds this relation’s key set against what the producer yields, so a population that goes missing announces itself as a failing test with the coordinate named rather than as a count in this sentence that nothing recomputes; it retires with the walk when the producer reads the fold. The sibling silence that sentence used to carry, an argument whose @reference path ends in a condition hop resolving no column, is closed: such a path resolves through graphitron_condition_method_route and lands a column scope like any other. Absence otherwise is every coordinate that reads no table, every coordinate whose arguments all resolve to something other than a predicate, and every coordinate whose generated predicates are all suppressed while it carries no authored condition to fall back on.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Where a @condition parameter bound to a slot is exempted from the declared-type extraction rule and receives the slot’s decoded node key instead, and what shape that key has. The override half of a pair: code_method_parameter.extraction states the standing rule by declared type, this states the exception, and presence here is the whole of what says the exception applies. Absence is not a silence; it is the assertion that the declared-type rule stands at that coordinate, which is the shape the fact model uses wherever a rule has an exception rather than a variant. The population is every slot carrying the @nodeId instruction that a @condition names a class and a method at, and a slot is named two ways: by its own directive, and by a directive on the field whose arguments it is one of. So the arms are three where the slot sites a value is bound from are two, an argument and an input field. Each arm reads its directive at the coordinate capture wrote it to: an argument condition at the three-part coordinate, an input-field condition at the shared field coordinate with the owning type’s kind INPUT_OBJECT, and a field-level condition at that same shared coordinate with the kind an object or an interface, the slots it sees being its field’s own arguments. They are one relation because they are one rule: the generator installs the decode keyed on the slot, so a parameter bound to a @nodeId argument receives the decoded key however the directive binding it was written, and an arm missing here would assert the declared-type rule stands at a coordinate where it does not. Keyed by the method as well as by the coordinate, for the reason the third arm makes visible: one argument can be named by its own @condition and by its field’s at once, and those are two authored methods each receiving the decoded key, so class_name and method_name complete the key rather than riding as payload of the coordinate. Two directives naming one method at one coordinate stay one row, which the third arm’s anti-join is what says: the exemption is a fact about a slot and a method, and a second directive asserting it again adds no fact. Use-keyed, and that is the point of it being separate: the rule the extraction relation states is a fact of a signature and the same signature written at two sites is one row there, while this is a fact of a site, so one method named by a @nodeId-bound slot at one coordinate and a plain scalar at another is one row here and not two answers on one method-keyed row. The coordinate it carries is graphitron_node_id_instruction’s own, so a reader holding a use site joins straight across; the instruction relation’s multiplicity is inherited whole, one row per consuming coordinate for an input field and one row for an argument. What this relation does not say is which of the method’s parameters receives the decoded key. That is the binding question the fact model defers everywhere: which parameter takes an argument, which takes the source table and which takes a context value is decided per directive application from the slots and the context keys in scope, and code_method_parameter’s own comment defers it for the same reason. A reader that has resolved the binding for itself, which the editor and the validator both have, reads the shape here and needs nothing further; a reader that has not cannot get it from this relation and must not read the row as naming a parameter. The shape is stated as an arity and a list flag rather than as a Java type, because the type is the generator’s composition of two facts a reader already has: the key columns' own types, at graphitron_node_keycolumn’s grain, and the wrapping this relation names. An arity of one means the key column’s own type, above one means the typed jOOQ Row of the key columns in key order, and list_valued wraps either. Spelling the composed type here would be a second statement of a convention that lives in generated code, and it would go stale against a column type change this relation cannot see. Population boundary, since a hole reads as an exemption that does not apply: a slot whose node type resolves no key columns has no row, the arity join being what excludes it, and that coordinate already meets a shipped rejection naming the type rather than needing a row here to be silent about. A parameter reached by a dotted argMapping into the key columns of the same slot is a different mechanism at a different grain, the projection rail’s, and is not this relation’s exemption; the two do not overlap because a dotted binding is not a whole-slot binding.

One GraphQL slot in scope at one application of a @condition: one row per argument or input field a parameter of the named method may bind there. For example a field condition on films(rating: String, first: Int) draws two rows, one per argument, while a condition written on the rating argument itself draws only that one.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The classes a declared type delivers something through rather than delivers: the container vocabulary the peel descends, one row per class with the type-argument position its element sits at. Named data rather than a predicate spelled inside its reader, and its own relation because the peel reads it twice, once to descend and once to ask whether a position can descend at all. A rule that decides which classes are containers is exactly the kind that must have one home. They are named rather than recognised through a closure over the declared supertype relation because such a closure cannot answer here: nothing ships the JDK as a classpath entry, so java.util.List declares nothing the census holds and standing in for it is unreachable from below. The set is closed by what a generator meets rather than by what Java offers, so a consumer returning its own collection type is not a container here and delivers itself; widening it is adding a row.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Which field of a type is an error channel: a nullable list of a polymorphic type whose every member carries @error. One row per such field, total over them, and a field’s shape alone decides it, so this says nothing about whether any producer routes errors into it; a type nobody returns has its errors field named here exactly as a payload’s does. That is deliberate and it is what lets the relation be shaped by the field rather than by the producer, which is the difference between stating a fact and stating one reader’s question. The shape is four conditions and every one of them is the walk’s own. The list must be nullable because a non-null list would raise a non-nullable-field error on the success arm, where the channel resolves to no list at all, and take the sibling data field down with it. The named type must be a union or an interface, a single @error type not being a channel: the dispatch table the channel drives is a choice among mapped types and there is nothing to choose. Every member must carry @error, one that does not making the container a mixed result type rather than an error list. And an @asConnection field is excluded, its wrapper being a Connection rather than a list, so the shape it presents to a channel reader is not the one it presents to graphql-java. The container’s members in their order are intent_errors_field_member, a child rather than a column here because a list is rows; the count of them is that relation’s to answer and not a number stored beside its own rows. This was the errors_field CTE inside graphitron_carrier_data_field, promoted on the second reader: the carrier scan asks which of a payload’s fields are not data channels and the error channel asks which one is the channel, and two readings of one shape is where a fact model puts a relation. Where a payload declares more than one errors-shaped field the walk takes the first in declaration order; this relation names all of them and carries the ordinal that decides, the picking being intent_field_error_channel’s. Not materialized, and the registration it carried was retired once the rule stopped being expensive. Two arguments retired it and only one is about time. On the clock the registration cost 0.21 s of refresh per capture and its one registered reader’s refresh rose 0.12 s without it, so holding it was dearer than not, by a margin this schema’s harness cannot resolve from noise. What decides it is the other cost, which no timing of the registered arm can show: a materialized target is a table with statistics of its own, so every planner decision above it bottoms out there, and the rule underneath becomes invisible to the planner and to anyone reading a plan. That is not hypothetical here. This relation’s own cost was a window function in intent_poly_member, five and a half seconds of it, and it sat unseen behind this registration until the register was emptied to look. A registration that is not paying for itself is not neutral, it is a blindfold over whatever is underneath it.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The @error types one error channel maps, in order: the ordered child of intent_errors_field, one row per member of the field’s container. Every member carries @error, that being a condition of the parent relation admitting the field at all, so this relation needs no error predicate of its own and a row here is always a mapped type. Ordered because the consumers are ordered: the dispatch table is tried in this order, and the fingerprint that disambiguates two channels sharing a constant name is a digest over the flattened handler list in this order, so a re-ordering is a different emitted name and not a cosmetic difference. A child relation rather than a column on the parent because a list is rows; a column holding a serialized member set would answer set equality and nothing else, which is the reading intent_type_backing_conflict declines for the same reason. Keyed by the errors field and not by the container, so two fields naming one union are two ordered lists rather than one shared by reference: that costs rows and buys a reader the ability to join on its own coordinate without knowing the container, and the container is a column on the parent for the reader that would rather group. The handlers each of these types declares are graphitron_error_handler_entry’s, keyed by the type alone, an @error type’s handler list being the type’s property and not this channel’s.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Every @key a graph’s emitted schema carries, authored and synthesized alike: the composition two readers already ask for, the round trip that re-emits the applications and the agreement anchor that pins the derivation against the pipeline’s registry rewrite. A relation rather than a union each of them assembles for itself, on the rule that a composition with a second asker is a relation. The grain is the authored relation’s, with a NULL ordinal on the synthesized arm rather than an invented one: document order is a property of something the author wrote, and a derived row has no position in a document. UNION ALL and not UNION, deliberately. The authored arm is unique on its own key already and the synthesized arm cannot collide with it, its condition being that no authored id key exists, so deduplication could only ever fold together rows a reader wants told apart: two authored @key(fields: "id") applications at distinct ordinals are two rows here, which is the arity the authored relation states and this reduction owes its readers. Key grain only. The path and segment children stay authored-only until a reader asks for them composed, the synthesized arm’s single id path being recoverable from fields_sdl by the same rule that would have decoded it. A reader wanting a total order over both arms orders the authored rows by ordinal and appends the derived one, which is the ordering the composing query owns rather than one this relation invents.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Where an accessor hop lands: for a field coordinate and a class its parent might stand on, the class the member reading that field delivers. One edge of the walk that binds SDL types to backing classes, stated as a fact instead of as a step, so the closure over these edges is a reader’s recursion rather than a rule buried inside one. The slot a coordinate reads is the @field(name:) override where the field carries one and the field’s own name otherwise, which is the resolution the emission side makes, and @field lands on both axes so both resolve the name the same way. What they do not share is what the name resolves against. An output field is read off the class its parent stands on, so it resolves against an accessor; an input field is written into the class being built, so it resolves against a constructor argument or a setter. The two are different member sets on the same class and a class can offer one and not the other, a data holder with a getter and no setter answering an output field and no input one, so this relation has an arm per axis rather than one population keyed by the coordinate’s owner kind. The owner’s kind is what picks the arm, and only one arm tests it: writing is what the input axis does, so the write arm asks whether the owner is an input object and the read arm takes everything else. Stated that way round deliberately. A positive test on each side would make the arms depend on an owner having been typed yet, and a coordinate whose type relation has no row for it, which a minted one is until the stage that mints it has run, would answer neither; as a complement the read arm keeps it, which is what it had before there were two arms. It also leaves an interface’s fields where they belong: an interface is not an input object, its fields are read, and a rule naming the object kind positively would have dropped them. The population is the expanded one rather than the transcription, so a coordinate on a type the expansion minted hops on the same terms as one an author declared: reading the transcription here would leave a minted Edge’s node field with no rows, which is the one edge that says what a connection’s element stands on. Total over standing classes by construction. Nothing here says which class a parent actually stands on, so a coordinate pairs with every class in the graph’s sources offering a slot of that name, and a row is a conditional rather than an answer. That totality is what makes this an edge relation instead of another copy of the binding, and it is why this is a view that is never materialized: the product is large wherever a slot name is common and small wherever a reader binds the standing class before asking. Ambiguity is rows and no count. Two spellings of one property are two slots on the stated terms of whichever relation the arm reads, and both already decline to choose between them, so a count here would be a second stance on a question those relations have settled. Two departures from the walk this replaces, both to be adjudicated against its shadow rather than assumed harmless. The first is that an SDL field’s arguments are not read at all. The walk probes for an accessor whose parameters match them, and a slot is a no-argument member by definition, so this relation hops where the walk would not (an argument-taking field standing on a no-argument accessor of the same name) and stays silent where the walk would hop (a field whose accessor takes those arguments). Reading the shape here would mean a slot relation holding parameterised members, which is a different question from the one that relation answers, so the difference is recorded rather than quietly closed. Every join is on a whole primary key. Both arms are two steps: a slot names the type it yields or takes, and that type names what it delivers. Which arm produced a row is deliberately not a column: nothing downstream reads it, the closure over these edges wanting only where a hop lands, and a column saying which member set answered would be a fact about this relation rather than about the binding. The second is that the walk skips a field carrying @service and skips a child type already bound; both are conditions on the closure rather than properties of an edge, and neither belongs here.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Where a field’s @routine chain stands after each step, and how it got there. The chain is the field’s @routine and @reference applications walked as one running source; this relation is every place along it, and the one recursion in the family. A node at seq 0 is the routine’s own result, which intent_field_chain_start resolved; a node at seq k is where the k-th @reference path element written after that application lands, each departing from the previous node’s arrival through graphitron_field_reference_step_hop, exactly as graphitron_field_reference_step_target walks a path from a type’s binding. No foreign key can carry the first element out of the function result, a function result declaring none, so the two arms that reach one are the hop relation’s name-matched arm and its condition arm, which route by column name and by the condition method’s signature respectively. Which elements are the chain’s is a comparison of source positions and not of ordinals, because @routine and @reference number their ordinals separately; the start carries the position that comparison is made against, so the rule that picks the last routine application is stated once, there. An element written before the routine is not in the tail at all, moving where the chain starts and never where it ends. Absence means "not reached", as on the target view: an element resolving to nothing ends the walk, so a chain whose second element is fine but whose first names an unknown key contributes only its seq 0 node, never a node standing where the walk did not arrive. last_seq is what makes that legible without a second relation, being the tail’s own extent rather than the walk’s: a walk that stalled has no row at last_seq and therefore no terminus, and a reader wanting to say where it stalled compares the two. The route into each node travels with it, which is the difference between this relation and the landing relation over it. A reader that has to render the chain’s joins needs the constraint and its orientation at every step, and before this relation those columns were computed inside a walk and then dropped, so a reader needing them had no choice but to write the walk again. Two vocabularies, kept apart on purpose: via says which directive put the chain here, in intent_field_chain_terminus’s own words, and step_via says which arm of the element’s resolution moved it, in graphitron_field_reference_step_hop’s. One relation carrying both under one name would make every reader say which it meant.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Where a field’s @routine chain begins: the last @routine application written on the field, resolved to the table-valued function result it names. The last and not the first, because a second @routine application restarts the chain rather than extending it, so the chain a reader cares about departs from the last one; applications before it move where the chain starts and never where it ends. Two conditions, and both are the resolution rather than the rule: the spelling resolves through graphitron_spelled_table as any written table name does, and the result is then required to be FUNCTION-typed, which is the only kind @routine accepts. A routine name resolving to no FUNCTION-typed table yields no row, and the chain over it therefore has no start, no nodes and no terminus, which is the silence intent_field_chain_node states the general form of. Its own relation because two things need it and each needs a different part: intent_field_chain_node seeds its walk from the landing, and a rejection about an unresolvable @routine names this coordinate, which is what the source position on the row is for. That view’s tail used to need the position too, to find the elements written after this application, because @routine and @reference number their ordinals separately and no relation related them; it reads graphitron_field_chain_application now, which states the written order across directive names as rows. No arity column: two schemas declaring the routine’s name is genuinely two rows here, and the count a reader wants is over the chain’s landings rather than its departures, which is intent_field_chain_terminus.candidates. Adding one would put a second window function under a relation the node walk inlines, and buy a number nothing asks this relation for.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Where a field’s @routine chain lands, and what kind of table it lands on. The chain is the field’s @routine and @reference applications walked as one running source, and its terminus is the last node; every read-surface axis on a routine-backed field is a question about that node. Which table an ordering or a filter resolves its column names against is the terminus, and whether the terminus is a table-valued function’s result decides whether an ordering can fall back on a primary key at all, a function result having none. Both were answered per axis before this relation, each from the directives directly, which is how one property of one catalog object came to be restated as several unrelated refusals. Population: fields carrying at least one @routine. A field whose navigation is @reference alone has a terminus too and it is not this relation’s, graphitron_field_column_scope’s PATH_TERMINAL rule answering it from the type’s own binding; the chain arm that view is missing should read the chain relations rather than grow a second copy of the walk. A selection and not a walk: intent_field_chain_node carries every place the chain stands, and the terminus is its rows at seq = last_seq. That extent is the written tail’s and not the walk’s, so a chain whose walk stopped short has no row here at all, which is the same silence this relation always kept and the reason absence means "not reached", never "resolves to nothing in particular"; where such a walk stopped is now answerable on the node relation, by comparing the two. Ambiguity is rows, and they are landings rather than routes: an element reaching one table by three foreign keys is one row here where the node relation has three, a terminus being a place and not a join, and a reader that has to render the join reads the node relation where the routes are. Two schemas declaring the routine’s name is genuinely two landings, and candidates says so.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Which table a column name written at a field’s site resolves against, when that table is not the one the field’s own parent is bound to. The question an editor asks at a @field(name:) or @defaultOrder(fields: [{name:}]) site, and the resolution three LSP arms (completion, hover, the field-member diagnostic) each used to ask a projected per-permit switch. The navigation itself is graphitron_field_column_scope’s and no longer restated here: this view is that relation read as an override, its two non-parent bases carried through as RESOLVE rows and its parent-binding rows dropped. Deliberately narrow, which is what dropping them means: a field whose column names resolve against its parent’s own binding contributes no row, because a reader already holding the parent’s binding needs no relation to tell it so, and stating that case here would make this view a copy of the scope keyed one grain down. Absence therefore means "the parent’s own scope answers", which is the reading every consumer already falls back to; only a row overrides it. Two rules produce silence, meaning "no column name resolves here, and the parent’s scope must not stand in", and both are this view’s own rather than the scope’s: a coordinate whose classification the author has already contested, and an authored path that reaches no single table, the second read as the scope answering a path-carrying field with no terminal. The conflict silence stays here on purpose, because the column-match classifier reads the same scope and its raw reading at a contested coordinate is what lets a diagnostic name the override. The silences are structural, never a reading of the rejection residue: a derivation that asked the residue whether a coordinate had been reported would go quiet the day that family drains, and this relation’s meaning must not depend on where a message currently lives.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The types whose fields require a classification verdict, one rule literal per arm. Type-keyed by design: every rule shipped so far is a property of the parent type, so this is the rule’s authored grain and the field grain is a join in the resolved view, legible as a projection rather than materialized into the rule literal. The root arm is keyed by the root operation binding, not the conventional names, so it states the intended rule; today’s walk dispatches on the literal names Query and Mutation, and a renamed root’s fields are a known demanded-but-unregistered population the shadow agreement pins. The producer arm covers the payload types whose producers capture can see (@service and @externalField references that decoded to a class, and every DML @mutation payload); a DELETE payload’s data field is thereby demanded even though today’s walk loses its verdict on every path but the ID-element repayment, which is the other pinned population. The underscore masks transcribe the walk’s short-circuit: an underscore-prefixed type never classifies, whatever it carries, while a root binding is checked before that short-circuit and stays unmasked. Each rule’s witnesses live one join away in the arm’s base relation; this view carries the rule key only, so no arm’s witness columns go nullable on the others.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Which coordinate has an error channel and what the channel is made of: one row per producing field whose returned type declares an error channel, total over them. The grain is the producing coordinate and not the payload, because a channel is something a field routes its throws into and two fields returning one payload are two channels, which is exactly the population the constant-name dedup groups over. Which field of the payload is the channel is intent_errors_field’s answer and the pick is this relation’s: a payload declaring several errors-shaped fields routes through the first in declaration order, so the join takes the minimum ordinal and carries it, the walk’s first-wins rule stated as a column rather than left implicit in a scan order. What the relation carries is the channel’s inputs and never its minted name. mappingsConstantName is a generated identifier, and a column holding one would make this relation a second site where a naming formula is spelled; the formula’s one home is GeneratedUnits, which reads these columns. That is the whole reason the payload class is here in binary form and the payload type in SDL form: the fold that mints the constant takes one of them depending on the transport, and a store that carried the folded result instead would have decided which. The transport is a decode over three facts and a precedence, not a transcription of the classifier’s control flow. A root @service field rides the typed Outcome wrapper, whichever shape its payload has, so that arm is tested first and wins over the carrier arm where both would answer; a payload the carrier recognition admits under the producing family is a directiveless structural wrapper whose catch arm ferries through graphql-java’s localContext; anything else constructs a developer payload class at the catch site. The precedence is real and stated rather than partitioned away, a root @service payload being a carrier under its own family as well. Ambiguity in the backing class is an arity and not a pick, on intent_bound_table’s terms: a payload two populations back differently reports the count and no class, so a reader needing one class sees the contest here instead of receiving a silent winner, and intent_type_backing is where the contesting classes are rows. A coordinate whose payload declares no errors-shaped field is absent rather than present with a null transport, this relation being total over channels and not over producers; a producer with no channel is a fact intent_field_payload_producer already carries.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The types whose fields are intentionally not demanded, a reason per arm, type-keyed like the demand rules. Arms are unmasked against each other and against demand, so overlapping readings survive as rows (a structural connection type is also a directiveless object, and both rows are true); one-reason-per-coordinate is the resolved view’s job, per the same masked-reading argument the column-match classifier records. The interface arm is the census’s largest population (no interface’s fields ever classify); the input arm makes the trace-only input coordinates explicit rows; the underscore arm transcribes the walk’s name short-circuit at the field-bearing object kind (interfaces and inputs are already covered by their kind arms); the machinery arm is the structural connection recognition (an object with an edges field whose object element has a node field, reached by some carrier field, plus that shape’s edge type, plus the SDL-declared PageInfo when any promotion would fire), whose fields the connection emitter owns; the nesting-target arm is the walk’s own absence-shaped rule (a plain object with no classifying directive, no root binding and no store-visible producer resolves through its embedding edge, or is an orphan whose rejection surfaces at the referencing field), stated by its own predicate rather than as an anti-join of the demand view, so the two relations state their rules independently and the resolved view owns their meet. Types bound only through the reflection fixed point (accessor chains, record-composite carriers) are deliberately in neither this view nor the demand view; that population is the shadow residue whose store-side closure lands with the binding-walk classifier migration.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Which type a field’s own generated SQL navigates as: the type whose binding, whose members and whose columns a rule at this coordinate should read, as against the type the field’s signature happens to name. The two differ wherever a wrapper stands between the field and what it delivers, and a rule that reads the signature at such a coordinate reads the wrapper’s facts, which are none. Total over graphql_field: every field navigates as something, so a consumer joins this rather than left-joining it, and the fallback rung is what makes that true. Two rungs, and the relation is a projection of graphitron_field_navigation, which is where they are computed and where the rules are stated. The connection’s element where the field’s named type is a connection, and the named type itself otherwise. A third rung is retired and worth naming because its absence is a result rather than a simplification: it read the expression the author wrote wherever a macro had rewritten the field, and measured over a consumer-size schema every row it answered is the row the two rungs below it answer, a synthesised connection’s edges.node being the element the authored expression named. It was also the only rung needing something no relation held, and therefore the only reason this rule had to be computed where the parse was. This relation is the correction of a resolution that had five spellings. The COALESCE over the synthesis record was written out at five sites, and all five read the same way: a connection navigates as its element when the generator built the connection, and as the wrapper when the author wrote it. The second half of that sentence is a silence and not a rule. A field returning an author-declared connection type resolved to a type binding no table, so it had no scope table, so its arguments had no scope, so a filter argument on it resolved no column and the condition membership fold could not see it, all from a rule that claims to navigate connections and only navigated the ones with a synthesis row. All five sites read this relation now and are correct at both halves: graphitron_field_scope_table, intent_field_participant_scope_table, intent_routine_return_binding, intent_mutation_routine_seat and graphitron_field_column_scope’s named-type arm. The rule to hold this relation to is not a count, which has been wrong twice by construction and is what an unguarded inventory does: every site that needs a field’s navigated type reads this relation, and the next spelling it exists to prevent is the one nobody has written yet. One thing a new reader owes itself, learned at the last site to arrive: join what this relation projects, and join it directly. A reader that takes the navigated type from here and then joins a binding onto some other relation’s echo of that name hands the planner a cheaper driver than this one, and a view is seekable on the coordinate it is keyed by rather than on a name it projects, so the relation lands on the probed side and is evaluated once per driving row. That is a property of every projection in this store and not of this arm, which is why it is stated here rather than only there. The basis column says which rung answered, so a test can pin the rule rather than only the answer. What this relation does not do is resolve anything: it names a type, and whether that type binds a table, holds polymorphic members or declares columns is each consumer’s own join. Nor does it look through a polymorphic container; a field returning a union navigates as the union, and the members are intent_poly_member’s answer read from that name. Declared before intent_routine_return_binding because that is the first of its readers, and the ordering here is a dependency rather than a reading order.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Which table one participant of a field’s polymorphic named type binds: the table that participant’s own branch of the field’s generated SQL is rooted in. A field returning a union, or an interface carrying no @table of its own, resolves to several tables rather than to one, and the classifier answers it by lowering the field once per table-bound participant, each against that participant’s own table; this relation is that population, one row per participant the field’s named type holds a binding for. The participant’s type name is a key column and not provenance, because it is what a consumer needs beyond the table: the generated condition method is named after the participant rather than after the container, so two participants of one field are two named units and a row carrying only a table could not tell a consumer which. Disjoint from both of graphitron_field_scope_table’s ranked rungs by construction rather than by precedence, which is why that relation unions this one in outside its window instead of ranking it as a third rung. The container binding nothing of its own is this relation’s own precondition, and it is exactly what separates the shape from the single-table discriminated interface, whose interface does carry @table and whose participants therefore share one table and one filter surface; a field carrying a @mutation(table:) spelling that resolves is excluded for the symmetric reason, the author having said which table the coordinate’s SQL binds against. Each participant’s binding must be unambiguous, on intent_field_reference_discovery’s terms and for the reason the ranked rungs give: a branch is a statement and two candidate tables are two different statements. A member with no binding at all contributes no row and no rejection here, the container whose every member must bind being the type classifier’s invariant and not this relation’s; a partially bound container is therefore incomplete here and rejected there, which is the division of labour every rule relation in this family keeps. Two participants binding one table are two rows, the grain being the participant; a consumer that wants tables takes them through graphitron_field_scope_table, whose projection of this relation is distinct on the table for that reason. Nothing here says any argument or name at the coordinate is column-shaped: this relation answers where each branch is rooted, and what each branch filters on is the argument-site resolution’s answer, reached one table at a time through that projection. Read cost, measured on the sakila example schema at 917 fields and 267 arguments, 128 rows out, five interleaved sweeps with result reuse off, so every figure carries an execution count above one and a standard deviation. The shape that ships joins the membership directly onto the stripped type expression and costs 47 milliseconds. Projecting that expression into an inner derived table first and joining the membership on the column costs 27, a 42% saving that is measured, reproduced, and deliberately not taken; the paragraph after this one is why, and it is the more useful half of the measurement. Two controls decided the rest. Driving from the 52 membership rows rather than the 917 fields, which reads like the obvious win, measured 29 milliseconds with three times the spread, so the smaller driver bought nothing. And the shipped shape with both exclusions removed measured 42 against 47, so the two anti-joins are about a tenth of the cost and the expansion is the rest; both children price under a millisecond, the membership at 0.3 and the binding at 0.04, which is what says there is no expensive child to register underneath this. The projection was called unshippable here for two builds and it ships now, which is worth the sentence it takes to say what changed, because the reason it was unshippable was real. The projection changes which plan H2 takes for this relation and for the two above it, and under that plan the registered read of graphitron_resolved_type_binding visited more rows than reading its source view would, for this relation, graphitron_field_scope_table and graphitron_argument_scope_table_rule alike; the read-cost gate of the time asserted the opposite over every such pair, so the projection failed the verification build deterministically. What closed it was not a rewrite but an index. The registration on graphitron_resolved_type_binding shipped without one, which cost nothing while every reader spelled its type expression inline, H2 pushing that expression down into the probe, and stopped costing nothing the moment the expression became a column: a join onto a projected column is one the planner may satisfy by scanning. ix_resolved_type_binding_type is the probe those readers actually make, and with it this relation and the field-grain scope table above it are both monotonic again. The same measurement carries its own warning, and it is the fact model’s: three readers further down the write family are still counted non-monotonic through that binding while their wall clocks did not move at all, so the counter and the clock disagree there and the read-cost gate’s pinned set recorded which was which. This relation’s own clock is what it costs: the projection took it from 47 milliseconds to 63, driving from intent_field_navigated_type rather than from graphql_field, which is the shape that measured best of the three tried; joining that relation while still driving from the field list measured 228. Read the sibling essay on graphitron_field_scope_table beside this, because the two look contradictory and are not: it was retired at the field grain once the far side of that join became a table, and there is nothing to re-evaluate per driving row when the far side is stored. intent_poly_member is a view, so the projection pays here, and the condition is what generalises rather than either verdict. Not stored, and the reason is reader count rather than cost: one relation names this one, and one names that, so a stage writing it would pay one write per capture to save one evaluation. The arm does raise graphitron_field_scope_table from 16 milliseconds to 59, which is the honest price of a question the store could not answer at all before, paid once per capture of the argument scope it feeds. When the condition membership fold arrives as a second reader that trade changes and is worth re-measuring then. The population is stated structurally and not narrowed to where an emitter exists, on intent_node_id_encode’s terms: a child field whose named type is a multi-table container has the same fact as a root field with that type, whether or not the generator carries a per-participant filter surface there, and narrowing the rows to today’s emitter would make this relation track emitter maturity instead of the schema.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Which coordinate produces a value and what type it returns: one row per field carrying a producing directive, with the directive’s family and the unwrapped SDL type the field’s value arrives as. The grain is the coordinate, which is what separates this from graphitron_carrier_data_field’s producer reading: that view asks which payload types a mutation root returns and folds the coordinates away, so a payload two fields return is one row there and two here. Both readings are wanted and only this one can key a fact to the field an author is looking at, so the fold is the reader’s and this relation does not perform it. A @routine field is DISTINCT because a chain applies the directive once per hop and the coordinate produces one value however many hops reached it, the hops being intent_field_chain_node’s rows. Where the coordinate sits is a column rather than a filter, for the same reason the family is: a root write and a child @service field are the same fact under different readings, and the two policies that turn on the position (the carrier scan wants root mutations, the error channel’s transport wants root @service) each name what they mean. One column carries it and not two, the operation being the discriminator and its absence the predicate, so a reader asking only whether the field sits at a root writes that as a null test rather than reading a boolean that would have to agree with it. A type serving as two root operations at once reports the alphabetically first, which keeps the grain at the coordinate; nothing in the schema forbids the shape and nothing in the generator has met it. @externalField is deliberately absent: it names a class member that answers an already-produced value rather than a directive that produces one, and intent_field_producer_reference is where the two meet as method references. Absence here means the field carries none of the three directives, not that it has no value.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The method a field’s authored Java reference names: intent_field_producer_reference resolved against code_method, one row per method the reference matches. A use-keyed resolution over a source-keyed reading, which is the shape an authored coordinate reaching into the classpath always takes here, and it states the resolution alone: what the method’s return delivers is code_type_element’s answer, reached through code_method.result_type. Which directive named the method, how the two arms coalesce and where the @externalField omitted-method fallback is applied are all the reference relation’s, stated in its comment; this relation adds the name match and nothing else, so a reader wanting the authored names without the match reads the reference and is not made to care whether the class was scanned. Ambiguity is rows and never a decline, as on intent_bound_table: a reference matching two overloads is two rows and candidates says so. That is the one place this relation departs from the walk it replaces, which takes whichever matching method the reflection API hands back first, in an order the JVM does not specify, so the walk’s answer for an overloaded name is unstable rather than merely arbitrary. The intended reading is that a reference matching more than one method is a rejection, and what a rejection needs is the arity, which is why this relation states it rather than picking. Absence has two causes and one join separates them: no code_class row under the graph’s sources means the reading never reached the class (its filters, an entry nothing read, the generated jOOQ package), while a class row with no method row means the class declares no method of that name. Nothing here judges the reference beyond matching it. A row here does not assert the method satisfies the directive that named it, because a name match is all this relation performs: whether a method is admissible at @externalField is code_external_field_method’s answer and whether it is static is a column of code_method, and a reader wanting either asks there rather than inferring it from a match. A nested class an author spells Outer.Inner matches nothing, the reading writing the $ the JVM writes and skipping nested classes anyway.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The Java method a field’s authored directive names, before anything checks whether it exists: @service and @externalField coalesced, one row per application. Named apart from its resolution because the two answer different questions and one of them survives an unreachable class. A surface that must name the declaration a field binds to needs the reference, which the author wrote and which is a fact whether or not the classpath census reached the class; a surface that needs the method’s arity or wants to know the reference is ambiguous needs intent_field_producer_method, which is this relation resolved against code_method and therefore empty exactly where the census fell short. Splitting them also gives the @externalField omitted-method fallback one home: graphitron_external_field_entry’s own comment defers that default to a derivation, and this is it, so no reader repeats the coalesce. Two arms coalesced by a view rather than one relation over a merged base, because which directive named the method is not recoverable from the pair of names and the two say different things about how the method is reached; declared_via carries it, on the terms any discriminator is carried on: two rows that would otherwise be identical say different things, and which of them a reader wants is not recoverable from the rest of the row. Nothing here judges the reference: a coordinate carrying both directives is two rows, neither winning, and the conflict is intent_authored_claim_conflict’s to report.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The foreign key an omitted @reference path discovers: for a field whose parent type and named type are each bound to a table, every foreign key connecting those two tables in either direction. This is the resolution the walk runs where a field carries no path element, and sql_referential_constraint’s own comment defers it here, "exactly one foreign key between these two tables" being a derivation over that relation rather than a captured fact. Separate from graphitron_field_reference_step_hop because that view resolves what an author wrote and this one answers where nothing was written; the hop view names this as a resolution it deliberately does not perform, so its silence is not the absence of a discovery. Neither endpoint is re-derived here. The arriving table is graphitron_field_column_scope’s named-type rule, which reads the navigation so a synthesised connection field navigates as its element type, demands an OBJECT named type and an unambiguous binding, and excludes the coordinates an authored claim, a @pivot or an authored path diverts; restating any of that would be a second spelling of the navigation that view exists to state once. That rule’s own comment carries what it does not answer for, an author-declared connection, and why it alone among its siblings still spells the navigation rather than reading intent_field_navigated_type. The departing table is the parent’s own binding, demanded unambiguous for the reason the arriving one is: a discovery between endpoints that are not certain is not the pair the walk would have had in hand. One row per connecting key and not two, a foreign key connecting a pair once whichever end declares it, and fk_on_from says which end that is; a self-referential key therefore needs no special case, the same-table pair being excluded outright. Excluded because the walk excludes it, comparing the two table names case-insensitively and nothing else, so two like-named tables in different schemas are one table to this rule as they are to the walk. Both names are catalog values reached through derived views, and a derived view does not forward a fold, so the comparison joins sql_table on its key at each end and reads the fold there; that costs two lookups on a primary key and keeps the fold a property of the relation that owns the spelling. The self-referencing field states its key explicitly or is rejected with that advice. Absence covers several things and none of them is "the discovery found nothing in particular": no foreign key connects the endpoints, or an endpoint is unbound or ambiguously bound, or the coordinate is one the named-type rule excludes. The walk’s other element-less arm needs no exclusion here: where the departing table is a table-valued function the walk name-matches instead of discovering, and a routine result declares no foreign keys, so such a coordinate contributes no rows on its own. The departing endpoint reads graphitron_resolved_type_binding, as the arriving one already does through the navigation view, so a parent bound by a @routine chain’s return rather than by a written @table is the same endpoint here; where that chain landed on a function result the sentence above is why the pair still finds nothing, and where it landed on a stored table through a hop the discovery is the ordinary one.

Where a field-site @reference path passes through an intermediate table, and whether that table can hold more than one row per pair of columns the entering and leaving hops bind: one row per intermediate, in a closed verdict vocabulary of four. For example film to film_actor to actor draws one row at position 0 reading COVERED, film_actor_pkey being exactly the pair the two hops bind, while a junction carrying a key column neither hop binds reads FANS_OUT there instead.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The generated call surface a @routine application names: graphitron_routine_entry resolved through graphitron_spelled_table and onto sql_routine, one row per call surface the application matches. The sibling of intent_field_producer_method, and the same shape for the same reason: an authored coordinate reaching into a census is a use-keyed resolution over a source-keyed relation, and it states the resolution alone. How a written name meets the catalog is the spelling view’s rule, stated once there; that a @routine(name:) resolves under it is that view’s own claim, jOOQ modelling a function result as a catalog table. Keyed on the application rather than the field, because @routine is repeatable and the ordinal is what tells two applications on one field apart, in the written order the table chain interleaves them in. No table_type filter: a spelling naming a stored table resolves on the spelling view and then matches no row here, so the join says "not a callable" without restating what sql_table.table_type means. Absence has three causes and the joins separate them: no spelled-table row means the name matched no catalog object at all, a spelled-table row with no routine row means the object it matched is not callable, and a routine whose generated model exposes no call surface is excluded here, because this relation is the call surface and naming a class that does not exist would be a worse answer than naming nothing. Ambiguity is rows and never a decline, as on intent_bound_table.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Which fields are fetched by a statement of their own rather than projected out of the enclosing SELECT, one rule literal per arm. The question a schema author asks about round-trips: a field with no row here that resolves against its parent’s table costs nothing beyond the parent’s own statement, while a field with one is a second trip to the database. The two marker arms are the delivery-forcing union the table-backed child arm reads (@splitQuery defers the fetch through a DataLoader; @tenantFanOut forces the same boundary because a fanned child runs once per tenant and cannot join into a parent statement running on one source), stated as separate rules rather than one DELIVERY_MARKER because which marker forced the split is what an author reads and the two are written for different reasons. The service arm is the non-root @service contract: the service fetches independently of the parent’s SELECT, which is why the split is required rather than optional there. The root arm is every field of a bound root operation type, whose fetch is the operation’s own entry point and never a projection of anything; keyed by the root operation binding rather than the conventional names, so it states the intended rule the way the demand rules do, today’s walk dispatching on the literal names being the same known difference recorded there. The record-handed-parent arm is the implicit split, the one no author writes: a field of a type the backing closure grounds on a class, naming a type of its own that is bound to a table. There is no enclosing statement for such a field to be projected out of, the parent’s value being a Java object a producer handed back rather than a row of a running select, so the child’s table is a trip of its own. It reads intent_type_backing_class rather than the coalesced intent_type_backing, and anti-joins the parent’s own @table binding away, because a type both populations answer is one the walk reads as a table row and never as a handed object; that precedence is the one intent_type_backing’s comment records, so transcribing it is the same reading rather than a new opinion. The anti-join is over intent_bound_table and not over the coalesced view’s table arm, because what makes a parent a table row is its binding, whether or not jOOQ generated a record class for the table the binding names. Both joins over that binding stay on the @table population rather than moving to graphitron_resolved_type_binding as the navigation relations did, and that is a deliberate hold rather than an oversight: a type standing for a @routine chain’s result is handed to its children by the routine’s own statement, so whether such a parent is a table row or a handed row is the same precedence question this arm exists to state, and answering it by substituting the relation would decide it in passing. The two joins move together when it is settled. The parent’s kind is guarded and the child’s is not: the closure holds input objects beside objects and an input coordinate is not a fetch, while on the child side @table on an input object is unreachable from an object’s field to begin with. The literal is the walk’s own trigger name, so one population keeps one word wherever it is stated; record there means a producer-handed domain object, which this schema calls a class backing. Two readings depart from today’s walk and both are the intended rule. An ambiguously bound child splits here where the walk mints no table-backed verdict for it at all, since an ambiguous binding is contested rather than projected, and the split is what an editor can say about a schema mid-edit; a reader wanting the walk’s reading filters on intent_bound_table.candidates the way every other reader of that arity does. A @table interface child splits at either cardinality where the walk inlines the single-valued one, its discriminated-interface arm running before its record-handed one. Two populations stay absent, which is why absence is still not the complement’s claim: a child reached through a connection wrapper, no relation naming a connection’s element type, and the polymorphic fan-in, where a list-valued interface or union child with a table-bound participant batches through a DataLoader. A reader may say a field with a row is separately fetched, and may not say a field without one is inlined.

Where an ordering is available at a coordinate and the coordinate’s own read shape cannot honour it: one row per coordinate and availability route, in a closed verdict vocabulary of two. For example a child field returning a three-implementation multitable interface and carrying both @defaultOrder and an @orderBy argument draws two rows under PARTICIPANT_FAN_OUT, one per route, while the same field with no declaration at all draws none.

The rejection each minting row of intent_field_unlowerable_ordering carries: one row per rejected coordinate and availability route, holding the sealed Rejection hierarchy’s verdict on it and the message a report would print. For example the multitable root carrying @defaultOrder draws a DEFERRED row whose message names the interface, its participants and both remedies, while a list-returning @routine write draws none, its rejection being held.

Primary key: (graph_name, ordinal). Foreign key: (graph_name) references store_graph (graph_name). Check: "KIND" = 'DEFERRED'.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. What a foreign key equates: one row per position, the key’s own column beside the column it references. The join condition every reader that renders or reasons about a foreign key needs, and a derivation rather than a capture because the census records the two constraints' column lists separately and the pairing between them is positional. Positional is the whole content of this relation and it is SQL’s own rule rather than a convention adopted here: a foreign key’s Nth column references the Nth column of the constraint it points at, which is why sql_constraint_column carries a position at all and why nothing else has to be matched on a name. Both sides are joined on their own constraint’s full key, so a constraint name two schemas or two classpath entries both declare pairs within its own table and never across, which is the collision the endpoint triples exist to prevent. A key whose referenced constraint has fewer columns than it declares pairs only the positions both sides hold, and that is a malformed catalog rather than a shape to model: the census would have to have recorded a key SQL could not have created. No arity is exposed beside the pairs, the position being dense from zero on both sides, so a reader wanting the width counts rows. Nothing here is specific to any one consumer’s question, which is why it sits with the catalog derivations and not beside the relation that first needed it: the @nodeId lift is its first reader and a rendered join is its obvious second.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Which table the column name written at an input field resolves against: the input-field twin of graphitron_argument_column_scope and graphitron_field_column_scope, and a third relation for the reason the third walk is a third walk. The departure differs and here it is not even a function of the coordinate, so the resolving table is part of the key and the same input field carries one row per table it is classified against. Two rules, disjoint rather than ranked, so this is a plain union with no windowed collapse over it and it carries the one-row-per-site property both twins stand on. An authored @reference path resolves to its terminal element’s table, demanding the terminal reach exactly one table rather than exactly one row, so an element joining two tables by three keys still names its destination; the DISTINCT over a projection keeping only the table is what collapses several routes to one destination. An input field with no path element resolves in the table it was handed, read from graphitron_input_field_resolving_table rather than restated, so the two spellings of that departure cannot drift. Repetition is a conflict and not a chain, as at the argument site and unlike at the output-field site: ordered composition has no meaning on an input field, the resolver rejects a second application outright, and a site carrying two has no row here under either rule. That second demand is on the applications and not on their elements, so an author writing an empty @reference(path: []) beside a real one has no row here, and an author writing one empty application alone has the resolving-table row, which is the bare predicate a directive-less field would have produced and is what the resolver gives that site. Nothing here reads the classifier’s ordered fork. A @notGenerated or @lookupKey application, a @nodeId decode, a nested input object and a plain name all have a scope, and which of them the classifier actually resolves the site as is a role question one rung up; this relation answers where a name would resolve if one is written, which is graphitron_argument_column_scope’s stance at its own site. Its consumer is graphitron_input_field_column_match, which asks which column the name reaches.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The order the flattener reaches a payload’s occurrences in, one row per occurrence path: a dense zero-based rank within the argument the path descends from. The walk is a depth-first pre-order over declared input fields, so the argument occurrence itself is always rank zero, a grouping input is reached before any field it groups, and a grouping input’s whole subtree lies between it and its next sibling. Two questions already asked that order pairwise, each in its own view body, and both are the same question: which of several contending straddler claims pins a key column, which graphitron_mutation_write_destination settles, and which occurrence a runtime agreement check names on its predicate side, which intent_mutation_write_agreement settles. A third is the order an emitter renders one statement’s assignments and predicates in, and it is what fixes the grain: all three are questions about an occurrence’s place in one descent, so the order is stated once at the grain of the occurrence rather than three times inside the relations that consume it. The rank is computed pairwise rather than from a sort key assembled out of the path, a key of that shape being a collection folded into one value and this schema keeping no such column: for each pair of occurrences under one argument, the earlier is the one that is a prefix of the other, or, where neither is, the one whose field is declared first at the outermost step the two differ at. That comparison tests field names only and does not compare containers, and does not need to: two paths agreeing on every field name before their first difference agree on every container too, each step’s container being the previous step’s named type and the first being the argument’s own input type, so the containers follow by induction rather than by a predicate. The order is total within an argument, which is what makes the rank dense: two distinct paths under one argument either stand in the prefix relation or take different fields at some step, and different fields on one container have different declaration ordinals. Between arguments it says nothing. Two paths under different arguments both have a rank and the two ranks are not comparable, which is why the argument is not repeated here: a reader needing it joins intent_input_occurrence_path, whose key this relation shares and whose row carries the argument coordinate. Absence is an occurrence path relation with no rows, so a graph declaring no input object surface at all; every path that exists has a rank, the payload root included.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The cascade fact as a predicate over path prefixes: one row per occurrence path with an enclosing @condition(override: true), which in the classification walk is the enclosingOverride boolean threaded through the recursion. A path’s enclosing sites are the use-site field’s own @condition, the argument’s @condition, and the @condition of every step strictly above the leaf (the leaf’s own override is the condition-owned carrier’s fact, not a cascade fact). Absence is the no-override reading, which is what the use-keyed cascade verdict fires on when the leaf is unbound. The witness columns name the nearest enclosing overriding site (deepest step first, then the argument, then the field), the row the admitted-because message and the future fix-it need; a NULL argument name means the witness is a field-site condition row, the witness’s own key shape across the two condition relations.

One occurrence of the input surface under a use site: an argument whose named type is an input object, or a nested input field reached from one by descending through input-object-typed fields. For example Mutation.updateFilm(in: FilmUpdateInput!) draws one row for the in argument at depth 0 and one for each of its fields, filmId and title, at depth 1.

Primary key: (graph_name, path). Foreign key: (graph_name) references store_graph (graph_name). Foreign key: (graph_name, root_type_name, root_field_name, root_argument_name) references graphql_argument_element (graph_name, type_name, field_name, argument_name).

The ordinal-keyed decomposition of an occurrence path: one row per input-field step, 1-based, so no consumer parses the serialized key. For example the path reaching title under Mutation.updateFilm(in:) draws one row at ordinal 1 naming FilmUpdateInput.title.

Primary key: (graph_name, path, ordinal). Foreign key: (graph_name, path) references intent_input_occurrence_path (graph_name, path). Foreign key: (graph_name, container_type_name, field_name) references graphql_field_element (graph_name, type_name, field_name).

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Whether a write payload identifies the row it acts on, and through which key. One row per write surface whose payload the walkers admit entirely, which is the population both walkers reach this question at: they collect every per-field refusal first and return before matching a key, on the grounds that an unadmitted field makes the covered set unreliable and a spurious coverage error on top of a real field error helps nobody. So a mutation with any refusal has no row here at all, and that absence is the refusal relation’s to explain rather than a verdict of its own. The match itself is verb-neutral and is the one thing the two walkers genuinely share: which catalog key does this input cover. The candidates and their order are intent_table_key_candidate’s, primary key first and then the unique keys in declaration order with duplicates on the column set already collapsed, so the primary key being the tiebreaker is that relation’s ranking read in ascending order rather than a preference invented here. Covered means every column of the key is one this payload contributes, which is a subset test and not an equality: an input naming more columns than a key needs still covers it, and the surplus is the other consumer’s business. The subset test is counted rather than correlated, the key’s columns outer-joined to the payload’s and the two counts compared, so the contributed columns are read once for the whole matrix instead of once per key column per candidate per surface. That shape also keeps the degenerate reading honest: a candidate with no columns at all compares zero against zero and is covered, which is what a subset test over an empty set does and what the matcher this transcribes would answer. No catalog jOOQ generates produces such a key, so it is a property of the rule rather than a population. What is not verb-neutral is the covered set, and that is the whole reason the verb is on the row. A DELETE counts every admitted column, every one of them being a WHERE predicate. An UPDATE counts only the columns of carriers that pin identity, which is every carrier except a self-referencing foreign key: a self-FK’s columns point at a sibling row, so a key column reachable only through one is not this row’s identity and an UPDATE that treated it as such would key on the wrong row. Stated as a predicate over the carrier role rather than as two relations, because the question and the ranking are identical and only the input to the subset test moves. A closed vocabulary of three. IDENTIFIED names the winning key and carries its rank and whether it is the primary, which is what a consumer emitting the WHERE clause and a diagnostic naming the key both need. BROADCAST is the DELETE that covered nothing and opted in: multiRow: true is the author saying the statement may match many rows, and it is an arm rather than a modifier because the emitted statement has no key predicate at all. UNCOVERED is everything else, and it is a rejection’s population: an UPDATE has no broadcast reading, multiRow: true on one being refused before a write surface exists at all, so an UPDATE whose input pins no key is an author error with the covered columns and the candidate keys as its evidence, both one join from this row. The three key columns are null together and exactly on the two verdicts that name no key, which is the vocabulary determining them rather than an unfilled slot. What this relation does not say is what happens to the columns the key did not take. On a DELETE nothing does, every admitted column being a predicate and the key being a cardinality guard beside them rather than a subset of them. On an UPDATE the key is a partition, and where each remaining column lands, whether a carrier straddles the key, and whether anything is left to set at all are the write destination’s answers over the same substrate this one reduces.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Which seat a mutation root’s @routine occupies, and where it occupies none, which precondition stopped it. A @routine on a mutation root is a write, and there are exactly two shapes the write can take: the chain seat, where @reference elements after the routine say where the committed row is re-read from, and the carrier seat, where the field returns a payload whose one data field re-reads it by the routine result’s name-matched keys. Which of the two the author wrote for is the seat, and whether that seat holds is the verdict, and they are separate columns because a refused coordinate still has a seat and a diagnostic about it has to name the shape the author was aiming at. Population: every mutation-root field carrying @routine, at the application that defines the chain. Total over that population and exactly one row per coordinate, which is the property the whole relation is for: there is no default arm and no coordinate with no row, so a shape this vocabulary cannot name is a build failure here rather than a silent non-member somewhere downstream. A reduction over sibling relations rather than a rule of its own: every fact it turns on is already a relation, intent_field_chain_terminus and intent_field_chain_node for where the chain goes, graphitron_carrier_data_field and intent_carrier_routine_hop for what the payload is and where its re-read departs from, intent_bound_table for what the author wrote @table for, and the captured directive rows for what was written. What this relation adds is the seat fork and the precedence, and nothing else; a verdict that needed a fact no relation states would be a rule wearing a reduction’s name, and the two the walk distinguishes that no relation states are disclosed below rather than fabricated here. One pass with the verdict picked by a CASE rather than one UNION ALL arm per verdict, which is intent_node_id_decode_defect’s rule for the same reason and additionally for this one: exactly-one-verdict-per-coordinate is what a reader trusts, and one driving row gives it by construction where a union would have to rank arms to get it back. The nesting is the seat fork, so the two seats' arms cannot reach each other. Precedence is this relation’s own and not a transcription of any evaluation order: a coordinate with two defects gets the more fundamental one, the count of routine nodes before the chain’s head, the head before the surface written on it, the surface before anything about the return, and the return’s shape before where the chain lands. There is no message column, on intent_node_id_decode_defect’s settled terms: the closed vocabulary plus the coordinate and the return type are the fact base, and the prose that renders a verdict as a sentence an author can act on belongs with the consumer that composes it. Nor a severity column, which would be a function of the verdict and nothing else; which verdicts are the author’s to fix and which are shapes the generator owes an emitter is stated per value below. The terminus rule reads intent_bound_table and not graphitron_resolved_type_binding, and the choice is load-bearing rather than inherited: the reduction’s other arm is intent_routine_return_binding, which binds a chain field’s return type to that same chain’s terminus, so comparing the terminus against the reduction would be comparing a value with itself. What the rule is actually about is whether the table the author wrote @table for is where the chain lands, which is the @table population’s question alone; this is graphitron_node’s reason for standing on that arm too. A return type carrying no @table therefore draws no disagreement, the derived binding governing there, which is the shipped behaviour and not an omission. One silence is disclosed rather than closed, and one that was is now shut. A first hop that joins by an authored condition alone resolves through graphitron_condition_method_route, so the chain reaches its first node and this relation reads the shape as UNANCHORED_FIRST_HOP, which is the verdict this relation’s own precedence already assigns that shape: a chain node at seq 1 whose captured step names a condition class. It read as CHAIN_UNRESOLVED for as long as such a hop resolved to no hop row at all, which conflated a refusal with a shape the classification walk calls owed an emitter. The one that stays disclosed: a payload whose data field is the ID scalar draws no graphitron_carrier_data_field row at all, that relation refusing an ID element for the ROUTINE family outright, so it reads as NO_CARRIER and CARRIER_ELEMENT_NOT_TABLE names the record element alone.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Which two of an UPDATE’s contributions must be checked equal before any DML runs, one row per pair per column. A foreign key forces the two values equal for well-formed input and nothing forces the input to be well formed: both values arrive on the wire independently, so a disagreement is a runtime error and can only be a runtime error, which is why this states an obligation to emit a check rather than a refusal to generate. It is a reduction over graphitron_mutation_write_destination rather than a fact beside it, and the whole of the rule is a self-join and a tie-break: every pair is a PREDICATE row of that relation and a non-PREDICATE row of it over the same column of the same statement. Two carriers reach the non-PREDICATE side and the destination already tells them apart. A self-referencing foreign key routes every column it carries to the assignment half, so a key column among them is written and checked, and its row here carries VALUE. A straddling cross-table reference whose in-key column something else already pins neither filters nor writes it, so its row here carries CHECKED, which is that destination’s whole reason to exist. The predicate side is one occurrence per column even where several are dispositioned PREDICATE, because the statement filters on a column once: where two whole carriers bind one key column, which of them the check names is the flattener’s descent order, read off intent_input_occurrence_descent_order, which is the same rank graphitron_mutation_write_destination settles a contested straddler claim with, and asked here rather than left to whatever order a row arrives in for the same reason it is asked there. A field paired with itself is excluded in the join rather than filtered after it: the check this lowers to names two input fields, and a field cannot disagree with itself, so an occurrence and a same-named occurrence elsewhere in the payload produce no obligation. Absence is every payload with no reference carrier landing on a key column, which is most of them, and every payload the write partition refuses, a refused payload having no destination rows to reduce over. Source positions are not carried: a row here names two occurrences, both of which graphitron_mutation_write_destination already carries a position for at a key this relation states in full, and carrying one of the two would invite it to be read as the obligation’s position, which no author error attaches to. Nor is the order the checks are emitted in carried as a column. That order is the reference occurrence’s place in the flattener’s descent and then its decode slot, which is the order the assignment and predicate halves are themselves emitted in, so it is one question at the grain of an occurrence rather than three at the grain of each partition; the descent half of it is intent_input_occurrence_descent_order, which an emitter joins on the reference path, and the decode slot is reference_position here.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Why an UPDATE the walker admitted field by field is refused anyway, once the matched key has partitioned its columns. The third of three refusal relations over one statement and the last in the order the build reaches them: whether each field is admissible at all is graphitron_mutation_payload_refusal’s and is collected before any key is matched, whether the admitted remainder pins a row is the matched key’s UNCOVERED verdict, and what is left is what only the partition can see. A consumer assembling an UPDATE reads all three and stops at the first that answers, in that order. The domain is UPDATE alone, and that is the whole reason these causes exist. A DELETE has no assignment half: every admitted column of one is a predicate, so there is no boundary for a carrier to straddle into, no assignment for two writers to collide over, and nothing that must be non-empty. Four causes in three stages, and the stage is what makes the ranking load-bearing rather than cosmetic. The walker collects a stage’s refusals without short-circuiting and returns at the end of it, so a cause from a later stage on the same coordinate is not merely unreported: it would have been computed over a partition an earlier refusal made the walker abandon. This relation therefore keeps, per coordinate, only the causes of the first stage that has any. The first stage carries the two straddles and reports them together, an author fixing one of them meeting the other. MIXED_CARRIER_KEY_MEMBERSHIP is a carrier of the row’s own columns with a column on each side of the key: half of it is the identity the statement finds the row by and half is a value it writes, which is moving the row rather than updating it. NULLABLE_STRADDLING_REFERENCE is a cross-table reference in the same position, where the split itself is legitimate and so is the spelling, except where the reference is the sole supplier of one of the key’s columns. The in-key half of a straddling reference is the row’s own identity, and an optional field cannot be load-bearing identity: omitted, it leaves the row unidentifiable, and no per-row conditional recovers a predicate that was never sent. Where something else supplies that column the same nullable reference is admitted, and an explicit null on it clears its out-of-key half; a half-null foreign key imposes no referential obligation under MATCH SIMPLE, so the cleared reference is an absent one rather than a dangling one, which is the premise this cause used to be argued from backwards. What counts as supplying it is the identity_pinned window beside the predicate: a whole carrier other than a self-referencing one, or a non-null cross-table straddler lifting the column in its in-key half. The second arm is the one that is easy to drop, and it is what makes this relation agree with the walker: a non-null straddler’s winning claim IS the column’s predicate and a non-null field cannot be absent, so it pins exactly as a whole carrier does. That window is this view’s own and is deliberately wider than the destination’s pinned window beside it, which stays whole-carrier-only: broadening that one would empty its claim step for any column two non-null straddlers lift and silently drop the column’s predicate. The predicate is silent about carrier_key_membership, which is sound but by a subtlety worth writing down rather than tidying away. It also matches a nullable cross-table reference whose columns fall wholly inside the key, and that shape escapes only because the window counts the carrier’s own WHOLE rows and so self-pins. A straddler is never WHOLE and so never self-pins, which is what makes the same window read as some other carrier for the rows this cause is about; the wholly-in-key nullable reference is a neighbouring hazard deliberately left to its own measurement, and a later reader fixing the self-inclusion would refuse schemas that build today. A self-referencing foreign key appears under neither cause, routing wholly to the assignment half before the boundary is consulted. The second stage carries PLAIN_COLUMN_COLLISION, two plain carriers assigning one column, which would silently last-write-win; an overlap one of whose writers decodes its value is admitted instead and reconciled at runtime by the agreement check, which is why the cause is about plain writers rather than about writers. The third carries NO_SET_FIELDS, an UPDATE every column of which is the key it filters on, which is structurally ill-formed rather than a no-op. Where a row is located varies by cause and so do two of its columns, which is the shape of the underlying errors rather than an unfilled slot. A straddle is a fact about one occurrence and names it with no column. A collision is a fact about one column and names every occurrence writing it; the walker’s own diagnostic quotes two of them, which is an artefact of the order it built the assignment half in rather than a fact about the payload, so this relation names the contributors and leaves the choice to whoever renders one. An empty assignment is a fact about the statement and names neither, and its position is the @mutation application’s rather than any field’s. Absence is an UPDATE whose partition the walker accepts, every DELETE, and every coordinate one of the two earlier refusals already answers for.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. What a polymorphic container holds, read as the node-id family asks it: one row per member of every container, carrying whether that member binds a table and whether it is a node type. Keyed on the container, because which node types are members of an interface is a fact about the interface and not about any slot that names it; keying it on a use site would store one copy of the answer per consuming coordinate. Total rather than filtered to the admissible members, and that is the whole of why it is a relation rather than a predicate inside its readers: three readers want three populations off it. The resolution axis above it, intent_node_id_candidate_node_type, wants the members that are both; intent_node_id_polymorphic_decode_defect’s MEMBER_NOT_NODE_TYPE wants the table-bound members that are not node types and so could not read a filtered relation at all; and the editor’s node-type keyset wants the containers with at least one of each. The two predicates are columns rather than a name that bakes one caller’s filter in, on intent_bound_table.candidates' own terms: whether either holds decides the reading, so it is stated as a column rather than left to each reader’s own existence test. This is the graphitron_spelled_table / intent_bound_table layering at the container grain, over intent_poly_member rather than over the captured relation beneath it, which is where a derivation over membership stands. The read side’s per-participant candidate derivation can re-source onto this relation the day someone wants the two to agree by construction rather than by both being right.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The node types an id arriving at a @nodeId instruction may belong to: one identity row for a resolved type that is a node type, one row per admissible member for one that is a polymorphic container. The resolution axis of the node-id family, keyed on the resolved type rather than on a use site, so a container’s member set is stored once however many coordinates name it. What it buys is that the polymorphic destination is a branch inside the decode relation’s existing slot arm rather than a second arm over the same driving relation: that arm joins this on the slot’s resolved type and the key shape on the node type this yields, so a node-typed instruction yields the one row it always yielded and a container yields one row per member with that member’s own key. Two readers ask it on day one, that destination and the sibling polymorphic defect view, which is the threshold this schema sets for a derivation to get a name of its own. The two arms are disjoint by construction and not by precedence, which is what lets this be a plain union: the identity arm is every node type, and the member arm excludes a container that is itself one, the same predicate graphitron_node_id_instruction_rule’s container arm carries. The identity arm is total over the node population rather than restricted to types some instruction names, because keying on the resolved type means the relation answers a question about a type and a population trimmed to today’s readers would be a filter one of them made for itself.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. How one decoding @nodeId instruction is carried out: one row per instruction, use site, branch and, where the instruction named a polymorphic container, member, naming the destination that receives the decoded tuple. The branch is the table the decode departs from, and it is part of the key rather than a column carried along: a slot whose consuming field returns a multi-table polymorphic container is rooted in one table per branch, the endpoint relation states one pair per branch, and each branch is a predicate the generator emits, so each gets its own destination and its own arity here. On the slot arm the three origin columns are NULL, determined by destination in the sense the nullable-by-kind discipline allows: a slot is reached at the root of the use site and departs no table at all. An instruction with no row here was not carried out, and absence is therefore never a message but the membership condition a defect view is keyed on, which is what keeps a resolution and a rejection from restating one fact. Presence is not an emitter, on intent_node_id_encode’s wording for its own half and for the same reason: a row says where the decoded tuple would land, and whether the generator carries the decode out at that coordinate is the schema walk’s fact rather than this relation’s. A cross-table filter naming a node type no foreign key connects the field’s table to draws a TARGET_TABLE_COLUMNS row here and is refused outright by the walk, which is the measurement that settles the reading. So a rule about whether a decode was installed reads what the run installed and not this relation; the build-path rule that does, over the instruction census and the classification run’s own dispositions, is deliberately no reader of this one. The reduction this relation performs is the whole of the junction-table case. A decode whose every key position lifted to a column of the row’s own table binds locally on a tuple of that table; one where any position did not binds the node type’s own key columns on the node type’s own table inside a correlated EXISTS; and a chain through a junction table is the second because its lift contributes no local column, not because anything rejects it. Those were one conjunct in the resolution this replaces, which picked the local shape when the terminal key’s referenced columns were the node key as a multiset, so the remote shape was unreachable for a multi-hop path and a chain that translated a column met a rejection before the question was asked. Here they are a count against a count. Anything short of every position is remote, which is always correct where a tuple predicate is not, and which position failed to arrive is the key-column child’s answer rather than this relation’s. All five destinations, in two arms over populations that are disjoint by construction rather than by a filter either arm applies twice. The fifth is a branch inside the slot arm and not a third arm: that arm joins intent_node_id_candidate_node_type on the slot’s resolved type and the key shape on the node type it yields, so a node-typed instruction yields the one row it always yielded and a container yields one row per member with that member’s own arity, and the destination CASE forks on resolved_type_kind rather than on a re-derived predicate. WHERE s.candidates = 1 survives verbatim, the multiplicity having moved off the slot relation’s partition and onto the resolution axis. A third arm would drive off intent_node_id_decode_slot a second time and re-join the key shape, which is what the derivation-depth rule forbids in the relation this comment calls the deepest derived read in the schema. The polymorphic branch is admitted by a NOT EXISTS over the members rather than by a per-member predicate, because one member whose record the slot’s type is not refuses the whole slot; and it is therefore silent at an input-field site, where the slot relation types the bean rather than the annotated member and no member’s record is that type. That silence is the polymorphic defect view’s stated edge and not a hole here. A decode landing in a Java slot is the slot arm’s, on intent_node_id_decode_slot’s answer, and the table arm excludes exactly that population, because a slot receives the value and the departing table then binds nothing. The arms are not a per-destination decomposition of one query, which the derivation-depth rule forbids: they read different driving relations for different facts, the table arm reducing the key-column child’s lift and the slot arm reading a parameter and the node key’s shape, and neither re-joins the other’s operands. Within the slot arm the record destination is tested first and wins, which is a precedence and is stated as one: a record holds a tuple whatever the key’s arity, so a single-column key reaching the node type’s own record is that record’s row and not a bare column value. The record has to be the node type’s own table’s record, and a slot typed as some other table’s generated record is deliberately no row here rather than falling through to the single-column destination: a record standing for the enclosing input type receives the tuple on its own table’s columns rather than on the argument’s scope table, so its lift departs somewhere this relation’s endpoints do not resolve, and reading it as a single-column slot would bind one value into a row type. The single-column destination requires arity one and then stands aside on either type being unknown, on intent_resolved_node_key_projection’s discipline for the same operands: a parameter no census could type and a key column no catalog could type both resolve here and are carried out on arity alone, with javac as the backstop, because refusing on an operand nobody could read is the silence this family exists to close. A slot whose type is known and disagrees is no row, and so is a composite key at a slot that is not a record; both are the defect view’s to name. An overloaded producer is also no row, this arm requiring one candidate rather than picking a type, which the slot relation’s own comment asks of a reader that needs the type; that leaves such an instruction in neither population, which is a gap in the partition and named as one rather than absorbed here. Population boundary, stated because a hole here reads as a fact everywhere downstream, and the two arms have different ones. The table arm’s rows come from the endpoint population, so an instruction whose departing or arriving table did not resolve unambiguously has no row and is a defect rather than a decode. The slot arm needs no departing table at all, a slot being reached at the root of the use site, and needs the node type’s key to have resolved, which is the one binding it does read. The node type’s key arity is carried rather than counted by each reader, both because a message about a single-valued slot names the count and because it is the operand the single-column destination turns on. Expensive, and the cost is invisible at the call site, which is why it is stated here: this is the deepest derived read in the schema, it reaches most of the tables the @nodeId and input-field stages write, and one read of it against a real capture has been measured in seconds rather than milliseconds. A reader that wants it takes it once and pairs it on its key, never correlated per row, per the rule under "Derived reads are views, not stored facts". It is not stored because nothing on the build path reads it yet; the sibling that is read there is intent_node_id_decode_defect, over intent_node_id_decode_slot rather than over this relation.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. What is wrong with a decoding @nodeId instruction whose value reaches a Java parameter and which the decode declined to route there: one row per refused instruction and use site, in a closed verdict vocabulary of two, over the slot relation and the node key’s shape alone. The rejections that close the last silence this directive had, where an author annotated an argument @nodeId, the walk’s type gate stood aside because a decoded value and the ID’s coercion output never meet, and the wire string then reached the consumer’s parameter with nothing in the build saying a word. Written in one pass with the verdict picked by a CASE rather than one UNION ALL arm per verdict, for the reason the fact model states about inline multiplicity: the two verdicts read the same two driving relations for the same two facts, so an arm each would name both a second time to say something one predicate already decides. Population, and it is the whole design rather than a scoping convenience: these are the slot rows the pair-grain argMapping family cannot see, and intent_node_id_decode_slot.carrier already names them. A MAPPED_PARAMETER slot at an argument site is an argMapping pair whose bound leaf is that @nodeId argument itself, so intent_argmapping_projection_defect judges both of these facts there already, BARE_NODE_ID for the arity and KEY_COLUMN_TYPE_MISMATCH for the type disagreement, each keyed on the entry the author wrote and each with a remedy naming it. Restating them here would be a second copy of a shipped rejection with a precedence between the two, which is how one family ends up with two answers that agree until one changes. NAMED_PARAMETER is the carrier no pair exists for, which the slot relation calls the coordinate at which the wire format reached consumer code unread, and judging it is the whole of what this relation adds. The input-field site draws no row, and that is the population’s stated edge rather than an omission. There the parameter receives a container and the decoded value goes to a member of it, so the one destination that resolves is the node type’s own record and everything else wants the walk into the class the slot relation deliberately does not perform. Comparing a container’s type against a key column’s is not an author error and a refusal naming both would be asking for a parameter the author was right to declare, so the shape is owed an emitter rather than a verdict. Which verdict fires is the key’s arity and nothing else, which is why one CASE decides it. Above one column there is nowhere for the second value to go, a parameter holding one; at one column the two types are compared. Both are the author’s to fix in one line of their own signature, so neither is a deferral and no arm here fails while promising an emitter later. The type verdict fires only where both operands are known, which is intent_resolved_node_key_projection’s discipline for the same comparison and is load-bearing rather than inherited wording: a key column no catalog could type and a parameter no census could type both leave the decode to be carried out on arity alone with javac as the backstop, because refusing on an operand nobody could read is the silence this family exists to close and not a second one to open. The arity verdict reads the slot’s type too, and reads it as an absence rather than as a value: what it needs is whether the slot is the tuple’s own row type, and a parameter position naming no class is a primitive or a type variable, neither of which is a generated record, so a composite key still refuses at a parameter the census could not type. That is not a verdict fabricated from a missing fact; the operand is the row type’s identity and the absence answers it. There is no accept line and no population filter of its own, on intent_authored_claim_conflict’s settled terms: the build-error surface joins the classification domain, only an emitted coordinate being able to fail a build, and the editor’s diagnostic arm reads the rows ungated, a coordinate nothing reaches being where an author most needs the signal. Absence is therefore not a message here either. An instruction with a row in neither this relation nor its direction’s resolution relation is either a shape the model does not yet account for or a coordinate another family refuses, and both lists are enumerated rather than left to be discovered. Owed an emitter: every input-field slot above, and a slot the value lands inside. Refused elsewhere: an overloaded producer, whose several candidate slots are a reference the schema walk rejects by name before any of this is read, so declining to pick here leaves no silence; and a departing or arriving table that did not resolve, which the walk likewise refuses on its own. There is no message column, the closed vocabulary plus the witness columns being the fact base and the prose belonging with the consumer that composes it.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Where a decode starts and where it has to arrive: for every slot carrying the @nodeId instruction on a decoding site, the table the slot’s own predicate binds on and the table the named node type’s keys live on. The relation the decode’s hop child, its key-column child and the destination over them all read, and it exists because those three would otherwise each resolve the same two tables: the destination is a reduction over the key-column child, the key-column child walks the hops, and the hops need a departure, so the endpoints have to be stated once below all three rather than recomputed inside each. Decoding sites only, which is the direction rule stated as a population rather than as a column: an output field encodes and the two input-side sites decode, so this relation’s WHERE clause is where the direction lives and no reader switches on one. The departure is graphitron_argument_scope_table’s answer at the consuming argument, which for an argument is its own coordinate and for an input field is the coordinate at the head of its occurrence path, both reached in one pass over the population; that answer is one table per branch where the consuming field returns a multi-table polymorphic container, so such a slot has one endpoint pair per branch and the decode is stated once per branch, which is what the resolver does with it; the two would be a union arm each and each would name the instruction relation again, which is the multiplicity the fact model’s own measurements warn about, so the occurrence path joins outer and the coordinate is picked by COALESCE. The arrival is the node type’s resolved binding, demanded unambiguous for the reason the departure is: two candidate tables are two different key tuples, and a decode against a table the author never named is worse than a decode that does not resolve. The navigation column is the whole reading this relation adds beyond the two tables, and it is a closed vocabulary of three. SAME_TABLE is own-row identity: the slot supplies encoded ids of the very rows it binds on, so the keys land on the row’s own key columns and there is nothing to walk. AUTHORED_PATH is an @reference the author wrote, whose hops the reference-target views resolve, one such view per site. DISCOVERED_KEY is neither written nor identity, where the resolution is the one foreign key declared on the departing table that reaches the arriving one. A fourth value stood here and no longer does. UNRESOLVED_PATH named an input field carrying its own @reference, whose path departs an input type that binds no table, and it existed because no relation walked such a path: the two reference-target views of the time departed from a field’s own binding and from an argument’s scope, and an input field has neither. The value was a statement that the question could not be asked, kept as a value rather than an absence so a consumer could not read it as a chain that legitimately lifted nothing. The input-field walk now exists, departing from the table the consuming field hands the expansion, so the same path resolves the same way an argument’s does and the shape is an AUTHORED_PATH like any other. What the retired value protected against is worth keeping in view, because the protection is now structural rather than nominal: an empty hop set still means own-row identity under one navigation and a chain that stopped under another, and the hop relation states which.

One @nodeId decode whose key landing the store can show is wrong: one row per refused instruction, use site and branch, in a closed verdict vocabulary of two. For example a path stopping on film_category where the node type is bound to category draws PATH_STOPS_SHORT naming both tables, and a key column jOOQ binds as String landing on one it binds as Long draws LANDING_TYPE_DISAGREEMENT naming both.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The Java parameter a decoding @nodeId instruction’s value descends into, where it descends into one at all, and the type that parameter takes. The relation the decode’s destination forks on first, and the fork is not between two shapes of predicate but between a predicate and consumer code: a slot carrying the instruction never delivers the wire format to a consumer, so where the value reaches Java the departing table the endpoint relation resolved receives nothing and no predicate is emitted from it. What decides that is the root of the use site rather than the instruction’s own coordinate, which is the whole reason this relation is cheap and the reason it is correct. An argument’s value reaches Java when a producer parameter is fed from it; an input field’s value reaches Java exactly when the argument its occurrence path descends from does, the field being one step inside a value handed to that parameter. So both sites ask one question at one coordinate, the occurrence path supplies that coordinate for the input-field site and the instruction is its own for the argument site, and no relation about classes, type backings or class members is read at all. An earlier shape asked instead which class member received the value, and it was both slower by an order of magnitude and answering a question one step past the fork. Two carriers, disjoint by construction. MAPPED_PARAMETER is an argMapping pair whose path binds the root argument itself, which is how a bean or a record is fed the whole argument, and it covers both the pair that stops at the argument and the pair that names a key column beyond it, those being one destination differing only in provenance. NAMED_PARAMETER is the producer method declaring a parameter of the root argument’s own name with no pair on that parameter, which is the match the generator itself makes and the coordinate at which the wire format reached consumer code unread. The absence of a pair on the parameter is what makes the two disjoint, and it is read on the parameter rather than on the argument because a pair redirects a parameter to some other argument and the name match must not then claim it. Presence and type are two facts here and keeping them apart is the one place this relation must not inherit its neighbour’s reading. intent_argmapping_bound_parameter_type has no row where the census cannot type a parameter, and its readers are free to treat that absence as no answer. Here absence means something else: no row is "this decode binds a predicate", so an untypeable parameter arriving as absence would route a value bound for Java to a table predicate that has nothing to bind. Both arms therefore reach the type by outer join and an untypeable parameter is a row with a null type, which is what lets a consumer carry the decode out on arity alone and ask for a type only when it is about to refuse. Ambiguity is rows and nothing is preferred: an overloaded method or a class two classpath entries declare resolves more than one row and candidates says so, on the neighbouring relation’s own terms. Which is why an ambiguous producer reference is not filtered out here, where every other reader of that relation demands one candidate. Demanding one would drop the rows entirely, and a use site with no row here reads as binding a table predicate, so an author whose @service names two overloads would get the wire format bound into SQL on the strength of an ambiguity nobody resolved. Keeping the rows makes that use site a decode with several candidate slots, which a consumer refuses to carry out rather than mistaking for a predicate. The stated limit is one shape, and it is the one this relation’s coordinate choice trades away. An argMapping path that descends into the argument and binds one input field below it (a pair spelled arg.field) hands that one field to a parameter while its siblings still bind predicates, and this relation sees no row for either, its arms asking about the root argument and that path binding something under it. Saying which occurrence path such a pair names is a reconciliation between two decompositions of one descent rather than a join, and until that is stated an input field reached only that way is read as binding a predicate.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. How an output field carrying the @nodeId instruction produces the tuple it encodes. The encoding half of the resolution, and a separate relation from the decode rather than one relation with a direction column, because the two answer different questions and sharing a row shape would leave half the columns nullable by kind: a decode has a destination that receives a tuple and, where that destination is a table, a column correspondence and possibly a join path, while an encode has a source that produces one and never has either. Direction is therefore not a column anywhere; it follows from the site and from which of the two relations answered. Output fields only, which is that rule stated as a population. Two sources, and the discriminator is whether a column tuple is in scope at all. PROJECTED_COLUMNS is everything that encodes today: the field sits on a type some table stands for and nothing overrides how its value is produced, so the key columns are selectable and the encode wraps them at the projection, whether they are the row’s own or reached through an authored path. READ_VALUE is the rest, and it is one source rather than four because the four spellings differ only in the mechanism a value arrives by: an accessor on a backing class, a by-name record read, a typed column off a record, or graphql-java’s own property machinery all hand the generator one value, and the encode applies to what the read yielded. The two conditions that put a field there are a containing type no table stands for, which is what an @error type is, and a field whose value a named producer method returns, which overrides the projection its containing type would otherwise offer. That second condition reads the producer reference and not the method it resolves to, on purpose: an @externalField naming a method the classpath census never saw still means the value is read rather than projected, and asking the resolved relation would have made an unresolvable reference look like a projection, which is the one reading that puts a base64 string where a column belongs. One precondition is stated here and it is arity: a read yields one value, so a node type whose key is several columns cannot be encoded from one, and such a coordinate has no row. The other precondition a READ_VALUE encode has is deliberately not stated here, and the reason is a limit rather than a preference: an encode from a read needs the value to arrive as the key column’s own Java type, and what type the read yields is decided by which of four locator arms the classification chose. Two of the four type nothing at all, and one of the two that do resolves an accessor by a candidate order and a naming rule, which is an algorithm and not a fact this schema holds. So these rows over-claim by exactly the coordinates the schema walk refuses on type, that refusal being where both operands are in hand: the walk loads the backing class through the codegen classloader and reads the catalog for the column. A reader wanting the whole truth about an output field reads the classification’s own verdict beside this relation, and a partial precondition here would be worse than the stated absence, since it would resolve or refuse depending on which arm answered without being able to say which arm that was. A projection has no such limit, the whole tuple being in scope, which is why the arity demand is written once against the source rather than as a blanket filter. Absence is therefore not the message and never should be read as one: an instruction with no row here was not carried out, and which precondition stopped it is the detection stratum’s statement with the operands to make it, on the same terms that keep the candidate and projection relations beside the argMapping family disjoint by construction rather than each re-testing the other’s predicate. Presence is not an emitter, which is the symmetric reading and the easier one to get wrong: a row says where the tuple would come from, and whether the generator carries the encode out at that coordinate is the schema walk’s fact rather than this relation’s. Two shapes here are recognised and deferred rather than emitted, and both are named so neither is left to be discovered: a PROJECTED_COLUMNS row over an authored path that did not collapse into the parent’s own columns, which the walk defers at the reference carrier, and a READ_VALUE row for a field whose value a producer returns, which the walk defers with a message naming the producer directive. Narrowing the population to what emits today would make this relation track emitter maturity, so a shape acquiring an emitter would change rows in a graph whose schema nobody touched, and the two facts a consumer wants apart would be one column again.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. What is wrong with a @nodeId instruction whose typeName: names a polymorphic container: one row per refused instruction, use site and, on the two member verdicts, member, in a closed verdict vocabulary of five. The sibling of intent_node_id_decode_defect and deliberately not new arms on it: that view’s whole design is two verdicts decided by the node key’s arity alone in one pass over two driving relations, and these five are decided on the coordinate, the member set and the slot’s type, which is a different fact base. The two populations are disjoint for a reason the incumbent already states rather than one asserted here: it joins intent_resolved_node_key_shape on the slot’s resolved type, and a container resolves no key of its own, so every row of this population misses that join and draws nothing there. Precedence runs outward in, and it is the remedy’s order rather than a ranking invented for tidiness. CONTAINER_NOT_AT_A_SLOT first, the coordinate deciding whether the polymorphic rule reaches the instruction at all before the member set is worth reading; then the two container verdicts, whose remedy is the container’s; then the two member ones. Two grains in one relation, with member_type_name NULL on the three container-grain verdicts and set on the two member ones, determined by the verdict the way the incumbent family determines nullness by its discriminator. One limit on how much of the rule this states, and it is the incumbent’s own population edge rather than a hole opened here. At an input-field site intent_node_id_decode_slot.java_type is the bean’s type and not the annotated member’s, the slot relation resolving the parameter at the root of the use site and deliberately declining to walk into the class, which is why the incumbent excludes that site outright and calls the shape owed an emitter rather than a verdict. So the container-side half of the rule is stated at every site and the slot-typing half, SLOT_NOT_SUPERTYPE_OF_MEMBER and the POLYMORPHIC_RECORD destination with it, only where the slot relation types the slot the author annotated. The walk refuses a mistyped bean member on its own, so no build goes silent; what narrows is the store’s agreement, and what would close it is the descent from a bean parameter to the member receiving the value, which is code_read_slot’s territory. Stating the edge is the point: a verdict that compared a container’s type against a member’s key would refuse a bean the author was right to declare. Two further shapes fall outside the partition and are enumerated rather than left to be discovered, both refused by the walk on its own. A polymorphic slot whose declared type no census could read draws neither a destination nor a verdict: unlike the single-column destination there is no arity-only fallback to stand aside onto, the emitted helper’s return type being the slot’s own type, so the walk refuses such a slot outright and a verdict comparing an unreadable type against a record would be inventing one of its operands. And an overloaded producer draws neither, this relation demanding one candidate rather than picking a type, which is the demand the slot relation’s own comment makes of a reader that needs the type and the same shape the incumbent enumerates for itself. There is no accept line and no population filter of its own, on intent_node_id_decode_defect’s settled terms: the build-error consumer joins the classification domain and the editor’s diagnostic arm reads these rows ungated, a refused instruction at an unreached coordinate being exactly where an author most needs to be told.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. What is wrong with the node-identity metadata a generated table class stated: one row per defect, over the sql_node_metadata rows and their entries alone. The rows it reads are transcription because a walk read them; this is not, because no walk read the verdict that metadata is malformed. Graphitron’s rule produces it, and every join is inside the jOOQ corpus, which is what makes it a derivation over one corpus rather than a validation smuggled into a crawler. Well-formed metadata is a sql_node_metadata row with no defect rows, and the conjunction is the whole test: no defect rows alone is also what a table publishing nothing at all has, that table having no metadata row to be well-formed. Every defect a table exhibits gets a row, with no first-failing short-circuit, so no evaluation order becomes normative; a reader wanting one message reduces by an ordering it owns. There is no reason-text column, deliberately: the closed defect vocabulary plus the witness columns already stored are the fact base, and message prose belongs with the consumer that composes it. Keyed on the catalog’s own key with no graph partition, as sql_name_matched_key_column is: the question is about a table, and a graph reaches it the way it reaches any source-keyed fact.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. What a polymorphic container holds, read at the grain a derivation asks it: the two captured relations unioned under the intent_ family’s names. Over the base relations rather than over graphql_poly_member, which says the same thing: that view is for readers outside this store, and reading it here would put a second view body in every detection component that asks this question. The two populations are two captured relations, so this body is the union of them under one name, which is the name three derivations already spell. What it once carried and no longer needs to: the interface arm’s position was ranked by a window function over the whole partition, which a correlated probe cannot prune, so every reader paid to re-rank every implementor of every interface on every driving row. Capture writes that order now, and the note the old body owed its readers moves to the column that holds it. One reading of these rows is still a choice rather than a fact, and it is the mapping-constant fingerprint’s: its digest is over a handler list in this order, source order, where the legacy walk’s own order for the interface arm is graphql-java’s registration order, which is neither source order nor documented. Source order is the defensible one and the disagreement is the walk’s to lose, but nothing has adjudicated it and a reader minting a suffix from these rows should know it is choosing.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Whether a node type’s generated record can land in a slot of a given declared type: one row per (node type, slot type) pair where the record is that type. The store’s answer to the question a live Class.isAssignableFrom answers at the walk, asked of a generated record against a slot the author declared, and the one relation both the polymorphic record destination and the polymorphic defect view’s slot verdict read, which is why it has a name rather than being the same expression written twice. Two arms over one captured fact and not a composition of two censuses, which is the whole of what makes it affordable, and the reason is that sql_table_record_supertype holds a closure rather than edges: the catalog walk climbs the live record class, so an interface a consumer’s jOOQ recordImplements option puts on the records is a row there and so is every supertype of that interface, at any depth. A census leg was written first, joining a closure over the classpath’s supertype edges to climb from a record-declared interface, and it was both redundant and unaffordable: redundant because the capture had already climbed that far, and unaffordable because H2 inlines a recursive view and re-evaluated the whole closure once per driving row, measured at two orders of magnitude over the two arms below and never returning against a real capture at all. Two rewrites of that leg were measured and neither helped, one unchanged and one worse; what fixed it was deleting it. The reflexive arm is there because assignability is reflexive and the walk’s comparison is: a slot typed as one candidate’s own record is assignable for that candidate and not for its siblings, and it is the sibling that refuses the slot. Total over the node population rather than seeded from the slot types a graph asks about, which was also tried and also cost: seeding pulled the decode-slot relation into the join and H2 re-evaluated it per driving row. Absence is not-known-to-be-assignable and never not-assignable, and the shortfall falls in one direction only; what bounds it here is that the closure is captured off a live class rather than reconstructed from anything, so the only pairs it misses are those of a table jOOQ generated no record for, which has no row at any slot type because the record class is NULL there.

One @referenceFor application paired with a consuming coordinate that offers the participant it names: one row per application and consumer whose participant set holds the spelling. For example an application naming Film under an input type two queries consume draws a row for the query whose union holds Film and none for the query whose does not.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The field-grain claim resolution: the authored relation unioned with the inferred rows at coordinates the authored relation does not cover. Masking is this join’s job, never a classifier’s guard, and the anti-join sits at the coordinate grain: any authored claim at a coordinate masks every structural reading there, presence arms included, because a directive whose decode declined still diverted the walk. The projection is the claim key plus tier, no trigger, decoded or witness component, so nothing goes nullable by kind; a reader wanting provenance joins the tier’s own view, and tier is a column precisely so that home is a read rather than a hand-maintained classifier-to-relation mapping. The stratum’s second layer, and what a planning reader eventually joins.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The field-grain demand reduction: one verdict per accounted coordinate of the classification domain, over every field-bearing parent kind (input coordinates resolve EXEMPT here rather than falling outside the domain). Demand beats exemption where both relations carry the parent (a @table type shaped like a connection classifies its fields, so the demand reading wins, matching the walk); within each side the rule is the first arm in the vocabularies' declared order, so the more specific reading names the row (machinery beats the directiveless catch-all). A domain coordinate with neither reading has no row: by construction the nesting-target arm complements the demand arms over plain objects, so absence marks the shadow residue (reflection-bound parents), and the agreement’s coverage gate counts resolved rows against domain coordinates to keep that construction honest. The future demand gate is this view’s DEMANDED rows anti-joined against the resolved claim view; nothing gates on it in shadow.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. An argMapping binding that decodes a node id and projects one column out of the decoded key, where the projected value can actually reach the parameter it is bound to: the candidate rows beside it, joined to the consuming parameter’s own Java type and kept only where the two agree. The reduction the whole item turns on, and the row an emitter reads to know which column of a decoded record to hand a routine parameter. A reduction over the relations beside it rather than a derivation of its own, which is what the resolved_ prefix names: the path resolution is graphitron_argmapping_match’s, the key list is graphitron_node_keycolumn’s, the name match and the column’s type are intent_argmapping_key_column_candidate’s, and the parameter’s type is intent_argmapping_bound_parameter_type’s; this is only where they meet. The type agreement is a join predicate and not a check performed after the fact, which is the whole of why it is sound: an emitter reads this relation, so a pair whose types disagree is not a projection an emitter can see, and there is no order of operations in which one is emitted and then rejected. Equality of the erased Java type, no widening admitted: a SMALLINT key column bound to an Integer parameter is a disagreement here, and whether that is a mismatch worth telling an author about is a question the detection’s message answers rather than one this predicate softens, softening it being what would let a narrowing through. The gate fires only where both operands are known, and standing aside on either absence is the deliberate half. A parameter whose type intent_argmapping_bound_parameter_type cannot state (a consumer compiled without -parameters and a reference resolving no method, which draw no row there at all, and a declared type naming no class, which draws a row carrying a NULL type) and a column the catalog cannot type (a node type with no unambiguous table binding, a pinned key column the bound table does not have) both leave the pair projecting exactly as it did before this predicate existed. Requiring the match in either case would have turned such a pair into one that is neither a projection nor a defect, which is the silence this whole family exists to close, and on the column side it would additionally have contradicted the key-column relation’s own rule that a pinned name resolves without a table. Standing aside leaves those where they were, projections whose types this gate never checked. What becomes of them afterwards is no longer one answer, and the split is worth stating here because an emitter reads this relation. A parameter declared as a Java primitive is refused by ArgmappingProjectionDefects before emission: the projected read is a boxed local at every shape of nullability along the path, an omitted @nodeId anywhere on it projecting null, and the compiler catches nothing at int p = <boxed null>. An array or type-variable parameter, and every absence that draws no row here at all, keep the compiler’s own error as the backstop they always had. So the gate strictly adds rejections and removes no emission, which is what makes it safe to land as a join rather than as a staged flip. One trailing name or none, never two and never a minimum, and where there is one it is what the written path spells past the candidate that bound: all of that is the match relation’s, stated there. The none case is the inferred form, a one-column key needing no name to select it, and it resolves here on exactly the terms the authored form does: the same column, the same type reached the same way, the same row shape. So this relation is read without asking which of them a row came from, which is what makes the two one emission rather than two. Which arm answered rides here all the same, on trailing_name, because an emitter needs one fact the row shape does not otherwise carry: where in the written path the wire id it decodes sits. That is provenance a reader may ignore and an emitter must not, so it is carried rather than left one join away on the candidate. Absence means this pair is not a projection, and every way of arriving at that absence is a query over the relations beside it rather than a fact this one withheld: a leaf with nothing trailing under a key of two or more columns is the bare form a rejection closes, a leaf with two or more trailing segments is the typo, a trailing segment matching no key column is the unknown column, a candidate whose types disagree is the type mismatch, a leaf carrying @nodeId with no typeName: is the missing type name, and a pair with no leaf row at all is a path the walk rejects before the store is written. None of them is this relation’s to report, which is what keeps it a positive population an emitter can trust rather than a verdict it has to interpret.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. A node type’s key reduced to what a slot receiving it has to agree with: how many columns the key has, the row type that carries the whole tuple, and where the key is one column that column’s name and the Java type it binds as. The relation a destination or a refusal reads when the question is not which columns the key is but whether a given slot can hold it. Every value here is a function of the key-column relation beside it and the type’s own table binding, so this states no new fact and exists for one reason: three consumers would otherwise each aggregate the key list and each re-resolve the binding, which is the inline multiplicity the fact model’s own measurements warn about, and a reader that wants the columns themselves still reads the relation this reduces. Arity is a count over the winning tier’s whole list, which is sound only because that relation picks a tier rather than a position; a per-position pick would make this number the count of a spliced list. It is counted before the two catalog reaches below it rather than after, which is not a stylistic ordering: either outer join can in principle match a key column twice, two catalog columns folding to one name being the case, and a count taken after that would report a key longer than the key is. The record class is the generated row type of the type’s own table, absent where the binding is ambiguous, where no table binds at all, and where the catalog answers org.jooq.Record, which sql_table’s own comment says is the catalog reporting no generated record rather than a record named that; the exclusion is a join predicate here so that absence is one thing at every reader instead of two. The two sole_ columns are stated only at arity one and are NULL above it, which is determined by the arity beside them rather than by anything unknown: a composite key has no single column, so a NULL here at arity two is the key’s shape and not a missing reading. Their absence at arity one is the ordinary catalog absence: a pinned key column resolves with no table at all, on the key-column relation’s own rule, so a name that names nothing the table has still has a row there and reaches no type here. A reader gating on type agreement therefore stands aside on the NULL rather than refusing, which is the discipline intent_resolved_node_key_projection already states for its own version of this operand.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The type-grain demand reduction over the classification domain, mirroring the field-grain reduction: demand beats exemption, first declared arm wins within a side, and a domain member with neither reading has no row, which marks the type grain’s shadow residue (directiveless objects whose registration is decided by the embedding walk and the reflection fixed point). The shadow agreement splits that absent population into its named parts rather than treating it as one structural bucket.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. Which catalog table a type is bound to by being what a @routine chain field returns: intent_field_chain_terminus keyed by the returned type rather than by the field. This is the binding a @routine author writes @table for today, derived instead, so the routine name is written once and the two spellings can no longer disagree. The type read is intent_field_navigated_type’s, so a connection-returning routine field binds its element type and not the wrapper, whether the generator synthesised that connection or the author declared it; that navigation is stated once in that relation and read here rather than spelled again. OBJECT only, a landing being a row and a row standing for an object type. The population is the chain read seats, and one seat is excluded: the payload carrier, a mutation root’s @routine field carrying no @reference, whose chain rows are not what the field returns but what its data field re-reads post-commit, so a binding there would name a table for a type no table stands for. The exclusion names that seat rather than the carrier because the store holds no carrier fact yet; the seat is the classifier’s own fork, which reaches the carrier resolution exactly when the parent is the mutation root and the chain has a single node, and it narrows to the carrier itself the day a carrier relation lands. That day has come and the narrowing is deliberately not taken here: intent_mutation_routine_seat states the same fork as its seat column, so the exclusion could read seat = CARRIER and mean exactly what it means today, but narrowing to the carrier itself means excluding only the seats that hold, which hands a binding to every mutation-root @routine this relation currently keeps out and changes the arity every reader of the reduction sees. That is a change to make on its own evidence, not in passing. The seat exclusion costs the routine write chain nothing, that shape carrying @reference by construction. Keyed on the root operation binding and not on the literal name Mutation, the same intended-rule form the demand rules and intent_field_separate_fetch’s root arm state. Ambiguity is rows, never a decline, on intent_bound_table’s terms: two fields returning one type off different routines are two rows and candidates says so. Nothing here is masked by an author’s @table, a type carrying both being a fact about the schema and not a conflict for this relation to settle; where the two populations meet is graphitron_resolved_type_binding.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The keys a consumer may identify a row of a table by, in the order the generator considers them. One row per surviving candidate, ranked, and the rank is the whole point: a write surface handed a set of columns takes the first candidate those columns cover, so a relation that listed the candidates unordered would leave the choice to whoever read it and two readers could disagree. The order is the generated model’s own, the primary key first and the remaining unique keys in the enumeration jOOQ hands out, which is why sql_constraint.key_position is captured rather than derived. Two projections come with that order and both are the generator’s rather than this relation’s. A unique key whose column set an earlier candidate already carries is dropped, so a table whose primary key is also declared unique offers one candidate and not two, and the survivor is the earlier one, which is the primary key whenever the primary key is in the tie. And a unique key resolving no columns at all is dropped, where a primary key in that state is kept: an empty primary key is a fact about a table nothing can identify a row of, and a consumer meets it as a candidate that covers nothing rather than as a table with no candidates. That the columns resolve at all is a property of capture here rather than a case to handle: sql_constraint_column carries a foreign key into sql_column, so a key naming a column the catalog does not have could not have been written. Absence is a table declaring no uniqueness constraint, which is every view and every table nothing identifies a row of, and it is what a write surface needing an identity meets when it finds nothing to cover. The columns themselves are not here. They are sql_constraint_column’s, in its own position order, joined on the constraint name this relation gives; putting them here would make the grain a column and the rank would have to be repeated down every row of a key.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. What class stands for a graph’s type, from either population that can answer: the type’s table binding read through the table’s generated record, and the closure over producer returns and accessor hops. The table arm reads graphitron_resolved_type_binding and not the @table population alone, because what puts a generated record behind a type is that some table stands for it, and a routine chain’s return binding stands for one exactly as a written @table does; a reader wanting only the written population joins the arm. One relation for the question every consumer of a backing actually asks, which is what class, not which walk found it. A view coalescing two relations rather than a base with a provenance tag, on the stratum’s provenance rule: each population is derived by its own rule from its own facts and neither is a special case of the other, so they are separate relations and this is where they meet. Both arms carry the same payload, one binary class name, and they can do that only because sql_table records the record class; before that fact was captured the arms had nothing in common and this view could not be stated without four columns NULL by kind. A table whose generated model has no record class reports org.jooq.Record, and that is not a backing, so the arm drops it and the type is unbacked here, the same silence a type no producer reaches already gets. Ambiguity is rows on both arms and nothing is preferred: a type its @table binding and its closure answer differently is two rows, and intent_type_backing_conflict over this view is where a reader learns so. The walk resolves that pair by precedence, reading the table and never looking at the class, which is a reading a consumer may still apply by filtering on declared_via; what it may not do here is mistake the precedence for agreement.

A graph’s type is backed by a class: the reachability of intent_field_accessor_hop’s edges from the classes the graph’s producer methods deliver. For example a type whose only producer method returns a FilmRecord draws one row naming that record class.

Primary key: (graph_name, type_name, class_name). Foreign key: (graph_name) references store_graph (graph_name). Foreign key: (graph_name, type_name) references graphql_type_element (graph_name, type_name).

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The types the store answers with more than one backing class: one row per type whose producers, accessor hops and @table binding do not all name the same class. Stated over the coalesced intent_type_backing rather than over one arm, because a type contested across the two populations is contested in exactly the sense a consumer needing one class cares about, and an arm-local view would have called that agreement. Two disagreements therefore land here. Two producers answering differently is the one the closure surfaces, a population nobody could previously ask about: the walk resolves it by refusing the second observation and folding the survivors, so a contradiction between producers is either invisible or arrives as a rejection with the losing side already discarded. A @table binding and a reached class answering differently is the other, which the walk resolves by precedence, reading the table without ever consulting the class; that is a defensible reading and a consumer may still apply it, but it is a choice, and a relation that folded it in would have hidden the choice rather than recorded it. Counted over distinct class names, not rows, so one class both arms name is one answer and not a contest. The arity is all this relation adds: the contesting classes themselves are rows on intent_type_backing under this relation’s own key, so a consumer wanting them joins there and gets one row per class, where a set serialized into one column here would have answered set equality and nothing else. A view over the coalesce rather than a column on the closure, on intent_authored_claim_conflict’s terms: the contested population is a grouping over rows already held, and it costs nothing to state on read. Nothing gates on these rows yet. The reading this relation is shaped for is that a contested type is a rejection at whichever consumer needs one class, and the arity is what such a rejection stands on, which is why it is here rather than left to each reader’s own count.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. A graph’s type is backed by this class by a producer of its own, rather than by being read off some other type’s class. Two arms, one per axis, and they are the seeds intent_type_backing_class closes over: a field with an authored Java reference backs the type it returns with the class the resolved method delivers, and a producer’s parameter backs the type of the argument it is fed from with the class that parameter delivers. Which argument feeds a parameter is the parameter’s own name unless an argMapping entry redirects it, in which case it is the first name of the written path, which that relation carries as a generated column. Objects and input objects only, as in the closure, and a parameter the consumer compiled without -parameters feeds nothing. This relation resolves its producers against the reading where the closure’s skip condition reads the directive entries, and the split is the two questions they answer: which class a producer delivers is knowable only from the method the reference matched, while whether a coordinate is read off its parent is settled by the author having applied the directive at all. So a producer naming a class no entry declared seeds nothing here and still stops the hop there, and the type it names is unbacked rather than backed by whatever member of the parent’s class shares the field’s name. Every row here is a row of intent_type_backing_class too, this relation being where that one starts; what it adds is which of that relation’s rows a producer grounded. Not a column on the closure, for the reason that relation gives for having no route column: a class reached both by a seed and by a hop is one backing and one row there, and a route column would multiply every reader’s rows by however many routes converged. Kept as its own relation, grounding is a join and the closure keeps its grain. Why a reader would want it: the classification walk this family shadows settles a type’s groundings before it propagates anything, and then declines to read an already-grounded type off a parent’s member, because a hop reads the parent’s member type without checking it against the child’s own grounding and can therefore land on a class that is simply wrong. A reader reproducing that precedence takes a type’s rows from here when it has any and from the closure otherwise. The precedence is the reader’s and not this relation’s, which states only where a backing came from.

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The types that require a type-grain classification verdict. Directly type-grain (no projection involved): the root arm states the intended binding-keyed rule (today’s walk mints RootType for the three literal names, so a renamed root type is a pinned demanded-but-unregistered population, the same hole as its fields); every reachable interface and union classifies at its own visit, so those arms are kind-wide less the underscore short-circuit; connection machinery types are registered by the promotion that recognizes them, so the machinery reading appears here as demand while the same types' fields are exempt, and the arm reuses the exemption view’s recognition rather than restating it; producer payloads take a carrier or result verdict at their producing edge, reused from the field-rule arm the same way. Directiveless objects with no producer are deliberately absent from both this view and the type exemption: whether such a type ends registered (a nesting target some edge embeds) or absent (an orphan) is decided by the embedding walk and the reflection fixed point, which is the type grain’s shadow residue until those arms migrate. Leaf kinds (scalar, enum, input) are the exemption view’s named deferral rather than absent rows.

The classification domain’s type members: every named type, of every kind, the generator’s intended traversal reaches from its seeds. For example a graph whose Query.films returns Film draws a row for Query and one for Film, and a type nothing reachable names draws none.

Primary key: (graph_name, type_name). Foreign key: (graph_name, type_name) references graphitron_type (graph_name, type_name).

Deprecated with the whole intent_ family, which has no owning gatherer and is being retired. A fact derived here belongs in the family that owns the corpus it comes from, captured as early as it can be so that every reader reaches it instead of deriving it again. The types whose type-grain verdict is intentionally not demanded yet. The underscore arm transcribes the walk’s name short-circuit at every kind (a federation-injected _Service or _Entity, and any author-declared underscore type, never classifies). The leaf-kind deferral arm is a bound carried as rows rather than a test-side filter: reachable scalars, enums and input objects do receive verdicts today, but their demand rules belong to those classifiers' own migration slices, so this arm retires arm-by-arm as they land and the shadow agreement reads the bound as data. Arms are unmasked; the resolved view owns precedence.

← Schema index