Lifecycle Maps

A Lifecycle Map is the whole-SDLC spine for governing software work. It shows how a unit of work moves from idea to production and back into improvement across code, dependencies, security, release, documentation and knowledge, evidence, and remediation.

Farna Control is a Delivery Governance Platform for this software-specific lifecycle. A Lifecycle Map gives the work its shape. Pipelines execute the stages that are ready to be managed. Connectors connect those stages to the tools where the work happens. Gates control when automation must stop for policy or human review. Evidence records what happened and why.

Why it exists

A single pipeline cannot represent an entire software delivery lifecycle. Pipelines are execution graphs: they start, run, and finish. A Lifecycle Map is the longer-lived governance view that shows how related work moves through stages over hours, days, or weeks.

Issue-to-PR is one governed workflow within that map, not the definition of the product. The same map can show how a team governs:

Code change: issue → implementation → review → merge → deploy
Dependencies and licensing: discover → assess license or vulnerability risk → update → review → merge → deploy
Security: alert → classify → remediate → verify → document
Release: prepare → validate → approve → deploy → observe → recover
Documentation and knowledge: draft → review → approve → publish → maintain
Evidence: collect run outputs, approvals, evaluations, and change records for the relevant stage
Remediation: detect a failed check or production problem → assign corrective work → verify the fix → close the loop

These are software delivery concerns, not generic business workflow templates. The map makes their relationships visible so a team can see where automation, policy, human ownership, and evidence meet.

How the layers connect

The Lifecycle Map is the outer layer. Each stage can point to the next level of detail without forcing every stage into the same execution model:

Lifecycle Map stage - the SDLC responsibility or handoff, such as security verification or release approval.
Pipeline - the executable graph attached to a managed stage.
Connector - the bounded integration used to read from or write to GitHub, a tracker, continuous integration and delivery (CI/CD), a scanner, a knowledge base, or another supported tool.
Agent and node configuration - the prompt, model backend, schemas, commands, and runtime settings used inside the pipeline.
Gates and evaluations - human review, policy gates, evals, and guardrails that decide whether work may continue.
Evidence - the run snapshot, outputs, eval results, approvals, and append-only audit events that explain the decision.
Improvement - the feedback or remediation work that changes the process, pipeline, policy, or documentation when results show a gap.

The map does not replace those layers. It connects them so the SDLC can be governed as a system rather than as a collection of unrelated automations.

Core philosophy

The Lifecycle Map is a semantic model, not a workflow engine. It says which software-delivery stages exist and how work should flow between them without prescribing that every transition is automated.

A stage may be:

Current - part of the process the team runs today.
Preview - being trialed or partially managed; treat its behavior and coverage as subject to change.
Planned - a deliberate future stage or gap, not evidence that Farna Control already executes it.

Use these labels in stage names or descriptions when a map contains a mixture of established, trial, and intended work. This keeps the map honest while still letting a team plan its graduation path.

Structure

Each stage in the map is a node. Each handoff between stages is a transition edge. A stage can be connected to an executable pipeline, an external system, or a human process.

Stage node types

Stage node types
Type	Border	Behavior
`modulo`	Solid	Clickable to the pipeline graph. This stage is a Farna Control pipeline
`external`	Dashed	Clickable to an external URL. This stage runs in an external system, such as GitHub Actions, a scanner, or an incident tool. Farna Control does not own execution
`manual`	Dotted	No click-through. A human process with no automation
`placeholder`	Ghost/faded	Planned but not yet implemented. Represents a known gap

Transition edges

Transition edges carry trigger metadata:

Transition edges
Field	Description
`trigger_type`	`pipeline_completed` \| `webhook` \| `cron` \| `manual` \| `external`
`description`	Human-readable description of the software handoff
`trigger_id`	Optional link to a Farna Control Trigger entity
`condition`	Optional condition expression (JMESPath, a JSON query language)
`estimated_frequency`	Expected frequency of the transition

A transition can also be where evidence or approval is required. Put execution in the pipeline, policy in the eval or guardrail, human accountability in the human-in-the-loop (HITL) gate, and the resulting proof in the run record and audit trail.

Graduation path

A map can start with the process as it exists, then make governance concrete one stage at a time:

Day 0: map the current SDLC, including manual and external stages. Mark future gaps as planned.
Day 1: replace one manual or external stage with a Farna Control pipeline, such as issue triage, PR review, or release validation.
Day N: attach connectors, add policy and human gates, and use evidence from runs and evaluations to improve the next stage.

Some stages never graduate to Farna Control. External and manual are first-class stage types, not failures. The goal is not to manage every action inside Farna Control. The goal is a faithful, governable model of the software lifecycle, with clear boundaries around what Farna Control owns and what it observes.

Example SDLC spine

A practical map might contain these stages:

Example SDLC spine
Stage	Status	Governance connection
Intake and triage	Current	A tracker connector supplies issues and a pipeline classifies or routes them
Implementation	Current	An agent or existing runtime produces a code change; schemas define the expected output
Review and merge	Current	A source-control connector, policy eval, and human review gate govern the pull request
Build and test	External	A CI/CD connector dispatches the run and records its status and logs
Security and dependency verification	Preview	Scanners and package registries provide findings; remediation pipelines can act on them
Release approval and deployment	Current or preview	Release checks, approval gates, and deployment connectors coordinate the handoff
Documentation and evidence publication	Planned or preview	A knowledge connector publishes approved material and links it to the governed work
Remediation and improvement	Planned	Feedback, failed evals, and operational findings create the next governed change

The labels are illustrative. Set them to match the map’s actual coverage rather than implying that a stage is managed when it is only documented or planned.

Multiple maps

Any organization member can create a Lifecycle Map. Separate maps can make distinct software concerns legible while still using the same pipeline, connector, gate, and evidence model:

Main SDLC: Issue → Groom → Dev → Review → Staging → Prod
Dependency and licensing maintenance: Discover → Triage → Update → Review → Merge → Deploy
Security remediation: Alert → Classify → Remediate → Verify → Document
Documentation and knowledge: Draft → Review → Approve → Publish
Release recovery: Detect → Assess → Roll back or fix forward → Verify → Record

The map is the outermost layer: stage node → pipeline → agent or connector node → configuration → sub-pipeline. At every level, you can drill down from the SDLC responsibility to the execution detail and back to the evidence that explains the outcome.

Relationship to pipelines

An executable pipeline is attached to a modulo stage node. The pipeline owns execution of that stage. A Lifecycle Map owns the relationship between stages and can include work that remains external or manual.

A pipeline may be a stage of one active map at a time. Reuse the pipeline’s run records, eval results, HITL decisions, snapshots, and audit events as evidence for the stage it serves.

What is Farna Control?: the Delivery Governance Platform and the problem it solves
Pipelines: the directed-graph execution model
Triggers: pipeline trigger types and configuration
Connectors: tool integrations for pipeline nodes
Agents: the atomic units that make up a pipeline
Human-in-the-Loop: review gates and governance
Evals: quality checks and policy gates on agent output
Feedback System: using rejections and gaps to improve governed work
Architecture: the pipeline engine the maps orchestrate
Examples: ready-made pipeline graphs to attach to a stage

Next: Connectors