Your PDLC and its gates

Your process, by version

Your PDLC, your product development lifecycle, is the process work moves through: its phases, and the gate on each move between them. The BLOM method doesn't prescribe one. It keeps the facts of the work apart, and your organization decides the process that produces them. See PDLC in the method.

A process changes over time, so BLOM keeps it by version. A task records the version it opened under and keeps it after a newer version is approved. The rules that governed earlier work stay readable, and no one's work changes process halfway through by surprise.

Your organization's PDLC

Your organization's PDLC is made when you create the organization, from the starter you choose:

The PDLC page lays the phases out left to right, with each phase's sub-phases under it and a gate on each move. Select a phase to read what it's for, its settings, and the steps work can take in it, such as Code, Claude review, or Release, each with what counts as done. A phase marked Takes reports is where Bugs, Issues, and Feedback are assessed.

Each phase's details come from the PDLC's own standard, a Markdown file BLOM holds, with a section for each phase. The page links it under Its standard.

Each team has a PDLC of its own, which governs the products the team owns, and an Administrator of the team changes it as this guide describes. A scope can also keep several PDLCs, each declaring the work it covers, such as a lighter one for small fixes, or one for a single product. New work runs under the PDLC that covers it.

Versions

The page shows the version in force, such as Approved v1, and any draft, such as Draft v2.

• New work uses the version in force.
• A draft applies to no work until it's approved.
• A task keeps the version it recorded. Its page says so under Phase: "Version 1 of its process, as the task records it."
• An earlier version stays readable after a newer one is approved.

Change it, and approve the new version

An Administrator changes the PDLC and approves its versions.

1. Edit

   Select Edit PDLC. Rename phases and say what each is for, mark one Optional or Takes reports, move them earlier or later, use Add phase and Add sub-phase, or remove one. Select a gate to change it. Five phases or fewer are recommended, and seven is the most.

2. Save a draft

   Select Save as Draft v2. The draft applies to no work, and v1 stays in force.

3. Fix what's listed

   If the draft lists problems under Before this version can be approved, fix each one.

4. Approve it

   Select Approve v2, write Why you approve it, and select Approve v2 again. BLOM records you as the approver, bound to the version's content and to the exact revision of its standard, which is approved and pinned with it.

New work uses v2 from then on, and tasks already open keep the version they recorded. Before you approve, Compare shows what changed between the draft and the version in force, or between any two versions. Discard draft drops a draft, and Revert to the starter makes a draft from the starter you began with.

An agent whose key has Admin access can also approve a version, through the public API or the CLI. No MCP tool approves anything.

Gates

A gate sits on each move from one phase to the next, and on closing work as Completed. In the method, a gate's check is what must be true for work to move on, and the gate decides what happens when it isn't. See Customization and gates.

Select a gate on the PDLC page to open it. Each gate has three parts:

Check

What grants the move's approval. None: the move is met by the task's own record. A GitHub check, by name, such as a CI build: it counts only when it passed on the exact revision the work is at. A sign-off by a person the gate names, directly or through a role. Or both a sign-off and a check.

Mode

Warn: the mover acknowledges what's unmet. Observe: BLOM records what's unmet, and asks nothing. Block: BLOM refuses the move until the gate is met.

Requirements

What the gate lists: the task's completion criteria, an approval of each governing document, the applicable standard rules, or a document the work requires. Each, but the standard rules, is Mandatory or Advisory.

At a move, BLOM evaluates the gate: whether its check passed, and each requirement's result, read from the record that holds it. A Mandatory requirement that's failed, missing, stale, or unknown leaves the gate unmet. An Advisory one is shown and recorded, and never holds a move back by itself. Under Warn, the mover sees what's unmet, and moves on only after ticking I've read what's unmet and make the move anyway. The starters' gates are set to Warn and list no requirements, so moves cross them without a question.

Under Block, BLOM refuses the move, naming the check and each unmet Mandatory requirement, and the attempt ends as Blocked. The phase stays as it was, and whoever tried can suggest the next action that meets the gate. A check that can't be evaluated, such as when its source can't be reached, counts as not passed. Where the gate allows it, a person it names attaches proof instead, which BLOM records as manual, never as the check's result.

Where a Job's phase shows

A Job moves when its next action is a move, such as Move to Build, and someone who may make it selects Make the move to Build. A move back, or between sub-phases of one phase, crosses no gate. A Job can't skip a phase unless the phase is optional, and it closes as Completed only out of the last one. Next actions and claims covers making moves.

• The Job's page names its phase in its header, and lists the version's phases under Phase, its own marked.
• Items to Jobs, in its Jobs PDLC view, sets each open Job in the column of its phase, on every item it targets.
• An item's page shows its open work on each step of the product's PDLC.

A phase is where work stands. It isn't an approval, and it isn't proof that anything was built or checked. The facts BLOM keeps apart says where those facts live.

Related