Client source contains definitions, generated code, registrations, event emitters, and many unused branches. The reliable conclusion usually comes from combining several kinds of evidence rather than trusting the first matching symbol.

Best evidenceRuntime behavior, current call sites, registrations, and event firing sites.
Weak evidenceNames, comments, stale documentation, or methods without callers.
GoalProve ownership, timing, arguments, and lifetime before using a private symbol.

Evidence ladder

Evidence Reliability What it proves What it does not prove
Runtime behavior and logs Very high The active build actually executed the path. That every mode, region, route, or future build behaves the same.
Caller sites Very high Who uses a function and under which owner. That external callers may safely use it at any time.
Event firing sites Very high When an event is emitted and which arguments are passed. That listeners may mutate any nearby state.
Service registrations Very high Which subsystem owns an interface and its lifetime. That it is available during import, replay, or disconnected states.
View aliases and route registrations High How UI views are identified and opened. That a route is visible or its model is ready.
Generated resources High Which resource identifiers the build expects. That a packaged asset can be reached through a different root.
Class definitions Medium Shape, inheritance, and available methods. That the class is instantiated in the current flow.
Method names Medium-low A possible capability or historical intention. That the method is called, safe, public, or client-authoritative.
Comments and old notes Low Intent at the time they were written. That the current build still behaves that way.
Guessing from names Very low A starting point for a search. Almost nothing by itself.

Definition is not ownership

A definition proves that a symbol exists. A caller proves that it is used. A registration proves who owns it. An event firing site proves when it happens. Runtime logs prove whether the path happened in the build and context you tested.

Source tracing pattern

  1. Start from the user-visible behavior, object, or log line.
  2. Find the class or resource definition.
  3. Find constructor and registration sites.
  4. Find callers and event firing sites.
  5. Trace the value to the consumer that makes the decision.
  6. Check teardown and invalidation paths.
  7. Test the path in lobby, battle, replay, reconnect, and unsupported contexts where relevant.

Confidence language

Use precise wording in the docs. Say confirmed by current call sites when a pattern is directly verified, version-sensitive when the path depends on private names, and illustrative when a code block explains a shape rather than a drop-in implementation.