Public claim level: demo. Interface and override relationships make a static blast-radius review more useful and more dangerous. TraceMap can surface compiler-backed possible continuations and compatible registration context, but it keeps every such continuation at review tier because static evidence does not select the implementation used at runtime.

Why is an interface call harder than a direct call?

A direct semantic call has a compiler-selected target symbol. An interface member or virtual member can have several statically visible implementing or overriding members. Which one executes may depend on object creation, dependency-injection configuration, registration order, keyed services, decorators, factories, runtime types, branches, reflection, or deployment configuration that a repository scan does not observe.

Ignoring every possible continuation hides useful review context. Picking one “likely” implementation fabricates certainty. TraceMap instead records bounded static dispatch candidates and their gaps.

Member identity comes before candidate composition.

Compiler-backed ImplementsInterfaceMember and Overrides relationships connect exact member identities. Explicit interface implementations, overloads, generics, nested types, and same-named methods remain distinct. Rule combined.dispatch-candidate.v1 derives candidate edges only from compatible graph evidence; combined.dispatch-gap.v1 records what prevents a stronger or complete candidate set.

TraceMap refuses display-name joins and type-only member guesses. When only type-level inheritance or implementation evidence exists, it may provide weaker review context or emit a member-candidate-unavailable gap. A short name is never enough to manufacture a method edge.

Candidate state preserves strength without claiming selection.

A fully symbol-backed relationship can be a SymbolBackedCandidate. Retained candidates are downgraded to WeakerCandidate when coverage is reduced, extractor evidence is missing, or compatible DI registration supplies only context. Type-level or identity-ambiguous evidence, unsupported or open-generic registration, and missing schema, relationship, implementation, or compatible evidence produce a CandidateGap instead of inventing a candidate. High fan-out retains the bounded relationship-backed candidates and emits a separate fan-out gap.

Even the strongest candidate is still a possible static continuation. It is not a runtime target, selected implementation, actual binding, or executed call. Candidate state helps reviewers order questions; it does not cross the static-versus-runtime boundary.

Dependency-injection registration is context, not a verdict.

When statically visible DI registration evidence names a service and an implementation already proven compatible by relationship evidence, TraceMap can annotate or prioritize that candidate as registration context. Registration evidence alone cannot create a member candidate. Unproven compatibility produces a gap.

Factories, lambdas, assembly scanning, modules, custom containers, open generics, keyed or named registrations, decorators, service locators, conditional branches, registration order, and lifetime behavior remain unresolved or weaker context. The analysis does not run a container and does not choose the object a request receives.

Fan-out is bounded and visible.

One interface member can have many implementation candidates. Stable caps prevent an unbounded candidate expansion from dominating every path. When a cap is reached, truncation and omitted-candidate state remain visible. Multiple registrations or generic families remain multiple candidates rather than being collapsed into a convenient winner.

Identity-unverified, member-unavailable, implementation-unavailable, override-unavailable, registration-compatibility, schema, generic, reduced-coverage, and fan-out gaps are part of the result. A zero-candidate summary is meaningful only relative to the schemas and sources that were actually available.

The same candidate contract reaches downstream review surfaces.

Candidate edges can appear in paths, route-flow, combined reverse, change impact, combined reports, portfolio summaries, release and design review, vault export, and evidence documents. Route-flow preserves combined.route-flow.interface-bridge.v1 while retaining the underlying dispatch rule. Reports use combined.report.dispatch-candidate-summary.v1; portfolios use portfolio.context.dispatch-candidate.v1.

Vault and evidence-document projections retain their own presentation rules, including vault-export.graph.dispatch-candidate.v1 and docs-export.chunk.dispatch-candidate.v1, plus supporting edge, fact, gap, tier, coverage, and limitation metadata. A downstream layout cannot strengthen the candidate merely by repeating it.

Consumer classifications remain capped.

Candidate-dependent paths remain needs-review paths. Route-flow stays review-tier static context. Reverse paths and impact items stay at their needs-review classifications unless unknown coverage is weaker. If a path combines a candidate with a Tier 4 gap, the unknown classification wins while the candidate limitation remains visible.

This prevents a symbol-backed candidate from becoming “definite impact” as it moves through reports. It also prevents a weaker candidate from becoming an operational recommendation in a portfolio or release packet.

A plausible candidate is a question worth assigning.

Review the call-site identity, interface or override member relationship, candidate state, DI compatibility context, supporting IDs, rule IDs, evidence tiers, source spans, extractor versions, coverage, fan-out, and gaps. Then ask an owner which runtime configuration, registration rules, and construction path apply to the deployment under review.

Use the evidence model, gap guide, static-versus-runtime boundary, manager proof path, capability map, change-review use case, and the route-flow proof path when forming that question.

What static dispatch candidates do not establish.

They do not establish runtime reachability, observed execution, selected DI implementation, registration order, object lifetime, branch feasibility, production use, complete coverage, severity, required testing, release approval, or safety. A candidate-dependent path is not proof of a defect.

This public article includes no source snippet, raw SQL, configuration, credential, connection material, raw SQLite, analyzer output, local path, or private identity. No LLM, embedding, vector, or prompt classification chooses or ranks an implementation.

Keep the candidate and the uncertainty together.

Compiler identity, compatible relationship evidence, bounded DI context, stable fan-out, review-tier classifications, and explicit gaps make an interface continuation useful without pretending it was selected. The result is a better review queue, not runtime proof.

For the traversal that brings these candidates into blast-radius review, read what depends on this symbol?