wtg2

name	wtg2
description	Generate Wardley Maps in the WTG2 domain-specific language. Use when the user asks to create, design, or describe a Wardley Map, or asks about strategic mapping.
argument-hint	["description of the map to generate"]

WTG2 — Wardley Map Language

You are generating Wardley Maps in the WTG2 domain-specific language. Your output must be a valid .wtg2 file that can be parsed and rendered to SVG.

---

What is a Wardley Map?

A Wardley Map is a strategic tool that visualizes a value chain (vertical axis) against the evolution of each component (horizontal axis).

• Value chain (Y axis): Components at the top are directly visible to the user/customer. Components lower down are dependencies — infrastructure, platforms, data sources.
• Evolution (X axis): Components move left-to-right through four phases as they mature:
  1. Genesis (I) — Novel, poorly understood, high uncertainty
  2. Custom-built (II) — Understood but bespoke, requires expertise
  3. Product/Rental (III) — Increasingly standardized, available as products
  4. Commodity/Utility (IV) — Highly standardized, pay-per-use, invisible

Key principles:

• Anchors represent users or actors — they sit at the top of the value chain, rendered with a person icon. They have a position on the evolution axis to control horizontal placement.
• Components are connected by dependency edges forming the value chain: User -> Application -> Database -> Compute.
• Position a component on the evolution axis based on its maturity, not where you want it to be.
• Common infrastructure (cloud, networking, power) belongs in phase IV. Novel R&D belongs in phase I.

---

Strategic Concepts for Richer Maps

The Climat / Doctrine / Manoeuvre Framework

Strategic action on a Wardley Map operates at three distinct levels:

• Climat — External forces you cannot control but must read: evolution toward commodity, network effects, Red Queen dynamics, co-evolution of practices and technologies. In WTG2, these are expressed as signal annotations. The strategist does not fight the climate — they use it.
• Doctrine — Universal principles you choose to follow: organizational hygiene, contextual awareness, operational excellence, continuous evolution. In WTG2, the doctrine: metadata field declares the organization's maturity phase.
• Manoeuvre — Deliberate, context-dependent actions to change your position on the map. In WTG2, these are expressed as gameplay annotations. A manoeuvre's value depends entirely on context — the same move can be brilliant in one situation and suicidal in another.

Manoeuvre vs Tactique — a critical distinction: A manoeuvre repositions you on the map (changes the terrain). A tactique optimizes execution within the current context (does the same thing better). Refactoring code is a tactic; replacing a legacy system via strangler-fig is a manoeuvre. Only manoeuvres belong as gameplay annotations — tactics are operational, not strategic.

Gameplays (Strategic Manoeuvres)

A gameplay is a deliberate manoeuvre to modify your position on the map. Annotate gameplays on the component that is the target of the manoeuvre.

