Building Enola, Part 3: Linking Architecture Across Repositories

In this third part of the Enola architecture series, the focus is on how the system reconstructs dependencies across repositories. After the extraction of language-specific code and contracts, the cross-repository linker reads shared facts and collects evidence from protocol-specific signals to establish relationships. The linker compares route facts expressed in a uniform vocabulary, regardless of the source language or framework.

Enola supports various signals, such as HTTP calls, package imports, Kafka topic ownership, and GraphQL consumption, each contributing evidence through a common interface. Directional signals establish consumer-provider relationships, while symmetric signals identify coupling without assigning a direction. Shared symbols are treated as depends_on edges only if supported by additional signals.

The HTTP signal, for instance, indexes server routes by normalized method and path, then evaluates client routes against this index. Exact string comparison is insufficient, so Enola normalizes parameter syntax, leading slashes, and trailing path segments. Suffix matching is subject to limits to avoid assigning generic paths to arbitrary providers.

The confidence level reflects the match's strength, with verified matches having complete path alignment and probable matches depending on suffix normalization or provider disambiguation.

gRPC and Kafka also utilize specific signals for dependency reconstruction. gRPC facts use wire identity to match declared RPC identities, while Kafka topic ownership relies on topic facts and ownership conventions. The materialization of dependencies involves combining evidence from multiple signals before producing a cross-repository dependency fact, with evidence grouped by type and aggregated when applicable. Coverage records what did not resolve, distinguishing external, declared, and unresolved calls.