@condition resolves its method by name alone, so per-participant overloads on a multitable filter are inexpressible

Agreement admits: reflect the binding shape from any representative. inferBindingsByType, the -parameters warning, and ParamSource classification are representative-invariant by construction: the shape rule already forces name-and-type identity on every non-table position, and all declarations live in one class, so the -parameters state is uniform across the set.

One existing check is not representative-invariant, and this item decides it. checkConditionOverrideTargets reads the names of the table-assignable parameters to reject an argMapping entry that targets the reserved slot, while the shape rule deliberately lets table slots differ in name as well as in type (navn(Film film, ...) beside navn(Forestilling forestilling, ...) is the reporter’s own shape). Both branches reject today, but with different prose: a hit on the representative’s table-slot name renders the "slot is reserved" message, a miss falls through to checkOverrideTargets and renders "references Java parameter 'film', but method …​ has parameters [forestilling, navn]", naming a declaration the author did not write the mapping against, and which of the two fires depends on getDeclaredMethods() order, which the JVM does not specify. The rule: checkConditionOverrideTargets collects the table-slot names from every admitted declaration, so each table slot in the set is reserved and the reserved-slot message fires regardless of representative. (Requiring name identity on table positions would also close it, but it rejects the reporter’s natural per-participant naming for no gain.)

Disagreement rejects as AmbiguousMethod.

The path-step coordinate reads table-slot declared types at classification time, so its two consumers become set-aware rather than representative-blind. The admitted set’s table-slot types are carried, not only the representative’s. resolveConditionJoinTarget: where a declared target answers the question the slot stays inert and overloads pass; where resolution falls to the method signature (every filter-path site), a set whose second slots all resolve the same table behaves as today, and a set that disagrees on the resolved target rejects through the existing unresolved-target path, prose naming the disagreeing declarations (the remedy is an agreeing set or, on sites that can carry one, a declared target). validateConditionParamTables becomes per-anchor applicability, the same statement handed to R647 below: at least one declaration whose slots accept the hop’s origin and target, most-specific selection left to javac.

