The walkthrough
How the living map becomes architecture intelligence.
ProvenMap gives teams a shared, current model of their systems. Use it to understand the landscape together, decide with cross-system impact visible, and hand that shared context to the coding agents that build the change.
01
Understand
Map the systems, sources, and relationships in scope.
02
Decide
Answer architecture questions with cross-system impact visible.
03
Build
Hand compiled skills, work items, and contracts to the coding agents — change an app, or author a new one.
04
Prove
The next sync marks matching work items proven against the code.
01 · Understand
Build a shared model of the systems in play.
Start with the system landscape: live applications, planned systems, third-party services, and the boundaries between them. Connect the sources behind each system, and put the analysis on a schedule, so the model stays current as those sources change. It becomes a ubiquitous language for the domain — drawn rather than written — that the people analysing and the people building both point at.
- 01Model> Name the systems, domains, and relationships.
- 02Ground> Attach the sources behind each part of the model.
- 03Navigate> Move from the landscape into the required level of detail.
- 04Refresh> Refresh on a schedule you set, and surface what went stale.
Your sources
/configure # connect
/analyze # bind source
/sync # update the board
+24 nodes · +41 edges
→ runs locally — your repository is never uploaded
Layers
Move from the cross-system landscape into a system, domain, service, or component when the decision calls for more detail.
“How do our systems connect?”
“What's inside the billing service?”
“What does this component do?”
One shared, layered architecture model — grounded in sources, current enough to trust, navigable from landscape to component — and the visual language everyone works in.
02 · Decide
See the impact. Define the change in context.
Before changing how customer orders are handled, the team asks which systems will be affected. ProvenMap returns a focused board so product, architecture, and engineering can agree the scope and sequence from the same context.
“What else changes if we simplify customer ordering?”
Board generated
The affected path across the systems involved — each relationship explained.
- 01Ask> Frame the proposed change as a question.
- 02Trace> Follow what depends on what, and the route between two systems.
- 03Review> See the answer as a focused architecture board.
- 04Decide> Set the scope, sequence, and intended outcome.
The team makes the decision with cross-system impact visible, then records the reasoning on the affected systems.
03–04 · Build and prove
The understanding is solved. Hand it to the coding agents.
Once an app board is understood, its context travels back into the repo: compiled skills that govern how your coding agents work, released work items anchored to real board elements, and the data and API contracts between systems. In a Claude Code, Codex, or Cursor session that context changes an existing app — or authors a new one from an empty repo.
The contextmap · work items · compiled skills
your coding agentClaude Code · Codex · Cursor
Existing app · changed
New app · built from empty
Analysis and engineering stop being a handoff: the person who understood the system and the person who ships the change speak the same visual language — title optional — and the agents build from 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.