Ecosystem graph

The ecosystem graph is the visual surface over your org's codegraph. Where the codegraph is a database of repos, functions, calls, routes, and policy verdicts, the ecosystem graph renders that same data as interactive maps you can pan, drag, click, and trace. Same facts — a different lens.

It lives in Dashboard → Ecosystem and comes in four views. Each answers a different question.

The four views

Ecosystem map — "how do my repos fit together?"

The top-level view at /dashboard/ecosystem shows every repository in your org as a node, with typed edges between them: which service calls which, what depends on what. Edges come from cross-repo analysis — when one repo's code calls another repo's HTTP endpoint, that link shows up automatically.

Nodes are draggable and the layout is force-directed, so related repos cluster on their own. Click a repo to open a side panel where you can set its role and description, edit or confirm a detected edge, or remove the repo from the map. Hit Analyze to re-scan and let Unyform detect new connections; the result reports how many repos were scanned and how many connections are new.

You can also draw edges by hand. Toggle connection mode, click a source repo, then click a target — Unyform records the new dependency. This is useful for relationships that live outside code (a queue, a shared bucket, a contract) that static analysis can't see.

Call graph — "who calls this function?"

Click a repo node and you drill into its call graph at /dashboard/ecosystem/{repo_id}/calls. This zooms from repo-level down to function level: every function in that repo as a node, every call between them as a directed edge. It answers the questions you'd otherwise grep for — what calls authorize(), what does this handler reach into, where does this dead code path actually lead.

Request flow — "where does this endpoint go?"

Request flow traces an HTTP route through the system. It renders every route across the org alongside its handler chain and the consumer→provider edges between services, so you can follow a request from the endpoint that receives it through the handlers and services it touches — across repo boundaries.

Filter by HTTP method and by path substring to narrow to the route you care about. Click a route to highlight it and its chain. This is the view for "if I change POST /api/orders, what's downstream?"

Policy view — "what's out of compliance, and where?"

The policy view (/dashboard/ecosystem/{repo_id}/policy, also reachable via the Policy Audit tab on the call graph) takes the same function-level call graph and colors each node by its policy verdict:

• Red — the function violates at least one policy.
• Amber — the function complies with a policy.

Click any function to open a side panel listing exactly which policies it violates (with the reason for each) and which it complies with. With no function selected, the panel shows an audit summary: total violations, total matches, and a per-policy breakdown with enforcement mode. It turns "are we following our own rules?" from a spreadsheet exercise into a picture you can point at.

How it stays current

Every view reads from the codegraph, and the codegraph is rebuilt when a repo is analyzed (the Regenerate action on its blueprint). So the freshness rule is simple: analyze a repo, and its nodes, edges, routes, and policy verdicts update the next time you open the view.

flowchart LR
    A[Analyze repo] --> B[(Codegraph<br/>rebuilt)]
    B --> C[Ecosystem map]
    B --> D[Call graph]
    B --> E[Request flow]
    B --> F[Policy view]

Relationship to the codegraph

These views add no new data. The codegraph is the source of record — repos, functions, CALLS edges, routes, and policy COMPLIES/VIOLATES verdicts. The ecosystem graph is a set of Cytoscape renderings over that store, each scoped and styled to answer one question. If you can see it in a view, it's queryable in the graph; if it's in the graph, a view can draw it.