How Lockstep works.
Lockstep sits beside the tools your company already uses, notices when a decision has been made, makes it binding once the person who owns it confirms, and delivers it to every engineer and every agent who touches the affected code — then keeps remembering: verified changes from merged PRs, weekly digests, and review dates keep the record true after launch. This page walks the pipeline end to end.
This page is the engineering tour. The plain version first: Lockstep reads the tools where your company decides, sends each decision to its owner for a one-click confirmation, briefs every person and every AI agent before work starts, and flags code changes that may conflict with a binding decision before they ship. Everything below is how, source by source, in detail.
Capture, per source.
What counts as a decision differs by tool. Each connector has its own trigger.
Slack threads
A thread where an owner lands on a call, like "let's do signed cookies, 24h", is a decision. Casual chatter isn't.
on: thread resolved in allowlisted channelJira
Acceptance criteria and scope calls made in ticket descriptions and closing comments.
on: status → Done · description changeNotion
Normative sentences in PRDs and specs: "must", "never", "always" statements with an owner.
on: status → In reviewGoogle Docs
Same as Notion: requirement language in shared docs you point Lockstep at.
on: doc shared to allowlisted folderConfluence
Architecture pages and runbooks: the rules teams already write down but never re-read.
on: page published in allowlisted spacePull requests
A PR description that changes behavior, like "switch refunds to async batch", is a decision about a surface.
on: PR mergedAgent sessions (MCP)
Choices your coding agents make mid-session, captured through the same MCP connection that briefs them. Auto-capture ships for Claude Code today; any MCP-speaking agent can read the record.
on: session decision recordedExtraction & approval.
Captured candidates land in a review queue as drafts. Nothing binds without a human: a draft has no effect on briefings or checks until its owner confirms it — a draft, not binding.
Owners can edit before confirming: tighten the wording, correct the scope, narrow the surface. The confirmed text is what gets enforced, not the raw capture.
Every decision keeps its source anchor, the Slack thread, the PRD paragraph, the PR, one click away, forever.
Guest checkout must not ask for a login code before payment.
POST /payments/initNotion ↗draftextracted from Guest Checkout PRD · a draft, waiting for a human
Briefing: humans and agents.
When an engineer or an agent starts work on a capability, Lockstep delivers the binding decisions that govern it, ranked by how directly they apply, truncated to what matters. Agents get this over MCP: the same get_product_context tool your Claude Code, Cursor, or any MCP-speaking agent can call mid-session when it needs more than the opening brief. The ledger also answers plain-English questions: paraphrases find decisions by meaning, not keywords — and it degrades gracefully to exact matching when no embedding key is configured.
We flag collisions. Humans judge.
Lockstep detects when two rules govern the same surface: the same endpoint, the same capability, the same flow. When that happens, both sides get the same message: “may conflict, review both”. It does not claim to semantically understand your product, and it will not silently pick a winner.
That's a feature, not a hedge. Tools that pretend to adjudicate meaning get one call wrong and lose the team forever. Lockstep's job is to make sure the collision is seen by both owners, before it ships. The judgment stays where it belongs.
The PR check.
Every PR is checked against the binding decisions that govern the surfaces it touches. It warns by default; block when you're ready. Literally one line of config.
# .lockstep.yml
block-on-conflict: true
And after the merge: Lockstep reads the merged diff, records the changed surfaces as verified changes in the ledger, and notifies exactly the teams whose code consumes what changed — not a broadcast, a routed delivery.
Maintain: the ledger after launch.
The record is only useful if it stays true. The PRD is checked against what actually got built — requirement by requirement, from verified merged changes. One command compiles the ledger into a per-project decision pack: a standard skill file with the binding decisions, the reasoning, the rejected alternatives, and what's no longer true, loadable by any agent that reads skills.
Rot is managed, not ignored: decisions carry review dates that nudge when due, launch-gate constraints expire on schedule, and project leads get a weekly digest of what needs a human look.
3 of 4 requirements have implementing work
## Principles
- Guests never re-enter data they already gave us.
## Binding decisions
- Guest checkout must not ask for a login code before payment.
- Why: OTP before payment killed guest conversion.
- Rejected: OTP-first flow.
## Approved product rules
⚠ [approved · Guest Checkout PRD] Ask guests to create an account only after payment succeeds.
## No longer true
- Checkout requires an account before payment.
compiled from the ledger · refreshed when the briefing says it's stale