Core concepts

SRM has its own small vocabulary. Once these few words click, the rest of the app reads naturally. This article is the map — a glossary you can skim now and come back to whenever a term trips you up.

Here's the whole idea in one breath: a release is a body of work made of components, the components are connected by a dependency graph that says what has to happen before what, people and agents take out a claim to work on a component without colliding, a dispatch wave kicks several off at once, findings capture what review turned up, and a deploy carries the finished release to production — all of it kept live so everyone sees the same picture as it changes.

Now the terms, one at a time.

#Release

A release is one shippable body of work — everything going out together under a single version or theme, like "v0.6.1" or "Search overhaul." It's the top-level thing you open and the shared record everyone on it reads from.

A release carries a theme (what it's about) and moves through phases as it matures — roughly: planning → open → executing → review → wrapping → deploying → shipped. You don't have to memorize the phases; think of them as the release's overall stage, from "still figuring out scope" to "out the door."

A release also records what's explicitly out of scope — the things the team decided not to do this time — so that context isn't lost.

#Component

A component is one scoped piece of a release: a single unit of work someone can pick up and finish. A release is a collection of components. "Add the login passkey flow," "Fix the revision-collision bug," and "Write the getting-started doc" would each be a component.

Every component has a work-state that moves in one direction:

Open — defined, not started yet.
In progress — someone (or some agent) is actively working it.
Proposed — the work is done and up for review (its pull request is open).
Merged — landed. This is the finish line, and it's what lets anything waiting on this component move forward.

Some components are flagged breaking or carry deploy-safety notes — signals that this piece needs extra care when it ships. A component can also link back to an issue in an outside tracker (a GitHub, Jira, or Linear item) so the two stay connected.

#Dependency graph

Components rarely stand alone — some can't start until others finish. "Show results on the page" can't begin until "Build the search API" is done. The dependency graph is the map of those must-come-before relationships across a release.

Each link is one edge: a blocker (the piece that must land first) and the blocked piece that's waiting on it. From the graph, SRM works out each component's real status at a glance:

Startable — nothing is in its way; it's ready to be picked up.
Blocked — one or more of its blockers hasn't merged yet, so it has to wait.
Unverified — the graph for this release hasn't been confirmed yet, so SRM won't call anything startable until someone builds and verifies it. This is a deliberate safety step, not an error.

The payoff: because SRM knows the order, marking a blocker merged is what automatically unblocks everything that was waiting on it. Nobody has to chase down "is it my turn yet?" — the graph answers it.

#Claim (the lock)

When you start on a component, you take out a claim on it. A claim is a lock: it says "I've got this," so two people — or an agent and a person — don't unknowingly work the same piece at the same time. This is what makes it safe for a whole team to move at once.

A claim is meant to be alive. While you're working, it quietly sends a heartbeat to show it's still active. When you're done, the claim is released so the component is free again.

If a claim goes quiet — a machine went to sleep, an agent crashed, someone wandered off mid-task — the claim expires and the component reopens on its own. SRM calls that a dropped claim, or drift: work that looked owned but actually stalled. Surfacing drift is one of the main reasons SRM exists — stalled work becomes visible instead of silently blocking everyone else.

#Dispatch wave

Sometimes you want to kick off several startable components at the same time — say, three independent pieces that can safely run in parallel. That grouped kickoff is a dispatch wave (a dispatch run, under the hood).

A wave is a layer on top of claims, not a replacement for them. Each claim is still the individual lock; the wave just groups the pieces launched together and tracks each one's progress — dispatched → in progress → proposed → merged, or failed if it didn't work out. That gives you one tidy summary of "how's this batch going?" and lets someone pick the thread back up later even if whoever started it stepped away.

#Finding

When a release is reviewed, each thing worth noting is recorded as a finding — a single, tracked review note attached to the release (or to a specific component). Findings keep review results in the shared record instead of buried in comments.

Each finding has a severity — high, medium, or low — and a status that tracks what's been done about it:

Open — raised, not yet dealt with.
Deferred — acknowledged, but deliberately parked for later.
Accepted — reviewed and consciously accepted as-is.
Fixed — resolved.

Open and deferred findings count as unresolved. This matters at ship time: unresolved high-severity findings act as a gate — the release isn't considered ready to deploy until they're handled. It's a safety net that keeps known problems from quietly riding along into production.

#Deploy step

When a release is ready, the deploy carries it to production — and SRM tracks it as an ordered sequence of steps, so a deploy is resumable and never a black box:

Merging — landing the release.
Deploying — the deploy is running.
Smoke — a quick check that production is healthy afterward.
Monitor — watching for a window to be sure it stays healthy.
Done — shipped and confirmed.

The steps only move forward, each carrying evidence of what happened. Because the progress lives in the shared record, if the person driving the deploy loses their connection, someone else can see exactly where things stand and carry on. The full walkthrough is in Deploying a release.

#Live

Almost every screen in SRM keeps itself current. As a component changes state, a claim is taken, or a deploy advances, you see it happen without reloading — that's what live means. A small status dot near the top of the screen tells you how fresh the view is, and if the instant connection drops, the app quietly falls back to checking for updates every few seconds so you're never looking at stale information for long.

Because it's important (and has a couple of states worth knowing), live has its own article: Understanding the Live indicator.

#The short version

Release — one shippable body of work; the shared record you open.
Component — one scoped piece of it; moves open → in progress → proposed → merged.
Dependency graph — what must come before what; makes pieces startable, blocked, or unverified.
Claim — the lock that says "I've got this"; goes quiet = drift.
Dispatch wave — several components kicked off and tracked together.
Finding — a tracked review note; unresolved high ones gate the deploy.
Deploy step — merging → deploying → smoke → monitor → done.
Live — screens update themselves; the dot shows how fresh you are.

With those in hand, head to Releases to see them all in one place, then Working a release to put them to use.