System graph & map

The contracts, package dependencies, and co-changes repowise extracts are each a flat list. The workspace layer folds them into a single normalized system graph, the one structure every cross-repo view reads. It is rebuilt automatically on every repowise update --workspace and persisted to .repowise-workspace/system_graph.json.

Nodes are services, not repos

A monorepo with three detected service boundaries (a package.json, go.mod, or Cargo.toml sub-directory) shows three nodes. The repo is a grouping attribute on each node. A repo with no sub-boundary collapses to a single repo-root node. Each node carries its provider/consumer counts, the contract types it participates in, and flags for orphan or isolated services.

Edges are typed and honest

Every edge carries:

• a kind, one of http, grpc, event, package, or co_change;
• a match_type, one of exact, candidate, manual, or inferred;
• a confidence and a weight (how many underlying contracts, deps, or co-changes it aggregates);
• contract_refs back-pointers, so any view can drill from an edge to its evidence.

Edge direction is uniform: source depends on or calls target. A consumer points to the provider it calls; a dependent repo points to the repo it imports. Structural edges (contracts, package deps) are flagged distinctly from behavioral co-change edges, so repowise never conflates "these change together" with "these call each other".

Fetch the graph over REST with GET /api/workspace/system-graph, or explore it visually in the Live System Map.

Live System Map

The web UI renders the system graph as an always-current diagram at /workspace/system-map. It is the visual counterpart to the REST endpoint, the same nodes and edges laid out and explorable, never a hand-drawn picture.

• Service nodes, coloured by category (service, frontend, worker, library, external), with a health ring rolled up from the owning repo and small flags for orphan or isolated services.
• Typed edges distinguished by kind (colour and glyph) and by match_type (solid for exact/manual, dashed for candidate, dotted for inferred co-change). Behavioral co-change edges read differently from structural contract and dependency edges.
• Filters to toggle each edge kind on or off, and a service ↔ repo switch that collapses a monorepo's services into one node per repository.
• Drill-down: click a service to inspect its providers/consumers and connected services; click an edge to see its match type, confidence, weight, and the underlying contract evidence, with a jump to the Contracts view.
• A legend explaining the edge colours, dash patterns, and the health scale.

The map appears once the workspace has at least two indexed repositories with detected relationships. It shows honest empty states otherwise.

Extraction diagnostics

When the cross-repo link count looks low, diagnostics explain why. Computed alongside contract matching, they report, per repo and contract type, how many providers and consumers were found, which consumers went unmatched (and why), and which providers have no consumer at all.

repowise workspace diagnostics            # human-readable report
repowise workspace diagnostics --json     # raw JSON
repowise workspace diagnostics --repo api # limit to one repo

The report covers:

• Provider / consumer counts per repo, broken down by contract type.
• Unmatched consumers, grouped by reason:
  • no_provider, no provider anywhere declares a matching route/service/topic.
  • internal_only, the only matching provider is in the same repo and service, so the call is intra-service and intentionally not surfaced as a cross-repo link.
  • unlinked, a cross-service provider with a matching id exists, but no link formed (a candidate worth inspecting).
• Orphan providers, endpoints declared but never consumed by any repo.
• Weak links, matched links below the confidence threshold.

The same data is available over REST at GET /api/workspace/diagnostics and is embedded in the system graph artifact's diagnostics block.