Measure re-evaluation rather than naming, so a materialization cut set can be chosen on evidence

The shipped one is no.sikt.graphitron.roadmap.InlineMultiplicityCheck in roadmap-tool main scope, tested by InlineMultiplicityCheckTest and bound by roadmap-tool/pom.xml to verify as the report-inline-multiplicity execution, so it runs in every full build. It scans the authored DDL textually, counts each relation’s references per CREATE VIEW body, multiplies down the tree, and prints the fifteen heaviest relations. A materialized relation drops out by construction, its canonical name being a table. It reports and does not gate, deliberately, because it over-approximates: it counts textual references without knowing which arms a predicate prunes.

The uncommitted one is a probe written while filing R848 and never committed. It reads H2’s normalized stored definitions out of a booted store rather than the authored text, sums over the 48 root readers rather than reporting per view, and can redirect each registered target to its _live view to produce a no-materialization counterfactual, which is where 470 and 913,978 below come from.

They disagree, and the mechanism matters because it lands inside slice 1. InlineMultiplicityCheck counts what an author typed; MaterializeDependencies.relationsReadBy collects off the normalized definition and returns a Set, discarding multiplicity along with position. So the multiplicities available to the new instrument are H2’s after normalization, not the authored ones, and slice 1 has to recover multiplicity as well as position. Neither basis is wrong. They answer different questions, and no arithmetic reconciles their totals.

This item is about neither of them. It is about the weighted instrument that replaces the uncommitted probe. InlineMultiplicityCheck is not touched by this item at any outcome, which the acceptance section below states explicitly.

A derived relation is a view in the fact store: a rule stated once in SQL, evaluated whenever a reader names it. A registration moves the canonical name onto a table refilled from the rule once per capture, so readers stop evaluating it. A root reader is a view no other view names, which is where a real read enters the derivation. Re-evaluation is the thing being counted throughout: how many times the engine actually executes a rule’s body during one read, which is not the same as how many times an author wrote its name.

