First I would define “consume.” It may mean a handler subscribes to a topic, a generated client deserializes the schema, a data job reads a warehouse copy, or a test fixture mentions the event without any production use. These are different edges with different evidence. A single list of files matching OrderRefunded will conflate them.

Build a versioned graph with identities for repository and commit, package or artifact version, service and deployed revision, event schema and version, topic, handler symbol, configuration binding, data transformation, and owner. A static index supplies definitions and references across languages where supported. SCIP is one protocol for precise symbol indexes, and Sourcegraph's cross-repository navigation write-up shows why package identity matters across repos. Add edges from schema registry, build manifests, generated clients, deployment config, topic subscriptions, and runtime discovery. Each edge needs provenance: which file or API record, which revision, when observed, and whether it is a direct fact or an inference.

For the YAML subscriber, parse the configuration under the same environment and deployment version that resolves it. A handler symbol may be reached only because topic: order.refunded maps to a class name in a registry. Static call references will miss that. Runtime telemetry can confirm a subscriber saw a particular schema version, but no recent traffic does not prove the consumer is absent. CodeQL's call-graph guide also makes clear that static reasoning has limits around dynamic behavior such as reflection. Keep exact text search as a candidate path for configurations and strings. Use the graph to explain the relationship rather than to replace search.

The answer should say which consumers are confirmed by an active deployment binding or observed runtime subscription, which are static candidates in source configuration, and which have only lexical evidence. For each, show the path from OrderRefunded version to subscription or deserializer to handler to downstream transformation, with source links pinned to commits. Map contract changes to likely impact: adding an optional field is different from renaming a required field or changing meaning without changing type. Owners and tests are versioned evidence too. A CODEOWNERS entry is a routing clue, not proof that a team has reviewed the migration. The assistant can suggest tests, but it should not invent test coverage where only a filename exists.

Now the interviewer says the graph was built from the default branch last night, while production runs a release branch built an hour ago. I would not answer “these are the production consumers” from that graph. Join deployed artifact IDs to exact commits and schema versions, fetch missing indexes or inspect the release artifacts, then give a scoped answer. If that cannot be done in time, name the gap and provide a candidate list with a freshness stamp. Current source code and current deployment are not interchangeable.

For a release decision, I would use the assistant as a map for human owners and automated compatibility tests. It can link likely consumers, identify where evidence is missing, and propose a migration sequence. It cannot safely approve a breaking schema change merely because a graph search returned a tidy list. The next question is whether the graph is complete enough to support a negative claim, which is a much stricter standard than finding some positives.