Next actions and claims

What a next action is

An open task's next action is the one step it waits on. It is one of three things:

• a step from your process's catalog, such as Code or Codex review;
• a phase move, such as Move to Build;
• Close as Completed.

In your queue and on the task's page, the next action shows what the step is, who it waits on, who put it there, and since when: Code, Waits on Claude, Suggested by Ada Lovelace on completing the step before, 3 h · since 09:14.

Whoever finishes a step suggests the next one. BLOM doesn't line up the steps after it. A blank next action reads No next action and Waits on nobody, and the task shows Backlog until someone sets one. The BLOM method describes next actions in full.

Set a next action

1. Open the task's page

   Under Details, select Set the next action. It shows only while the next action is blank and you can change work on the product.

2. Choose what it is

   Under What, choose An action, A phase move, or Close as Completed. A close waits on the work owner.

3. Name the step and who does it

   For an action, choose its Type and who it Waits on, a person or an agent. Fill in Subject (optional) or Instruction (optional) if the step needs them. A step your process doesn't run in the task's phase is marked (not in this phase). For a phase move, choose where it goes under To.

4. Save it

   Select Set the next action. The task enters the queue of whoever it waits on.

Complete a step

The person or agent the step waits on can complete it, and so can the task's assignee. Another actor's live claim on the step stops anyone else from completing it.

1. Select Complete

   On the task's page, under Details, select Complete. The dialog shows what counts as done for this kind of step, such as Done when: The change is linked as a PR or commit.

2. Choose the outcome

   Choose one of the step's Outcome choices, such as Done, Approved, or Changes requested, and add a Note (optional).

3. Suggest what comes next

   Under Suggest what comes next (optional), choose the next step and who it waits on, or Nothing: the next action stays blank.

4. Record it

   Select the button that names the step, such as Complete Code.

If the step you suggest can't run when BLOM checks it, it's kept with what you did, and the next action stays blank: Your suggestion was kept, not applied, with the reason.

When the next action is a phase move or a close, the page offers a button such as Make the move to Build, or Close as Completed. Its dialog shows the gate's check and whether it's met. If the gate warns, tick I've read what's unmet and make the move anyway. to go on. Your PDLC and its gates covers gates.

Each completed step joins the task's Actions table, with its outcome, who did it, when, and what it suggested. A Job's assignee can also record a step from Items to Jobs with Mark step done.

One assignee per task

Every task has at most one assignee: a person, or an agent with the person it answers to. The assignment stays across steps until someone changes it. The assignee can do the task's catalog steps, and the task is in their queue while a next action is set. On a Bug or another report, the assignee is whoever is assessing it.

The Assignment block sits on every task's page and in a Job's drawer in Items to Jobs. If you can change work on the product, which your role and access decide, it offers:

• Assign to me, to take the task yourself;
• Assign…, to choose from the product's people and agents who can change work there;
• Unassign, to leave it with no one.

Assignment is a notice, not a lock. Taking a task from someone happens at once, after BLOM asks you to confirm. They're told, and you can leave them a note of up to 500 characters. An agent that takes a task from someone has to leave one.

Claims

A claim records who is working on a next action right now. Agents claim through BLOM's MCP server, and people and agents can claim through the CLI or the public API. BLOM's screens assign instead, and show claims where they matter: in an agent's queue, in your queue's Claim filter, and on a task's page. While a claim holds a task's next action, the task's activity reads Active.

Leases, renewing, and releasing

Every claim has a lease: 30 minutes for an agent and 8 hours for a person, unless the task's PDLC sets other lengths. The holder renews it with a short note on progress. Releasing a claim takes a reason: the next action stays current and returns to the queue, and a Job assigned to the holder is unassigned. Completing the step ends the claim.

On a Job, and on a report

On a Job, a claim is a notice. Anyone who can change work on the product may claim a Job's step, whoever it waits on, and claiming assigns the Job to the claimer. A Job has one live claim at a time. If someone else holds it, the new claim takes it over at once, even within their lease: their claim ends, and their next call on it is refused, telling them who took the Job and when. Reassigning the Job ends the earlier holder's claim the same way.

On a Bug or another report, only whoever the step waits on, or the report's assignee, may claim it. A claim doesn't assign a report, and another actor's live claim refuses a new one until it's Stale. The report's Assignment block names the claim that holds its step and until when. Assigning the report to anyone else, or unassigning it, ends that claim, and the holder is told.

A Stale claim

Renewing never brings a Stale claim back. Its holder resumes it, or another actor takes it over, through the MCP server, the CLI, or the API. On a task's page that has a handoff, a Stale claim shows under Handoffs, in Since the last handoff, with its holder, its last update, its workspace, and its scope. Select Go to Assignment to reassign the task: assigning it to anyone but the claim's holder ends the claim.

Declared scope and overlap rules

A claim can declare its scope, what it expects to change: the Job's target items, code areas such as a path in a connected repository, document drafts, spec revisions, the entities a DB-Spec names, and environments. It can also name a workspace: a repository and a branch. A claim declares only the Job's own target items, and a report's claim declares no items or code.

When two claims' scopes overlap, the overlap rule for that kind of resource decides what happens:

Allow

Both claims go on.

Warn

The later claim acknowledges the overlap before it's made.

Coordinate

Before starting, the later claim's holder agrees a split or an order with the first claim's holder, or with the owner of what it touches, and BLOM records the agreement.

Exclusive

The later claim is Waiting until the first ends or narrows.

Your PDLC holds the rules. Open Organization, then PDLC, and expand When claims overlap to see the rule for Same item, Same code area, and Same document draft. Two migrations on one table can't safely run side by side, so the same DB-Spec entity defaults to Coordinate, and so does work on a product with another owner than the work's own. The same environment defaults to Exclusive. A Stale claim's overlap holds nothing back. The method's declared scope and overlap rules explain why each resource has its own rule.

See every claim at once

Coordination answers who is working on what right now, without opening every task. Filter it by product, item, actor, claim state, or the team that owns the work. It has four parts, each with its count:

• In progress: the Active and Waiting claims, by product and item, each with its holder, task, scope, branch, and lease.
• Overlaps: the claims whose scopes meet, and the rule that applies, with who has acknowledged a Warn, or which claim waits for which under Exclusive.
• Stale: the claims whose lease ran out, waiting for someone to pick the work up.
• Conflicts: the times work collided anyway, open or resolved.

A claim shows as a claim and nothing more, never as a phase, an approval, or a release. A claim you can't see shows only that it's there.

Record a conflict

When two pieces of work collide despite the rules, record a conflict on the task's page: the claims and their holders, the scope affected, and what collided. Each conflict has an owner, who reassigns it or resolves it with how it was settled. Coordination counts every conflict recorded, open or resolved.

Related