Skip to main content

Keel Roles And Lanes

If Board Model explains what exists on the board, this page explains who gets to move it. Keel keeps strategy and implementation close, but it does not let them blur together. The board has separate lanes because the questions are different.

Management Lane

Choose and constrain

Use management roles when deciding what should exist, what should change, and what needs review or acceptance.

Delivery Lane

Execute and submit

Use delivery roles when pulling implementable work, starting stories, attaching evidence, and submitting slices.

Role Taxonomy

Be explicit about who is acting

Keel requires `--role` for lane selection so the board never has to guess whether you want strategic or delivery work.

keel next is role-aware on purpose​

Keel does not have an implicit default queue. You must declare the role family that should be used for routing:

keel next --role manager
keel next --role operator
keel next --role operator/software:frontend

This matters for two reasons:

  • it protects strategic work from getting buried in implementation noise
  • it protects delivery work from being interrupted by planning decisions that belong elsewhere

If you want to inspect the routing contract directly instead of inferring it from behavior, use:

keel roles
keel roles --json

Management lane​

Management lane questions:

  • Which mission should be active?
  • What problem deserves a new epic?
  • Is a voyage planned tightly enough to start?
  • Can this story be accepted yet?

Management work is about selection, constraint, and authority. This lane is where the board decides what should exist and what can be trusted next.

Delivery lane​

Delivery lane questions:

  • What is the next executable slice?
  • Which story should I start now?
  • What evidence is still missing?
  • What should be submitted for review next?

Delivery work is about execution, submission, and local proof. This lane is where the board consumes the plan without improvising a new one.

Role selectors​

The lane boundary becomes real when you use explicit roles on commands:

keel next --role manager
keel next --role operator
keel next --role operator/software:frontend

If you want the routing rules and command patterns in more detail, read Role Routing And keel next.

The shared board is still one system​

Separation does not mean fragmentation. Both lanes read from the same board state:

  • the same mission and epic structure
  • the same voyage plans
  • the same story evidence
  • the same routines and health signals

That is why Keel works for mixed teams. A project manager, engineer, designer, and operator can all look at one system without wanting the same view.

Commands that make the lanes legible​

keel roles
keel flow
keel flow --scene
keel workshop --scene
keel doctor
  • keel flow shows how work is moving across the configured topology
  • keel roles shows which roles resolve to which lanes and contracts
  • keel workshop --scene highlights items that require human attention
  • keel doctor validates structural integrity regardless of lane

The lanes decide what you pull next. Diagnostics tell you whether the board should be trusted first.

If you want the full visual contract, read Scene Surfaces.

Once the structure and lane authority are clear, the remaining question is temporal: what does one good move look like? Read The Turn Loop next to see how Keel turns board structure and role routing into a repeatable operating rhythm.