Computed by the uncommitted probe over 107 views, 168 base tables, 20 registrations and 48 root readers. Both figures are total rule instantiations summed across every root reader, counting H2’s normalized references with multiplicity. They are not comparable with `InlineMultiplicityCheck’s per-view ranking, whose heaviest single view already exceeds the first figure here.

These figures are pinned to the tree they were taken on and are not restated per run. That tree declared 107 views; trunk declared 109 within a day, two having landed while this item sat in review. Swapping the census while leaving the totals would misattribute them, and re-taking the totals on every census move is work with no reader. Nothing downstream depends on their being current: the acceptance gate compares against magnitudes recorded in the DDL rather than against anything measured per run. The drift is also the item’s own thesis happening again while the item waits for it.

The distribution is the finding rather than the ratio. A single family dominates: the five worst root readers are all in the write-payload chain and account for about 98% of the total. A greedy search, adding whichever registration cuts total expansion most, reaches 595 with twelve registrations against the 470 that twenty buy.

The same probe was run two days apart, across a tree that gained exactly one registration in between, and the pair says something no per-relation measurement could.

intent_field_scope_table was registered by an increment whose subject was not materialization. On the tree before it, intent_argument_scope_table was the single largest lever in the whole register: greedy step one, taking total instantiations from 910,497 to 78,457. On the tree after, that role belongs to intent_field_scope_table (913,978 to 77,209), and intent_argument_scope_table has fallen to a marginal value of +17 and last place in the greedy order.

Registering the lower relation absorbed almost all of the upper one’s value. The two are near substitutes and the register holds both, each with its own reason arguing its own case, neither mentioning the other. Nobody did anything wrong and nobody could have noticed: the value of a registration is a function of which other registrations exist, and no per-relation measurement can see that.

This also shows why the marginal column is the wrong summary to act on. intent_field_scope_table scores +9 marginally and is the largest lever in the register. Registrations are substitutes, so dropping-one-at-a-time systematically understates every relation that has a near-twin.

Three mechanisms put registrations in the register. A naming metric, on either parsing basis, models one. Nothing below turns on the difference between the two, which is why they are separated once above and treated together here.

Check the blindness against the register’s own timings. intent_mutation_write_destination scores 10 and its reason records 12983 milliseconds falling to 5.4. `+intent_field_reference_step_hop` scores 36 and its reason records `+intent_node_id_decode` falling from about fifty seconds to about thirteen. Those are the two registrations bought for per-row and recursive re-evaluation, and the metric ranks them near the bottom.

So a naming metric is a map of one mechanism, useful for locating where breadth concentrates and unusable for choosing a cut set. Committing the probe as-is, or reading a cut-set decision off the shipped report, would repeat the error the store-performance skill already records twice: a count that is real, and a reading of it as cost that is wrong. InlineMultiplicityCheck does not make that error itself, its javadoc saying outright that it reports rather than gates because the metric over-approximates; the error would be a reader’s.

A metric that weights each naming by its position, because position is what decides how many times the engine runs the body.

Parse each stored view definition with jOOQ’s parser and classify every relation reference as one of: plain (evaluated once per naming), inner-side-of-join (once per driving row), correlated (once per outer row), or recursive-term (once per iteration). MaterializeDependencies already parses stored definitions this way and walks them, collecting table references off the query object model rather than off text, so the walk and its normalization rules are established; what is new is retaining each reference’s position instead of discarding it.

Weight the three re-evaluating positions by the driving side’s cardinality, which the store can count because it holds the rows. That makes the metric population-dependent, and that is correct rather than regrettable: the register’s own reasons record that a synthetic fixture twelve clusters wide understates a per-row probe by as much as it takes to turn four seconds into no termination at all. A metric that ignores population would inherit exactly that error.

Home: graphitron-model, test scope, beside the instruments that already live in no.sikt.graphitron.model.test (UnregisteredRelation, RunawayRelation, FactStores). It is a research instrument and nothing at runtime needs it. Promoting it to main scope, or to an MCP surface, is a separate question and should not be settled here.

Why not extend InlineMultiplicityCheck instead, which is the module that already holds a static metric over this DDL.

Not for want of dependencies, which is what an earlier draft of this plan claimed and got wrong. roadmap-tool depends on graphitron-model at compile scope, so jOOQ is on its classpath; it carries org.duckdb:duckdb_jdbc (named as evidence about that module’s dependencies and nothing more: this instrument runs on H2 through jOOQ like everything else in graphitron-model, and nothing in this item uses DuckDB or proposes a change of engine, the fact store’s own being out of scope however much the register’s reasons blame its inlining); and it already opens a populated store on every full build, SchemaIdentifierDriftCheck and SchemaReferencePages both calling GraphitronModelStore.open() with check-schema-identifiers bound to verify beside report-inline-multiplicity. Both inputs this instrument needs are present there today. The "needing no database and no profiler" premise belongs to InlineMultiplicityCheck and describes that check, not the module around it.

The grounds are the instrument’s collaborators and its cadence.

The walk being extended is MaterializeDependencies.relationsReadBy, graphitron-model main scope. Extending it from another module means duplicating the walk or widening its API for a single caller, and the H2 normalization rules it encodes are exactly the part that must not be re-derived independently, the two existing metrics already disagreeing because their bases differ.

The counterfactual’s collaborators are test scope in that module. Scoring a candidate cut set means evaluating the registered and unregistered shapes of a relation, which is what UnregisteredRelation does, over a store from FactStores; both are no.sikt.graphitron.model.test, republished as a test-jar so downstream modules build on that floor rather than opening a store of their own. report-inline-multiplicity runs from roadmap-tool main scope through exec:java, and main cannot reach test-scope instruments. Hosting the weighted metric beside it therefore means reimplementing the swap in main scope, or putting it in roadmap-tool test scope where it is neither a build step nor near anything it collaborates with.

Cadence decides what is left. Every roadmap-tool execution is bound to verify, so the module’s shape is build steps. This instrument answers a question somebody is asking at the time they ask it, and its store boot and cardinality counts are not costs to add to every build. A class can sit unbound in that module, which is why this is the third ground rather than the first.

So the two coexist on purpose, with different jobs and different cadences: a DDL-only report that runs every build and catches an authored-multiplicity regression, and a store-dependent instrument run on demand when a cut set is in question. What would make the shipped one redundant is a weighted metric that runs without a store, which this plan does not propose and does not believe in, the population being the reason the register’s own reasons record a fixture understating a per-row probe by orders of magnitude.

This is the gate, and the item fails honestly rather than shipping a plausible number that nobody can check.

Most rows of meta_materialize carry a measured before-and-after in wall clock. Those timings were taken on different trees and different schemas, so they are not comparable as figures. What survives that incomparability is a coarse class, because the classes below sit orders of magnitude apart and no cross-tree noise flips one into another.

Classify all twenty first, then score. The classes are fixed and written into this item before the metric is run, so the gate cannot be tuned to the answer it produces. Class on the absolute saving a reason records rather than on the ratio: a cut set is chosen to reduce total time, and a large ratio on a small base is not evidence of value.

The ship condition is over all twenty, not over a triple: no registration may outrank one in a higher class. Class U is excluded from the comparison, having no evidence to compare against, and must be listed rather than quietly dropped.

This discriminates, and the earlier version did not. The probe fails it, on the same marginals this plan already reports:

What the triple was, and what it now is. An earlier draft made the ship condition an ordering over intent_mutation_write_destination, intent_field_reference_step_hop and intent_argument_column_match, and claimed the probe got it backwards at 10 and +36 against +4. That claim was simply wrong: those three marginals are in the demanded relative order, and the probe passes that test. So does `+InlineMultiplicityCheck` on the obvious per-registration derivation, its source-view subtree counts putting them at 28, 20 and 6. A ship condition passed by both metrics this item exists to replace is not a gate. The triple survives below as an illustration of what the blindness looks like, which is the job it can actually do: intent_field_reference_step_hop and intent_mutation_write_destination, the two bought for recursive and per-row re-evaluation, rank tenth and fifteenth of twenty by marginal (+36 and +10) despite their reasons recording among the largest measured wins in the register. That is a statement about where they sit in the whole ranking, which is the claim the gate now tests, rather than about their order among themselves, which was never wrong.

What the negative branch deletes, stated exactly because the first draft of this plan left it to implication. If the gate fails, the new weighted instrument and its tests are deleted, and the uncommitted probe stays uncommitted. InlineMultiplicityCheck, its test, and the report-inline-multiplicity build step are untouched: they are a build-bound reporting surface whose retirement is a separate decision with a separate blast radius, and nothing this item measures bears on whether that report is worth printing.

Where a negative result is recorded. Not in this file, which is deleted at Done. It goes in roadmap/changelog.md, one of the three permanent roadmap artifacts, naming the item and what the gate refused and why. A finding that a static count cannot rank these registrations is worth as much to the next author as a working metric would have been, and it is the kind of result this tree loses by default.

Slices 1 and 2 are worth nothing without 3 and should not land separately from it.

The classifier is the risk. H2’s stored definition is already normalized and may not preserve the distinction between a join whose inner side is derived and one whose inner side is a base relation in a way the parser exposes. If it does not, slice 1 stops and the item needs a different reading of position, possibly from EXPLAIN plan shape rather than from the definition. Establish this in slice 1 before building anything on top of it.

Cardinality weighting can also mislead in the other direction, inflating a relation whose driving side is large but whose body is trivial. The gate is what catches that, which is another reason it cannot be deferred.

R848 asks which cut set the store should have. This item builds the only instrument that could answer it on evidence, so R848 should not reach Spec before this one has produced a result. Stated here rather than as a depends-on edge on R848, whose body is being actively worked by another session.