A lifecycle map is a visual model of your software development lifecycle (SDLC): a directed graph of stages and transitions from idea to production. Define your stages - grooming, development, review, staging, deploy - and the transitions between them, then see the map as one diagram so every handoff, bottleneck, and gap is visible.

In short

Models your SDLC as a DAG of stages and transitions from idea to production across all your tools.
Use it for a single view of a process that spans multiple tools, teams, and automation levels.
Skip it when one pipeline already covers your workflow end-to-end.
Graduation path: document your current process, then progressively automate stages as Farna Control pipelines.

The problem it solves

Your engineers work in GitHub, your PMs in Linear, your deploy pipeline in GitHub Actions, and staging separately, so nobody - engineers, PMs, or leadership - has a single view of how a ticket moves from "created" to "shipped." When a deploy skips staging, a PR merges without review, or a handoff goes unowned, the process lives in people's heads and across disconnected tools. You cannot improve or 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.

Stage node types

Each stage is a node of one of four types:

Farna Control (solid border): an executable Farna Control pipeline. Click the node to see the pipeline graph; the stage is fully managed.
External (dashed border): runs in an external system - CircleCI, GitHub Actions, PagerDuty. Farna Control documents and surfaces the stage without owning its execution.
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, a gap you intend to fill.

Transition edges with trigger metadata

Each transition carries metadata: what triggers the handoff, how often, and under what conditions. Trigger types include pipeline_completed, webhook, cron, manual, and external. The metadata keeps the map a living document rather than a static diagram that goes stale when a tool changes.

Graduation path: day 0, day 1, day N

The adoption model is incremental:

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

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

Multiple maps per organization

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 show how the organization operates.

Fractal navigation

From a stage node you drill into the pipeline, then the agent, then its configuration, then sub-pipelines. At every level you zoom in for detail or out for flow, which makes lifecycle maps navigable representations of your process.

Journey example: before and after

Before

Wei is an engineering manager at a 40-person startup. His team ships through Linear, GitHub, GitHub Actions for CI, and manual staging and production deploys, with nothing written down, so a new engineer shadows someone for a week. When a hotfix bypasses staging or a PR merges without tests, the postmortem shows the person skipped a step they did not know existed.

After

Wei maps the current SDLC, every stage external or manual. For the first time the team sees how a Linear ticket becomes a GitHub branch, how CI runs, how staging deploys, how production releases flow. The map surfaces an undocumented stage: the manual approval before production deploy that only two people know how to do. Wei automates the staging deploy as a Farna Control pipeline, graduating that stage from manual to Farna Control. The team can now see which stages are automated, manual, or gaps, and a new engineer reads the map on day one.

When to use it vs. when not to

Use a lifecycle map when your process spans multiple tools, teams, or automation levels, when you need one source of truth for how work flows, or when onboarding, auditing bottlenecks, or choosing the next stage to automate. A single pipeline that covers your workflow end-to-end needs no map, and the map models flow rather than executing it. Do not create a map nobody maintains: a stale map gives a false sense of understanding.

Where it fits

Lifecycle maps sit above pipelines: a pipeline executes steps, while a map shows how pipelines, external tools, manual processes, and planned work connect. Together with HITL gates and the principles of Farna Control, they govern an SDLC spanning humans, agents, and tools.

Go deeper

Read the Lifecycle Maps docs for structure and configuration, or the Pipelines and Triggers docs for the automation layer. Take the product tour to see lifecycle maps in action, or use the contact page to talk about mapping your SDLC.