Lmapping

The notation, in full

The whole roadmap language, in one page.

Lmapping encodes a roadmap on two independent axes. Status is a colour. Phase is a name and a position. A closed set of statuses, a short grammar of modifiers and arrows, and a few rules for how time constrains a card. That is the entire system, and a human and a machine read it the same way.

Axis 1

Status is the colour

A light fill with a stronger border of the same hue. A colour means the same thing anywhere on the board, so nobody re-learns a legend. Active equals Development (yellow) and Release equals Done (green) share a colour on purpose, so phase and status line up.

Demand

A request, raised. Not on the roadmap yet.

#c593ff · #8a26ff

Intend

Adopted as an intention. Positioned by quarter, not locked.

#e5c7ff · #ca8fff

Commit

Committed to a target month. The lock. Not started.

#ffc0bc · #ff8178

Solution

Work begins here. The solution is defined.

#80d8f8 · #00b0f0

Specifications

The first release is fully specified.

#ceeaff · #b3dafb

Development

In build. The delivery zone. Equals Active.

#ffea8c · #ffd418

QA

In verification. A failed check returns it to build.

#a1e5b8 · #599c70

Done / Release

Delivered and released.

#c9e8a8 · #92d050
BlockedBlocked is a solid red fill (#ff2e00), white text. It is the only fully-red status, and it is not the same as Attention.

Axis 2

Phase is the position

The five delivery milestones, read left to right. In detail an active card takes the colour of its own phase, not a generic yellow. Renamed for clarity: Design became Solution, Spec became Specifications, Dev became Development.

Solution
Specifications
Development
QA
Release

A card's lifecycle

One cycle, one colour at a time

demand
intend
commit
solution
Specs
Dev
qa
Done

Before the work: Demand, then Intend, then Commit (the lock). In work: the card takes the colour of its phase, from Solution to QA. Finished: Done. Commit shows only before the start, because an active card is necessarily committed.

Modifiers

Modifiers sit on any card

Attention

An orange fill (#ff8a00), or a thick red border. Either form flags a card while it keeps its status colour.

Blocked

A solid red fill (#ff2e00), white text. The only fully-red status. Keep it apart from Attention.

Corner tag

A small label in a card's corner flags a cross-team dependency, or an internal-only track that sits on the public board but outside the delivery scope.

Reading the roadmap

Two readings of the same project

Collapsed

One card is the release, at its target month, at the release's status. This is the published, readable view.

Column = September (target month)

Checkout v2Release · Intend

Expanded

The milestone chain, laid out in time. This is the real micro-management. Time constrains the status: the active front is Development, so Solution and Specifications before it read Done, and QA and Release after it can only be Intend, Commit at best.

Checkout v2Solution
Checkout v2Specifications
Checkout v2Development
Checkout v2QA
Checkout v2Release

Grouping

The release cartouche

Search v2 + filters
Wallet pay
New onboarding
Widgets
App release

A box grouping several distinct feature cards that ship together as one release. It carries the union of their subjects and wears the release name; the enclosed cards keep their own status colours. Do not confuse it with the grey month cartouche, which is only a column header for a target month.

The time header

Where a card sits sets its status

Two things at once. The grey month cartouche is a card's target month, and on a Kanban the month marks the end of the work. The coloured band above is a status-guidance zone: the status a card in that time is expected to hold. Q+1 is where planning crystallises, and Intend or Demand lock into a month as Commit.

Past quarter

Done

Current quarter

On-going

Q+1

Lock to a month, Commit

Later this year

Intend or Demand

Next year

Everything Demand

The published roadmap

The published roadmap: a kick start

Expanding every project floods the board, so the published roadmap draws only a project's two ends: a kick-start card where activity begins, an arrow, and the project's final card (the rollout or release) at its expected time. The chain between is hidden. A kick-start card carries no special colour: its colour is the status of the start.

Team A kick startCommit
RolloutDemand · 2027

Connectors

Arrows are notation, not decoration

Every arrow is part of the board's structured data, not just a visual, so a machine can read it as well as a person.

1

Two ends, one arrow

Collapsed. A kick-start card to the project's final card, the chain hidden.

2

Chain progression

Expanded. A release's milestone chain, laid out statically.

3

Inter-track dependency

One card gates or feeds another, across tracks.

Usage rules

The rules that keep it honest

01

The board is the single source of truth. One card, one status, one colour at a time.

02

Commit is the final gate before work. Committed is not started; work begins at Solution.

03

A new demand lands at the first free slot in time, after everything already on the roadmap.

04

Intend is positioned by quarter, not a fixed month. Certainty pulls it into a month, as Commit.

05

Time constrains status: a card cannot hold a status its place in time would not allow.

06

A slip cascades downstream. Move a card, and the chain after it retro-plans from the release.

07

Expand for the team that runs it; publish collapsed for the people who read it.

For a machine

Built for a machine to read, and to run

Because the notation is real (colour, position, arrows, a legend map), the board is data, not a screenshot. A read-skill turns any board into structured data; a write-skill applies changes back, in valid notation. The full, versioned spec is open.

Read the open spec

That is the whole language.

Status is a colour, phase is a position, and a few rules for how time constrains a card. Draw it anywhere, and your team and your AI read the same board.