Gameplay	Description	Typical context
ILC	Innovate-Leverage-Commoditize: 3 phases — (1) Innovate: provide base infrastructure, externalize innovation risk to the ecosystem; (2) Leverage: use a Sensing Engine to detect weak signals of success in ecosystem usage; (3) Commoditize: absorb validated innovations into your own offering. Self-perpetuating growth machine.	Platform with ecosystem (AWS, App Store)
open-source	Commoditize a layer to capture value in an adjacent layer. 3 uses — attack (destroy a competitor's rent by open-sourcing their differentiator), defense (prevent a third party from commoditizing your layer), standardization (establish the de facto standard).	Competitor with proprietary rent
land-grab	Sacrifice profitability for rapid market share to become the de facto standard before the competition. First to reach critical mass becomes difficult to dislodge.	New market with strong network effects
embrace-extend	3 phases — (1) Embrace: adopt an open standard; (2) Extend: add proprietary extensions that create dependency; (3) Extinguish: users depend on extensions, the open standard is abandoned de facto.	Standard you want to control
tower-moat	Erect barriers: patents, lock-in, closed protocols. Wardley's critique: fundamentally temporary in an evolutionary climate — moats dry up as components evolve toward commodity. A harvesting tactic, not a long-term strategy.	Protecting an existing rent
FUD	PID (Peur, Incertitude, Doute): deliberately spread fear, uncertainty, and doubt to slow adoption of a competitor's offering. Double-edged — can damage your reputation if discovered.	Competitor gaining traction
strangler-fig	Progressively replace a legacy system. 3 steps — (1) identify components to commoditize; (2) isolate the core of value; (3) replace component by component without service interruption. Opposed to Big Bang rewrites. The map helps plan replacement component by component by visualizing dependencies.	Legacy system blocking evolution
signal-distortion	Mislead competitors about strategic intent. Variant: techdrop — release a technology to distract competitors into investing in the wrong direction.	Competitive misdirection
due-diligence	Strategic due diligence: evaluate M&A targets by mapping their value chain. Detects anomalies (Custom components that should be Commodity), assesses EVT alignment, and reveals real synergies vs. paper synergies.	Merger/acquisition, asset evaluation
two-sided-market	Create an obligatory passage point via cross-sided network effects: more producers attract more consumers, and vice versa. The virtuous circle creates substantial barriers to entry once critical mass is reached.	Platform connecting producers and consumers

gameplay ILC on Platform API
gameplay open-source "Commoditize compute to capture AI layer" on Cloud Infra
gameplay strangler-fig on Legacy CRM
gameplay due-diligence "Assess strategic coherence before acquisition" on Target Company
gameplay two-sided-market on Marketplace

Flow Analysis

A map is not just a snapshot — value flows through it. Two types of flow reveal invisible dynamics:

1. Evolutionary flow — The gravitational pull from left to right (Genesis → Commodity). Every component tends toward commoditization. Movement arrows (>>) make this explicit for components in active transition.
2. Capital flow — Bidirectional exchanges along dependency edges: money, data, knowledge, labor. Unlike evolutionary flow, capital flows in both directions along the value chain.

Flow anomalies to flag with warning or note:

Anomaly	Symptom	WTG2 annotation
One-way flow	A dependency where value only flows in one direction (e.g., data goes up but no value returns)	warning "One-way data flow — no value returned" on Component
Bottleneck	A single component through which all flows pass — a structural SPOF	warning "SPOF — all value chains pass through this component" on Component
Value leak	Value created internally is captured by an external component (e.g., a buy component in phase III extracting rent)	warning "Value leak — vendor captures margin on our differentiation" on Component

Five Capitals (Asset Classification)

Components represent different types of organizational capital. The asset field classifies the nature of the asset (orthogonal to type which classifies sourcing).

Every asset has a dual nature: it provides a strategic capability (what it enables) while simultaneously generating a carrying cost (inertia — what it prevents from changing). A proprietary database is both a differentiator and a migration burden. The asset field captures the capability side; cost: and inertia (!) capture the carrying cost side.

The sourcing type (build/buy/outsource) also carries strategic implications: build creates CAPEX (capital expenditure — sunk cost, high inertia), while buy/outsource shift toward OPEX (operational expenditure — flexible, lower inertia). Moving from CAPEX to OPEX is itself a strategic manoeuvre to increase financial liquidity.

Asset type	Description	Example
tech	Technological capital: code, infrastructure, patents	A routing engine, a data pipeline
financial	Financial capital: revenue models, pricing power	A billing system, a licensing model
human	Human capital: expertise, skills, tacit knowledge	An ML engineering team, domain experts
relational	Relational capital: partnerships, brand, contracts	A partner API, a brand, a patent portfolio
social	Social/environmental capital: community, regulatory	Open-source community, regulatory compliance

AI Team : II.3 {
    type: build
    asset: human
    note: "12 ML engineers, hard to replace"
}

Qualified Inertia

Inertia is not a defect — it is a mechanical consequence of past success. It is proportional to mass, where mass = past investments × systemic dependencies × professional identities. The more successful a component has been, the harder it is to change.

Phase transitions (e.g., Custom → Product) require latent heat — invisible energy to break existing bonds: retraining experts, migrating dependencies, accepting accounting losses. This cost is invisible on a balance sheet but real on the map.

Inertia can also be reversed as momentum: when deliberately built through repeated strategic iterations, accumulated capability propels the organization forward rather than holding it back. The difference between inertia and momentum lies in intention and awareness.

Inertia is not just a severity level — it has a nature. The 5 forms are:

Kind	Meaning	Symptom
tech	Technology lock-in, infrastructure debt	"We've always used Java"
financial	Sunk costs, established revenue models	"We've invested 5M in this"
human	Skills gap, identity threat, expertise obsolescence	"Our team doesn't know cloud-native"
relational	Contractual obligations, partner dependencies	"We have a 3-year vendor contract"
social	Cultural resistance, regulatory inertia	"That's not how we do things here"

Component : II.7 !!(tech,human) >> III.5    // tech and human inertia
Component : II.7 !(financial) >> III.5      // financial inertia only
Component : II.7 !!! >> III.5              // unqualified (backward-compatible)

Climatic Patterns (Extended Signals)

Beyond accelerating/stagnating/declining, mark climatic forces that explain why components evolve:

Signal	Meaning
co-evolution	Technology and practice evolving together (e.g., containers + DevOps)
red-queen	Must evolve constantly just to maintain position
commoditization	Gravitational pull toward utility/commodity
network-effects	Value increases with number of users/participants
economies-of-scale	Cost advantage from volume, favoring consolidation

signal co-evolution on DevOps Practices
signal commoditization on Cloud Infrastructure
signal network-effects on Social Platform

EVT/PST Team Alignment

The Explorer-Villager-Town-planner model aligns team types to evolution phases. Use team: in groups to declare this alignment:

Team type	Evolution phase	Mindset
explorer / pioneer	Genesis (I)	Discovery, intuition, high failure tolerance
settler / villager	Custom-Product (II-III)	Productization, standards, analysis
town-planner	Commodity (IV)	Industrialization, cost optimization, experience-driven

Organization-phase alignment grid:

Evolution phase	Team profile	Organizational role
Genesis (I)	Explorers / Commandos	R&D, skunkworks, innovation labs
Custom (II)	Artisans / Villagers	Engineering teams, consultants
Product (III)	Product managers / Settlers	Product teams, solution architects
Commodity (IV)	Ops/SRE / Town Planners	Platform teams, infrastructure

Formal transfer principle: Explorers create, Villagers productize, Town Planners industrialize. The fatal error is assigning the wrong profile to a phase — e.g., asking Town Planners to innovate (they optimize) or Explorers to run production (they break things). Transitions between profiles generate friction; transfers must be orchestrated, not assumed.

A mismatch between team type and component evolution phase is a strategic signal worth highlighting.

group R&D Team {
    team: explorer
    Quantum Algo
}

Carrying Cost

The book emphasizes that 70-80% of IT budgets go to maintenance. Use cost: to annotate financial context:

Legacy CRM : III.2 {
    type: buy
    cost: "850k/year, 80% maintenance"
}

Doctrine Violations

Recurrent anti-patterns detectable on a map. When generating a strategic map, flag these with warning annotations:

Violation	Map symptom	What to flag
NIH (Not Invented Here)	Component marked build in phase III-IV when market alternatives exist	warning "NIH — standard solutions exist at this evolution stage"
No differentiation	All components in phase III-IV, zero investment in I-II	warning "No differentiation — entire value chain is commodity"
Dispersion	Many components in phase I without critical mass in any	warning "Dispersion — too many bets, insufficient focus"
Single method	Same approach applied uniformly regardless of evolution phase	note "Agile/Six Sigma may not suit all phases equally"
Strategy theatre	Map has no question:, no gameplay, no movement (>>)	A map without a question is a ritual, not strategy

Strategic Cycle

Strategy is not an event — it is a continuous discipline following the OODA loop (Observe → Orient → Decide → Act). Each iteration reduces friction, transforming the laborious effort of a beginner into the fluidity of an experienced practitioner.

The Value Flywheel Effect structures this cycle in 4 phases:

1. Clarity of Purpose — understand the user need (anchors, value chain)
2. Challenge and Landscape — map the terrain (components, evolution, climate)
3. Next Best Actions — decide and act (gameplays, manoeuvres)
4. Long Term Value — harvest value and reinvest (momentum builds)

Each iteration feeds the next: capabilities developed in phase 1 facilitate phase 2; patterns recognized in phase 2 accelerate phase 3. The flywheel spins faster with practice — the velocity of adaptation (how fast you complete the cycle) becomes a competitive advantage in itself.

---

Document Structure

A WTG2 document follows this canonical order:

1. Metadata       (title, date, author, scope, question, doctrine)
2. Configuration   (stages, legend)
3. Nodes           (anchors, components, submaps, pipelines)
4. Value chain     (edges / dependencies)
5. Groups          (visual organization)
6. Annotations     (notes, warnings, signals, gameplays, focus)

All sections are optional. Comments can appear anywhere.

---

Syntax Reference

Comments

// Single-line comment
/* Block comment */

Metadata

title: My Wardley Map
date: 2026-01-15
author: Strategy Team
scope: B2C mobile platform, European market
question: "Where should we invest to differentiate?"

All metadata fields are optional. The question value should be quoted.

doctrine: context

The doctrine field indicates organizational maturity phase: hygiene, context, excellence, or evolution.

Stage Labels

Override the default evolution axis labels (default: I, II, III, IV):

stages: Genesis, Custom, Product, Commodity

Exactly four labels, comma-separated.

Legend

Display an auto-generated legend panel to the right of the map. The legend shows only the element types actually present in the map (component types, edges, signals, gameplays, groups, etc.).

legend

The keyword is standalone — no configuration needed. The SVG viewBox is automatically widened to accommodate the legend without distorting the map.

Nodes

There are three node kinds:

Keyword	Purpose
anchor	User or actor — rendered with a person icon, always at the top of the map. Has a position on the evolution axis to control horizontal placement.
component	Regular component (keyword is optional)
submap	Encapsulated sub-map shown as a component

Shorthand declaration (single line)

[kind] <name> : <evolution> [(<type>)] [@<visibility>]

The component keyword is optional — a bare name with a position is treated as a component.

Examples:

anchor User
anchor User : III.5
anchor User : II.3 >> III.5
Application : III.5
Database : III.8 (buy)
Infrastructure : IV.3 (buy) @0.2
submap Payment System : III.6

Anchors have a position on the evolution axis that controls their horizontal placement on the map. They are always rendered at the top of the map (vertical position is fixed) with a person icon. Anchors can also have movement (>>) to show a shift in user positioning.

Block declaration (multi-line)

<name> : <evolution> {
  type: build
  color: #3498DB
  note: "Our key differentiator"
}

Block config fields:

Field	Values
type	build, buy, outsource
asset	tech, financial, human, relational, social
evolution	Evolution expression (e.g., II.7 !! >> III.5)
color	#RRGGBB or #RGB
visibility	0.0 (bottom) to 1.0 (top)
cost	Free-text cost annotation
note	Quoted text description

Evolution Positioning

The horizontal position uses roman numerals with an optional decimal subdivision:

<roman>.<digit>

Where <roman> is I, II, III, or IV, and <digit> is 0-9.

Each phase spans 25% of the axis. The decimal subdivides within the phase (0 = start, 9 = end). Without a decimal, the center of the phase is used.

Position mapping to 0-100 coordinate:

Position	Coordinate	Meaning
I.0	0	Start of Genesis
I.5	12	Middle of Genesis
I.9	22	End of Genesis
II.0	25	Start of Custom
II.5	37	Middle of Custom
II.9	47	End of Custom
III.0	50	Start of Product
III.5	62	Middle of Product
III.9	72	End of Product
IV.0	75	Start of Commodity
IV.5	87	Middle of Commodity
IV.9	97	End of Commodity

Formula: floor((base + digit/10 * 0.25) * 100) where base is I=0.00, II=0.25, III=0.50, IV=0.75.

Evolution Movement

Show that a component is evolving from one position to another:

Component : II.7 >> III.5

This renders an arrow from position II.7 to III.5 on the map.

Inertia

Mark resistance to evolution with ! (1-3 levels), optionally qualified by kind:

Component : II.7 ! >> III.5               // moderate inertia
Component : II.7 !! >> III.5              // strong inertia
Component : II.7 !!! >> III.5             // blocking inertia
Component : II.7 !!(tech,human) >> III.5  // qualified: tech + human inertia
Component : II.7 !(financial) >> III.5    // qualified: financial inertia

Inertia appears between the current position and the >> movement operator. The optional (kind,...) qualifier specifies the nature of the resistance (see "Qualified Inertia" above).

Visibility Override

By default, vertical positioning is computed automatically from the dependency graph. Override it with @:

Component : III.5 @0.9    // near top of map
Component : III.5 @0.1    // near bottom of map

Values range from 0.0 (bottom) to 1.0 (top).

Edges (Value Chain)

Edges define dependencies between components.

A -> B                          // A depends on B
A <-> B                         // bidirectional relationship
A -[label text]-> B             // annotated dependency
A <-[label text]-> B            // annotated bidirectional

All four forms are supported. Annotated bidirectional edges combine <-> with [label].

Edges can be chained:

User -> App -> API -> Database -> Cloud

This creates four edges: User->App, App->API, API->Database, Database->Cloud.

Pipeline member references

Target a specific member within a pipeline:

Component -> Pipeline:Member

Pipelines

A pipeline shows multiple implementations of a component at different evolution stages:

pipeline <component-name> {
  Implementation A : III.5
  Implementation B : II.3
  Implementation C : I.2
}

Rules:

• The pipeline name must match an already-declared component.
• Members are positioned on the evolution axis only; their vertical position is derived from the parent component.
• The pipeline's horizontal span covers from its leftmost to rightmost member.

Groups

Visually group components (purely visual, no scoping). Optionally specify team type for EVT/PST alignment:

group Team Name {
  Component A
  Component B
  Component C
}

group R&D Team {
  team: explorer
  color: #E74C3C
  Quantum Algo
  Experimental Cache
}

Members must reference existing component names.

Group directives:

Directive	Values
color:	#RRGGBB or #RGB
team:	explorer, settler, town-planner, pioneer, villager

Annotations

note "Description text" on Component Name
warning "Risk description" on Component Name

Signals

Mark market dynamics and climatic patterns on a component:

signal accelerating on Component Name    // moving rapidly toward commodity
signal stagnating on Component Name      // evolution has plateaued
signal declining on Component Name       // regression in relevance
signal co-evolution on Component Name    // technology-practice mutual reinforcement
signal red-queen on Component Name       // must evolve to maintain position
signal commoditization on Component Name // gravitational pull toward utility
signal network-effects on Component Name // value grows with adoption
signal economies-of-scale on Component   // cost advantage from volume

Gameplays

Annotate strategic maneuvers on a component:

gameplay ILC on Platform API
gameplay open-source "Commoditize to capture adjacent value" on Database Engine
gameplay strangler-fig on Legacy System
gameplay land-grab on New Market

Gameplay types: ILC, open-source, land-grab, embrace-extend, tower-moat, FUD, strangler-fig, signal-distortion, due-diligence, two-sided-market.

The quoted description is optional and provides strategic context.

Focus

The focus keyword highlights a component and all its descendants in the value chain. Elements outside the focus are rendered with reduced opacity.

focus Recommendation Engine

Multiple focus declarations can be combined — their subtrees are merged:

focus Recommendation Engine
focus Real-Time Personalisation

Focus is useful for presenting a specific part of the map during a discussion or presentation.

---

Identifier Rules

Identifiers (component names, group names, etc.):

• Start with a letter or digit
• May contain letters, digits, ., -, ', _, and spaces
• Spaces are allowed inside identifiers (e.g., Application Mobile)
• Cannot be a reserved keyword used alone

Reserved keywords: anchor, component, submap, pipeline, group, note, warning, signal, gameplay, legend, focus, title, date, author, scope, question, stages, doctrine, evolution, type, asset, color, visibility, cost, team, build, buy, outsource, accelerating, stagnating, declining, co-evolution, red-queen, commoditization, network-effects, economies-of-scale, ILC, open-source, land-grab, embrace-extend, tower-moat, FUD, strangler-fig, signal-distortion, due-diligence, two-sided-market, explorer, settler, town-planner, pioneer, villager, tech, financial, human, relational, social, on, hygiene, context, excellence

---

Semantic Rules

1. Every node referenced in an edge, annotation, signal, or pipeline must be declared with a position somewhere in the document.
2. Pipeline names must match a declared component.
3. Pipelines cannot be nested.
4. Groups do not create namespaces — components remain global.
5. Anchors do not need an evolution position (they are placed at the top automatically).
6. The dependency graph must be acyclic (no circular dependencies).

---

Complete Example

// Wardley Map — GPS Navigation Platform

title: Navigation Platform — 2026 Strategy
date: 2026-01-15
author: Product Strategy Cell
scope: B2C mobile app, European market
question: "Where to invest to differentiate against Google Maps?"
doctrine: context

stages: Genesis, Custom, Product, Commodity
legend

// Anchors
anchor Driver
anchor Local Authority

// Visible layer
Application : III.5
Displayed Route : III.2
Real-Time Traffic Alerts : II.3

// Core engine with qualified inertia and asset/cost
Route Calculation Engine : II.7 !!(tech,human) >> III.5 {
  type: build
  asset: tech
  color: #3498DB
  cost: "1.2M/year, 12 FTEs"
  note: "Key differentiator"
}

// Pipeline: the engine exists in multiple forms
pipeline Route Calculation Engine {
  Classic Dijkstra : III.5
  Predictive AI : II.3
  Quantum Algo : I.2
}

Cartographic Data Model : III.1 (buy)
B2G Partner API : II.1 {
  asset: relational
}

// Infrastructure
OSM Data : III.8 (buy)
Real-Time Sensor Feed : I.8 !(relational) >> II.5 {
  type: build
  asset: tech
  color: #E67E22
  cost: "300k/year"
  note: "Partnership in progress with Waze/TomTom"
}
Cloud Infrastructure : IV.3 (buy) {
  cost: "500k/year, rising 30%"
}
CDN : IV.5 (buy)
Mobile Network : IV.7 (outsource)

submap Payment System : III.6

// Value chain
Driver -> Application -> Displayed Route -> Route Calculation Engine
Application -> Real-Time Traffic Alerts -> Real-Time Sensor Feed
Route Calculation Engine -> Cartographic Data Model -> OSM Data
Route Calculation Engine -> Cloud Infrastructure
Real-Time Sensor Feed -> Cloud Infrastructure

Local Authority -> B2G Partner API -[Open Data, annual license]-> Cartographic Data Model
Local Authority -> Real-Time Traffic Alerts

Application -> CDN -> Cloud Infrastructure
Cloud Infrastructure -> Mobile Network
Application -> Payment System

// Link to specific pipeline member
Real-Time Traffic Alerts -> Route Calculation Engine:Predictive AI

// Groups with team types
group Core Navigation Team {
  team: settler
  Route Calculation Engine
  Predictive AI
  Cartographic Data Model
}

group Platform Team {
  team: town-planner
  Cloud Infrastructure
  CDN
  Payment System
}

group Data Team {
  team: explorer
  Real-Time Sensor Feed
  OSM Data
  Quantum Algo
}

// Annotations
warning "SPOF — no fallback if unavailable" on Route Calculation Engine
warning "Vendor lock-in AWS, cost rising 30%/year" on Cloud Infrastructure
warning "Critical dependency on single supplier" on OSM Data

note "Candidate for outsourcing Q4 2026" on Payment System
note "Partnership signed with 12 cities" on B2G Partner API
note "R&D budget 400k, horizon 2028" on Quantum Algo

// Market signals and climatic patterns
signal accelerating on Predictive AI
signal co-evolution on Real-Time Sensor Feed
signal stagnating on Classic Dijkstra
signal commoditization on Cloud Infrastructure
signal declining on OSM Data
signal red-queen on Application

// Gameplays
gameplay strangler-fig "Replace Classic Dijkstra with Predictive AI" on Route Calculation Engine
gameplay open-source "Commoditize mapping data to reduce dependency" on OSM Data
gameplay ILC on B2G Partner API

// Focus
focus Route Calculation Engine

---

Generation Guidelines

When generating a WTG2 map:

1. Start with the user need. Identify the anchor(s) — who is the user/customer? Place them as anchor declarations.

2. Build the value chain top-down. Ask: "What does the user need?" Then for each component: "What does this component need?" Continue until you reach infrastructure.

3. Position evolution realistically:

   • Phase I (Genesis): Research, experiments, novel tech nobody else has
   • Phase II (Custom): Built in-house, understood but bespoke
   • Phase III (Product): Available as products/services, increasingly standardized
   • Phase IV (Commodity): Utilities, pay-per-use, ubiquitous (cloud, electricity, internet)

4. Use (buy) and (outsource) for components you consume rather than build. Leave untyped or use (build) for in-house work.

5. Mark evolution movement (>>) only for components actively transitioning. Add inertia (!, !!, !!!) when organizational or market resistance slows the transition.

6. Use pipelines when a component exists in multiple forms at different evolution stages (e.g., legacy vs. modern implementations).

7. Add annotations sparingly. Use warning for risks and note for strategic observations. Use signal to mark market dynamics.

8. Group by team or domain to show organizational ownership.

9. Keep identifiers readable. Use natural language names with spaces, not camelCase or snake_case.

10. Follow the canonical section order: metadata, stages/legend, nodes, edges, groups, annotations.

11. Annotate gameplays when the map represents a competitive strategy. Ask: "What maneuver is being applied to which component?" Use gameplay to make strategic intent explicit.

12. Classify asset types for components where the strategic value is non-obvious. A database is tech capital; a brand is relational capital; a specialized team is human capital.

13. Qualify inertia beyond severity. When marking !!, ask: "Is this technical debt (tech), sunk cost (financial), skills gap (human), contractual lock-in (relational), or cultural resistance (social)?"

14. Apply climatic patterns to explain evolutionary forces. Components in phase III with many dependents should likely have signal commoditization. Use signal co-evolution when a practice and technology evolve together.

15. Align teams to evolution phases. When defining groups with team:, verify that explorer teams own Genesis-phase components and town-planner teams own Commodity-phase components. Highlight mismatches as strategic risks.

16. Annotate cost for components consuming significant budget. This enables run/change ratio analysis across the value chain. Use cost: in block config.

17. Respect the Extremistan/Mediocristan divide. Phases I-II (Genesis, Custom) operate in Extremistan: power laws, unpredictable ROI, winner-takes-all dynamics. Phases III-IV (Product, Commodity) operate in Mediocristan: normal distributions, predictable metrics, Six Sigma applicable. Do not apply the same KPIs or risk models uniformly across all phases — a startup metric (burn rate) does not apply to infrastructure, and an SLA does not apply to R&D.

18. Flag doctrine violations. Check for NIH (building what could be bought in phase III-IV), lack of differentiation (nothing in phase I-II), dispersion (too many phase I bets), and strategy theatre (map without a question or gameplays).

---

Strategic Completeness Checklist

Before finalizing a map, verify:

1. Every anchor has at least one dependency chain to infrastructure
2. Components in Genesis (I) have movement (>>) or a signal
3. Inertia is qualified by kind when the nature of resistance is known
4. Groups carrying team types align with component evolution phases
5. At least one gameplay is identified if the map is strategic
6. Warnings exist for SPOF, vendor lock-in, or single-supplier risks
7. Cost annotations exist for high-budget components
8. Signals reflect observed market dynamics, not speculation
9. The question: metadata is defined — a map without a question is strategy theatre
10. At least one component has movement (>>) — a static map is not strategic
11. Components marked build in phase III-IV are justified (otherwise: NIH violation)
12. Capital flows along edges are bidirectional — one-way flows deserve a warning
13. The map contains at least one surprise — if nothing contradicts your assumptions, you have not looked closely enough (test de la surprise)