Understand dependencies across multiple repositories
Usually an architect or a platform engineer, before a contract changes
Every app's contracts read from its own code and folded into one view: the consumer in the other repository named, traced hop by hop, and told when it changes.
The problem
One repository is easy to read. The question that hurts is across them: which service calls this endpoint, who subscribes to this event, which app reads this table. The answer lives in other teams' code, and in the memory of whoever last broke it.
Drawing the arrows by hand does not help. An arrow says one system depends on another; it does not say on which endpoint, and it is wrong a month later.
How it goes
The same steps the product’s playbook walks. Each one shows the screen at that moment.
Map each repository
Each app's repository is analysed on your machine and drawn as its own app board, with a node for it on the landscape above.
Adopt each app's contracts
Each app extracts the endpoints it serves, the services it calls, the events it publishes and subscribes to, and the tables it reads and writes. The contracts are read from the code, not typed in.
Read what passes between the apps
The landscape's Aspects screen folds every app's contracts into one view: who calls whom, who publishes and who subscribes to each event, and where a subscriber's copy of an event disagrees with the publisher's.
Trace one element across the estate
Open Dependencies on any element: what depends on it, what it depends on, and the route between two, hop by hop across layers and apps. A route worth keeping is saved as an insight.
See a change arrive from another app
When another app changes a contract this one consumes, that app's diary entry names this one, and this app's hub lists the change under From other apps.
- Done
End proofDone when every app's contracts are adopted, and a change to one of them names the apps that depend on it.
Works with
- Code
- Each repository as an app board with a node on the landscape, analysed locally by the code plugin; monorepos and polyglot stacks included.
- Contracts
- Endpoints by method and path or by gRPC method, events by broker and channel, tables by name, and the clients that call them.
- Agents
- The same answer for an agent over MCP: the workspace plugin's question to the board, or your own client, with a summary, a picture and a table.
- Insights
- A route or an impact worth keeping, saved as an insight on the board with its trail.
Where it stops
- A dependency is found where the code proves it: a client that calls an endpoint, a subscriber on a channel, a reader of a table. A call made through a gateway the analysis cannot see is not drawn.
- An app whose contracts have not been adopted shows nothing, and the view says so rather than claiming there is nothing.
- Edges drawn by hand on the landscape say an app depends on another, not on which part; the contract views do not follow them.
- An event whose schema cannot be read, such as a binary blob, is listed but never compared.
Why not a diagram, or a code browser
A diagram shows
Arrows between boxes, drawn from memory, that say two systems are connected and nothing about which endpoint, which event or which table.
A code browser shows
Every caller inside this repository, and a dead end at its edge, where the other team's code begins.
ProvenMap shows
Every app's contracts read from its own code and folded into one view, so the consumer in the other repository is named, traced hop by hop, and told when the contract changes.
Walk through it
- The docs walkthrough of this job is being written.
The features behind it
Start with one system
Map a real system and see the architecture around it.
Open one repository and run the code plugin. No migration, no rollout, no diagramming.
No credit card · Analysis runs locally in your own session · Self-hosted available
See the four commands to your first board →
Or for writing on architecture that stays connected across systems.