Everywhere else the representative’s table-slot declared type is carried on the MethodRef.Param as today and must stay emission-inert (it already is: MethodRef’s extraction accessors throw on `ParamSource.Table, ServiceMethodCallWalker skips it, and the emitters substitute coordinate-typed expressions). If some future consumer starts reading it, the representative choice becomes visible; leave a pointer to this invariant at the admission site.

AmbiguousMethod gains the rendered candidate signatures (the ServiceCatalog.renderSignature form the seam arms already carry), replacing or augmenting candidateArities. Any consumer, including the LSP, can then see the overload set the author actually wrote without parsing prose.

The @condition-path rejection (shape disagreement) renders its own guidance from that data: which positions disagree, and that overloads may differ only in their table slots (or collapse to a single Table<?> method). If path-specific wording is needed, the blessed shape is a typed discriminant threaded as an explicit input the way SeamFilter is, with message() switching on it (the InvalidSchema.CaseFoldCollision.Origin precedent); not a nullable pre-rendered hint slot.

Arm identity and lspCode() (graphitron.reflect.ambiguous-method) stay stable. Drift-guards to touch: the AmbiguousMethod sentence in typed-rejection.adoc, RejectionSeverityCoverageTest.sampleFor, and the RejectionResidueDrainageTest roster if the component set changes.

Reach of this deliverable: the improved rejection surfaces at the argument-, field-, and input-field coordinates. The path-step coordinate discards typed reflection rejections today (BuildContext.resolveConditionRef maps any failure to ConditionResolution.Unresolved() and the caller authors a generic message); restoring its rejection fidelity is a pre-existing gap, out of scope here.

docs/manual/how-to/add-custom-conditions.adoc: a new section on filtering multitable interfaces/unions, presenting both forms. The overload-set form: one declaration per participant, differing only in the table parameter; the branch emitter calls the shared name once per participant against that branch’s concretely-typed alias, and the consumer’s javac picks the declaration; a participant with no applicable declaration fails the consumer’s compile, which is the intended guard for partial coverage. The single-method form: a Table<?> parameter serves every branch; the null-probe pattern table.field(FILM.NAVN) is typed and returns null on a branch whose table lacks the column, so the section must say in the same breath that an unguarded .eq(...) on that null throws at request time and that DSL.noCondition() is the escape for a non-matching branch; instanceof narrowing (Java 16+, safe on the consumer 17 floor) recovers the whole concrete table. The same file states the Table<?> first parameter as an invariant in three places that the new section contradicts, so they are reworded in the same commit: the "Every condition method has the same shape" lead under Write the Java method, the "The first parameter is the surrounding Table<?>" bullet below it, and "The first Java parameter is always the surrounding Table<?>`" under Constraints. The file already contradicts itself: four prose signatures in its own walkthroughs type the first parameter concretely ((City table, List<String> cityNames), `(City table, String countryId, List<String> cityNames), (Film table, String filmId), tenantScoped(City table, UUID tenantId)), so the reword reconciles the whole file, presenting those as instances of the admitted concrete form rather than leaving them as exceptions to a stated invariant. The reference page also shows a concretely-typed slot in a canonical example (iRegelverksamling(Regelverksamling rs, String regelverksamligId)), so the how-to is the coordinate out of step, not the reference.

docs/manual/how-to/polymorphic-types.adoc: the multitable section gains a short "Filtering" pointer to the new section (the reporter arrived at polymorphic types first and found nothing about filters there). The pointer names @condition explicitly: that page already uses the bare word "condition" throughout in the reference-path {condition:} join sense, and the pointer must not read as more of that.

docs/manual/reference/directives/condition.adoc: state the admission rule (overloads are legal exactly when they agree on the binding shape; disagreement rejects) and cross-reference the how-to section. Its Constraints rung on multitable @nodeId override: true leaves ends "one method cannot mean both tables", which the admission rule falsifies as stated; reconcile the wording in the same commit. Whether the route-split rejection itself lifts under per-participant overloads is R676’s territory, not this item’s.

docs/manual/how-to/global-id.adoc, [#multitable-filter-inputs]: this is the one existing multitable-coordinate statement of the shape, and it leans on it ("The condition method’s table parameter is Table<?>-shaped, so a split would compile and show up only as a wrong WHERE at request time"). Under admission a concretely-typed per-participant set is legal at that leaf too, so both the shape claim and the would-compile reasoning are updated in the same commit.

Admission: an overload set agreeing modulo table slots classifies clean at the query-field and input-field coordinates, and the reflected ConditionFilter is the same either way. Home: MultiTableFilterLoweringTest, which already carries the union Occupant = Customer | Staff schema, the per-participant input-field lowering case, and the assertLowersConditionFilterPerParticipant helper the new case asserts through. Fixture: a new pair on TestConditionStub under its own name, one declaration per participant table (Customer and Staff share first_name, so the overload set is meaningful rather than synthetic). Do not overload the existing occupantsFirstName: its Table<?> declaration is the single-method pin the argument-bearing per-participant cases assert through (the no-argument field-level case pins lifterFieldCondition), and adding declarations to it would silently convert that pin into a mixed-set case.

Rejection parity: a shape-disagreeing overload set produces ReflectionError.AmbiguousMethod at both coordinates (the typed-arm assertion mirrors ServiceRootFetcherPipelineTest.serviceOnOverloadedMethod_surfacesAsTypedAmbiguousMethod). This discharges the Backlog note’s claim check: the report said the query-field coordinate accepts overloads while the input-field coordinate rejects; both route through the same resolution point, and this pair is the executable form of that reading. If writing it disproves the reading, stop and reopen to Spec.

Dispatch proof: the reporter’s scenario end-to-end: a multitable query with a filter input whose @condition names a per-participant overload set, proving each branch calls its own declaration. The execution tier is the natural home (the emitted dispatch is javac plus runtime behaviour), and the live coordinate to extend is the AddressOccupant union (Customer | Staff) developer-@condition family: MultiTableConditionFixtures (a main-source fixture class in graphitron-sakila-service) holds the Table<?> condition methods, the @condition declarations sit in the sakila-example schema, and MultiTableFilterExecutionTest already proves per-branch firing on Query.occupantsByNamePrefix by asserting a prefix match returns rows from both branches, which an implicit equality could not. A per-participant overload set on a sibling query field, asserted the same way, is the dispatch proof. The compilation tier (the same module) additionally proves a mixed set (Table<?> fallback beside a concrete declaration) compiles.

Path-step set-awareness: pipeline pair for the set-aware target resolution above: an admitted set whose second table slots resolve the same table classifies on a filter-path hop as the single method does today; a set disagreeing on the resolved target rejects through the unresolved-target path. Home: the pipeline tests around reference-path {condition:} resolution, fixtures beside ReferencePathConditionFixtures.

Honesty note: coordinate-invariance itself is enforced by reflectTableMethod being the sole @condition resolution entry over pickMethod’s single name-filter; the pipeline pair above is a regression sample over that invariant, not the invariant’s enforcer. A structural check (no second `getDeclaredMethods() name filter in main sources) is deliberately out of scope.