The system graph

Find your way around the SpecsGraph system map: contexts as nodes, relationships as edges, zoom from system to requirement, and filter by subdomain type.

The map view

Every project opens on the system map. Each bounded context is a node and each relationship between two contexts is an edge. The Northwind Commerce map shows 7 contexts and 9 relationships: Identity, Billing, Catalog, Orders, Fulfilment, Notifications and Analytics, joined by edges such as Catalog to Orders and Orders to Billing.

Edges point from the upstream context to the downstream one, so the map doubles as a picture of who depends on whom. Orders sits near the middle because five of the nine edges touch it: Identity and Catalog feed it, and Billing, Fulfilment and Analytics depend on it.

Select a node to open its detail pane with the purpose, subdomain type, owning team, services and any open proposals that touch it. Select an edge to see its relationship pattern; Context relationships explains the patterns.

Zoom levels

The graph has four levels. Select a node to move down a level, and use the breadcrumb above the canvas to move back up.

Level	What you see	Northwind example
System	Every context and relationship in the project.	The 7 contexts and 9 edges
Context	One context with its services, glossary terms, actors and neighboring contexts.	Orders, with its Checkout and Order history services
Service	The requirements one service implements, grouped by state.	Checkout, with ORD-12 and ORD-13
Requirement	One requirement with its statement, scenarios, links and revisions.	ORD-12, Reserve stock for every line item at checkout

Zooming in does not cost you the big picture. The breadcrumb always shows where you are, and a requirement's links take you sideways to the terms, actors and decisions it depends on, even when those live in another context.

Map, Requirements and History tabs

Three tabs sit above the canvas. Each shows whatever is in scope at your current zoom level, in a different form.

Map draws contexts, services and relationships. It is the default tab and the place to discuss structure.
Requirements lists every requirement in scope as a table you can sort by ID, state, context or service. Use it when you care about the rules more than the shape.
History lists the revisions that changed the nodes in scope. Every revision is a Git commit you can diff and review, and you roll one back by restoring an earlier version through a proposal; see History and versions.

The sidebar lists the views that sit next to the map. They all read from the same graph, so the glossary term you open in Glossary is the same object a requirement links to on the map.

View	Use it to
System map	Explore contexts, services, requirements and relationships.
Glossary	Read and propose definitions for the terms your team uses. See Domain glossary.
Workstreams	Group related changes into tracks and tasks. See Workstreams.
Reviews	Work through open proposals and review threads. See Proposals and reviews.
Decisions	Read why past changes were made. See Decision log.

Search and filter

Search matches contexts, services, requirements, glossary terms and decisions by text. Type an ID such as ORD-12 to jump straight to that requirement, or a word such as reservation to find every term and requirement that uses it.

Filters narrow what the map highlights without changing the graph:

Subdomain type keeps core, supporting or generic contexts in focus and dims the rest. Filter Northwind to core and only Orders and Catalog stay bright.
Owning team shows the contexts one team is responsible for, which helps when you plan who reviews a change.

Contexts touched by an open proposal carry a marker on the map. While the spec/checkout-reserve proposal is in review, the Orders node shows it, and its detail pane lists ORD-12, ORD-13 and BIL-04 as proposed changes.

Edit the graph in the web app

People change the graph in the web app, and every change goes through a proposal, the same as an agent's. Start one from Reviews, or begin editing a node on the map. Your edits collect in a Draft proposal, and reviewers are not notified until you choose Request review.

To add	Where	Fields
Context	On the map, at system level.	Context fields
Relationship	On the map, drawn from the upstream context to the downstream one.	Relationship fields
Service	Inside a context, at context level.	A name
Requirement and scenarios	Inside a context or a service, or from the Requirements tab.	Anatomy of a requirement
Glossary term	In Glossary, or from a context.	Term fields
Actor	Inside a context, at context level.	Actor fields
Decision	In Decisions, or from the proposal it explains.	Decision fields

Nodes you add or change are marked on the map, and the proposal lists them as a diff. You can keep editing the draft until you request review. Proposals and reviews covers what happens next, and Workstreams shows how to link the proposal to planned work in Workstreams.

How agents read the same graph

Agents connected over MCP read the graph your team sees, not a copy or an export. A coding agent starting on a task usually works from the outside in:

get_project_overview returns the contexts, relationships, open proposals and active workstreams.
search_graph finds the requirements, terms and decisions related to the task.
get_context or get_requirement reads one node in full before the agent proposes anything.

What the agent proposes shows up on the map and in Reviews like anyone else's change, with the agent named as author. The full tool list is in the MCP tool reference.

Next steps

Bounded contexts and subdomains covers the nodes on the map.
Context relationships covers the edges between them.
Connect an agent so your coding agent can read the same graph.