Everything we learned about a single module: what kind of OTP citizen it is, its supervision configuration (if a supervisor), the names it registers itself under, and its outgoing coupling edges.

The supervision-tree fields (strategy, max_restarts, max_seconds, children) can come from two places, recorded in tree_source:

• :exact — read at runtime by calling Mod.init/1, the same call OTP's supervisor makes. Authoritative: resolves child lists assembled dynamically (pipes, conditionals, builder calls) that no static pass can.
• :static — recovered from the AST without running the code. Best-effort; a child spec or option assembled at runtime is reported as unresolved rather than guessed.

The coupling fields (edges, registers, unsupervised_spawns, traps_exit?) are always static — they describe who-calls-whom, which init/1 does not reveal.

Dynamic children

A DynamicSupervisor returns no children from init/1 — they are added at runtime via DynamicSupervisor.start_child/2, so the static (and even exact) tree shows the supervisor as empty. Two fields recover that runtime shape statically:

• dynamic_starts — every start_child call site found in this module, as {sup_target, child} pairs (the supervisor the call targets and the best-effort Child parsed from the spec). The call may target a supervisor defined in a different module.
• dynamic_children — resolved in Firebreak.Coupling: the dynamic children attributed to this module as their supervisor (gathered from every module's dynamic_starts whose sup_target resolves here). Best-effort.

Supervision evidence (orphan-check inputs)

Two fields feed the orphan check the evidence that a stateful process which appears in no supervisor's subtree is nonetheless meant to be (or is) started a particular way — so the finding can be relabelled or sharpened rather than left as a vague "we couldn't see it":

• child_spec_builds — modules this one builds a child spec for (Mod.child_spec(...)), scanned from the full body including quote blocks, since a child_spec call inside a __using__ macro is exactly how a base module declares that its users will supervise Mod. A module that something builds a child spec for is supervised through an indirection we can't attribute to a specific supervisor — not an orphan.
• manual_starts — {module, line} for every direct Mod.start_link(...) call site in this module (excluding the OTP behaviour helpers and self). A stateful module started this way, outside any supervisor, genuinely won't be restarted on crash — the orphan finding can name the exact call site.

Wrapper-call coupling (inter-procedural inputs)

Most apps don't litter GenServer.call(Server, …) across the codebase; they expose a public API (Server.fetch(id)) that wraps the call. A naive edge scan only sees the direct call shapes, so it misses the dependency from the API caller onto the server process. Two fields recover the first level of that:

• api_entries — this module's public functions that themselves perform a coupling call, as fun => [{kind, target, sync?}]. A self-call (GenServer.cast(__MODULE__, …) in def notify/1) is recorded with this module as the target, so a caller of notify/1 can be wired to it. OTP callbacks (handle_call, init, …) are excluded — they aren't an external API.
• api_calls — {module, fun, in_init?, line} for every remote call Mod.fun(...) this module makes. Firebreak.Coupling keeps only those that match some module's api_entries and synthesises the resulting edge onto the wrapped process.
• api_fun_calls — public_fun => [{module, fun}]: the remote calls each public function makes. This lets Firebreak.Coupling chain wrappers transitively (A calls B.f, B.f calls C.g, C.g couples to a process ⇒ A depends on it), bounded by a depth cap and cycle-guarded. Only chains through remote public-function calls, not private helpers.

Concurrency evidence

• lookup_or_create — functions performing a non-atomic registry test-and-set: a single body that both reads the registry (whereis / Registry.lookup / :global.whereis_name / registered) and creates a registration (register / start_link / start_child / spawn). {fun, line, mechanism} per such function; mechanism is :register_raises (a duplicate register crashes the loser) or :register_soft (a duplicate start returns {:error, {:already_started, _}}). The classic lookup-or-create race (Christakis & Sagonas, PADL 2010): two callers both miss the read and both create, and the loser's just-spawned process leaks as a ghost.
• opens_port — lines at which this module opens a port (Port.open / :erlang.open_port), i.e. bridges to an external OS process.
• handles_port_exit — whether any handle_info clause handles a port's termination (a head mentioning :exit_status / :EXIT / :eof). A module that opens a port but never handles its exit can't notice the external program dying (or is taken down by the linked exit).