wardley-maps.sgit.ai / Method / The custom-axis verdict

The custom-axis verdict

Original contribution 28 July 2026 W7 · glossary

the evolution scale doesn't necessarily need to be Genesis, custom-built, product and commodity; you can go from air gap to file to API to event-driven.

Relabelling the evolution axis is one of the most common things people try in their second month of mapping, and one of the fastest ways to produce something that looks like a Wardley map and reasons like a spreadsheet. This is the sharpest answer in the corpus to when you may do it, and it fits in one sentence.

Relabel the axis when the thing genuinely evolves; use a maturity model when the thing merely improves.

What the rule is actually testing

Wardley's four stages are not four adjectives for "how good is it". They name a process: something appears, gets built badly by people who need it, gets productised by people who see a market, and finally becomes so ubiquitous and so well-understood that it is bought without thought. The axis measures ubiquity against certainty. It is not a time axis and not an adoption curve.

So the test the rule proposes is: do your labels name stages of that same process, or do they name rungs on a ladder of quality?

Proposed axisVerdictWhy
air gap → file → API → event-driven A relabelled evolution axis Each stage is a genuinely different kind of thing, with its own economics and its own failure modes. Moving right is not "the same integration, better" — it is a different integration that became possible because the one to its left became ubiquitous. That is evolution.
no tests → some tests → good coverage → full coverage A maturity model Same activity, more of it. Nothing new becomes possible at the right-hand end that was inconceivable at the left. Draw it as a maturity model and stop calling it a map.
not-visible → fully-visible (the visibility overlay) Open Proposed in the corpus as an alternative axis. It is a property of a component relative to a user rather than a stage of its evolution — which is, notably, what the other axis of a Wardley map already measures. Unresolved: see below.
risk: not-understood → fully-accepted Open Same question. There is a real argument that risk understanding does evolve — from nobody having seen this failure to it being a line item in a standard control set — and an equally real argument that this is a maturity model wearing a map's clothes.

The six axes that were proposed and never drawn

The corpus proposes alternative axes in two places — "by treating the evolution axis as a configurable dimension rather than a fixed one, and by storing axis metadata in the graph alongside everything else" (7 February 2026), and again as visibility and risk overlays (19 June 2026). Six were named: openness, automation, documentation, test coverage, graph connectivity, plus the visibility and risk overlays.

Zero maps in the corpus use one. Not even the axis this very verdict sanctions — air gap → file → API → event-driven — was ever drawn. Six proposed axes, one explicit ruling in their favour, and no artefact. Applying the rule above to the six proposals is uncomfortable, too: test coverage and documentation look like maturity models by the verdict's own test. That is the verdict working correctly, and it is worth saying rather than quietly not mentioning.

What changes if you accept it

Two things, and the second is the useful one.

You stop arguing about whether custom axes are allowed and start arguing about whether a specific one passes the test — which is a much better argument, because it is about the domain rather than about the method.

You get a reason to reject most of them. The rule is not permissive. Applied honestly it rejects the majority of relabelled axes people propose, including several in the corpus that proposed it. A rule that only ever says yes is not doing any work.

What would falsify it

Left open

Q2: does the rule hold for the risk and visibility overlays? The corpus proposes both and the verdict does not adjudicate them. This page has argued above that visibility is the weaker of the two, since a Wardley map already has a visibility axis — but that is an argument, not a resolution.