owulveryck/wardleytogo/wtg2

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 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`:

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.

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:

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 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:

Organization-phase alignment grid: