Feature Spotlight: How lifecycle maps give you a single view of your entire SDLC

A lifecycle map is a visual model of your software development lifecycle (SDLC) - a directed graph of stages and transitions that shows how a unit of work moves from idea to production. You define the stages your process uses - grooming, development, review, staging, deploy - and the transitions between them. You see the map as a single diagram, so you can spot every handoff, every bottleneck, and every gap in your process at a glance.

In short

• What it does: models your SDLC as a DAG of stages and transitions, showing how work flows from idea to production across all your tools.
• When you'd use it: when you need a single view of your process that spans multiple tools, teams, and automation levels.
• When you wouldn't: when a single pipeline already covers your entire workflow end-to-end.
• Graduation path: start with a documentation map of your current process, then progressively automate stages as Modulo pipelines.

The problem it solves

You are a team lead. Your engineers work in GitHub, your PMs track work in Linear, your deploy pipeline lives in GitHub Actions, and your staging environment is managed separately. Each tool shows its own slice of the process. Nobody - not the engineers, not the PMs, not the leadership - has a single view of how a ticket moves from "created" to "shipped." When something slips through the cracks - a deploy that skipped staging, a PR that merged without review, a handoff that nobody owns - the root cause is almost always the same: the process exists in people's heads and across too many disconnected tools. You cannot improve what you cannot see, and you cannot govern what you cannot see.

How it works

A lifecycle map is a semantic model, not a workflow engine. It says "tasks should flow through these stages in this order" without prescribing how each transition happens. Here is the anatomy.

Stage node types

Every stage in the map is a node, and each node falls into one of four types:

• Modulo (solid border): a stage backed by an executable Modulo pipeline. Click the node and you see the pipeline graph. This stage is fully managed.
• External (dashed border): a stage that runs in an external system - CircleCI, GitHub Actions, PagerDuty. Modulo does not own execution, but the stage is documented and visible.
• Manual (dotted border): a human process with no automation. A code review meeting, a manual deploy, an approval gate.
• Placeholder (faded): planned but not yet implemented. Represents a gap in your process you intend to fill.

Transition edges with trigger metadata

Each transition between stages carries metadata: what triggers the handoff, how often it happens, and whether conditions apply. Trigger types include pipeline_completed, webhook, cron, manual, and external. The metadata makes the map a living document - not a static diagram that goes stale the moment someone changes a tool.

Graduation path: day 0, day 1, day N

The adoption model is incremental:

• Day 0: map your current SDLC. Every stage is external or manual. The map is a documentation artifact - it makes the invisible visible.
• Day 1: replace one manual stage with a Modulo pipeline. That stage graduates from manual to modulo.
• Day N: more stages graduate. Some never will. External is a first-class stage type, not a shortcoming.

The goal is not 100% management. It is 100% model fidelity.

Multiple maps per organisation

Any team member can create a lifecycle map. You might have:

• Main SDLC: Issue to Groom to Dev to Review to Staging to Prod
• Dependency Renovation: Crawl to Triage to PR to Merge to Deploy
• Incident Response: Alert to Classify to Remediate to Postmortem
• Content Publishing: Draft to Review to Approve to Publish

Each map captures a different workflow. Together they give leadership a complete picture of how the organisation operates.

Fractal navigation

The map is the outermost layer. From a stage node you can drill into the pipeline, from the pipeline into an agent, from the agent into its configuration, and from there into sub-pipelines. At every level you can zoom in to see the detail or zoom out to see the flow. This is what makes lifecycle maps more than diagrams - they are navigable representations of your actual process.

Journey example: before and after

Before

Wei is an engineering manager at a 40-person startup. His team ships through a process that involves Linear for tracking, GitHub for code, GitHub Actions for CI, a manual staging deploy, and a manual production deploy. Nobody has written the process down. When a new engineer joins, they shadow someone for a week and pick it up by osmosis. When something goes wrong - a hotfix that bypassed staging, a PR that merged without tests - the postmortem reveals that the process was followed correctly by the person who skipped the step. They just did not know the step existed. The process lived in three people's heads and the rest of the team guessed.

After

Wei creates a lifecycle map of the current SDLC. Every stage is external or manual. For the first time, the team can see the full picture: how a Linear ticket becomes a GitHub branch, how CI runs, how staging deploys happen, how production releases flow. The map surfaces a stage nobody documented: the manual approval before production deploy that only two people know how to do. Wei automates the staging deploy as a Modulo pipeline. That stage graduates from manual to modulo. The team can now see which stages are automated, which are manual, and which are gaps. A new engineer reads the map on their first day and understands the entire process without shadowing anyone.

When to use it vs. when not to

Use a lifecycle map when your process spans multiple tools, multiple teams, or multiple levels of automation. Use it when you need a single source of truth for how work flows through your organisation. Use it when onboarding new team members, when auditing your process for bottlenecks, or when deciding which stage to automate next.

Do not use a lifecycle map when a single pipeline already covers your entire workflow end-to-end. Do not use it as a workflow engine - it models the flow, it does not execute it. And do not create a map nobody will maintain. A stale map is worse than no map because it gives a false sense of understanding.

Where it fits

Lifecycle maps sit above pipelines in the orchestration hierarchy. A pipeline executes a sequence of steps. A lifecycle map shows how pipelines, external tools, manual processes, and planned work connect into a coherent whole. Together with HITL gates and the principles of Modulo, lifecycle maps are how you govern an SDLC that spans humans, agents, and tools.

Go deeper

Read the Lifecycle Maps docs for the full structure and configuration, or explore Pipelines and Triggers to understand the automation layer. Try the hosted demo at demo.modulo.run, or use the contact page to talk to us about mapping your own SDLC.