wardley-maps.sgit.ai / Method / Maps are graphs with position

Maps are graphs with position

Original contribution 7 February 2026 W5 · glossary No implementation

a Wardley Map is not a separate artifact from the graph. It is a graph with positional metadata.… The graph is primary; the map is a projection… Map queries are graph queries with positional filters.

The claim

Every Wardley map is already a graph. It has nodes — the anchor and the components — and directed edges — the dependency links. The two coordinates on each node are attributes of the node, not a separate kind of information. The picture is a rendering of the graph with those two attributes used as x and y.

Taken seriously, that has a consequence that is bigger than it first sounds: the map stops being the artefact you maintain. The graph is what you maintain. The map is one view of it, generated on demand — and it is not even the most useful view for many questions.

If the graph is primary, then a question like "what depends on something we have placed at Genesis?" is not a mapping question at all. It is a graph traversal with a filter on a node attribute. So is "which components moved right since March?", and "what is the least evolved thing on the critical path to this user need?" — which is the question most maps are drawn to answer, and which nobody can currently ask a map because a map is a PNG.

What follows if it holds

If a map is a graph……then
Position is a node attributeAlternative axes are just other attributes. Relabelling the axis becomes a rendering choice rather than a schema change — which is exactly what the corpus proposed when it said to store "axis metadata in the graph alongside everything else."
The map is a projectionTwo maps of the same system are two queries, not two documents that can disagree. The paired before/after technique becomes a diff over one graph rather than two hand-drawn pictures somebody has to keep in sync.
Maps are queryableA map diff — "a before/after showing what moved" — is computable rather than eyeballed. That is specified in the corpus as a standing requirement and has exactly one dated pair to show for it.
Evidence attaches to nodesThe doctrine assessment's discipline — every rating names the artefact it rests on — becomes available for placements too. Which is Q5, and currently no map in the corpus attaches evidence to a single placement.

And it does not exist

There is no implementation of any of this, in any of the four repositories. The reality document lists it as PROPOSED. There is no stored map graph, no positional query, no map diff, and no .owm or map-JSON export anywhere in the corpus. What exists is this argument, four rendered SVGs, and a handful of Mermaid sources — all of which are pictures with the graph implicit in the text, which is the situation the claim is complaining about.

Publishing an architectural idea as method is legitimate. Publishing it without saying it is unbuilt would not be, and it would be a particularly poor thing to do on a page arguing that maps should be checkable. So: this is design. /shipped/ says so too.

The nearest thing to a demonstration on this site is small and worth being precise about: the four maps in the gallery ship their source next to their render, so the graph is recoverable — by parsing a text file, which is not the same as querying a graph, but is the difference between a claim you can check and one you cannot. And graphs.sgit.ai holds the methodology for maps-as-graphs rendering; this page holds the argument. The two should be read together.

What would falsify it