Does the PR check block our merges?

It warns by default. When you're ready, one line of config (block-on-conflict: true in .lockstep.yml) turns a conflict into a failing check. The judgment stays with your team; Lockstep flags, humans decide.

What does the check actually compare?

The surfaces a PR touches (endpoints, capabilities, flows) against the binding decisions that govern them. A change to a governed surface with an open conflict gets an annotation and a labeled PR comment linking both decisions.

Does Lockstep read our source code?

The check runs against changed surfaces and the decision record; Lockstep's coordination flow carries decisions and metadata, not your source. The only thing it writes to GitHub is the check result and a labeled comment.

Lockstep for GitHub

Lockstep runs a PR check that catches code drifting from binding decisions — warning on conflict before it merges, blocking when you opt in, right where your engineers already work.

What Lockstep captures from GitHub

a PR that may conflict with an approved product rule
decisions made in PR review comments
an agent shipping code against a prior call

How the loop runs

Lockstep captures the decision from GitHub, routes it to its owner for one-click confirmation that makes it binding, then briefs every engineer and every AI coding agent before they touch the code, and flags any pull request that drifts from it. See the full pipeline on how it works.

How to set up Lockstep for GitHub

Sign in to Lockstep with GitHub and run lockstep onboard in your repo. It links the repo to a project, writes or merges lockstep.yaml, and seeds the surface graph.
Add the Lockstep PR Check GitHub Action (actions/pr-check in the Lockstep repo) to a workflow, with your Lockstep API URL and CI token.
Optionally pass a GitHub token with pull-requests: write so the check can post a labeled PR comment naming conflicts. Annotations show up without it.
Run in warning mode first. When you're ready to enforce, set block-on-conflict: true.

Example: a decision captured from GitHub

Illustrative example

In the PR

A merged PR description: "Switch refunds to async batch: refunds are queued and processed nightly instead of inline."

Drafted decision

Refunds are processed asynchronously in a nightly batch, not inline. Surface: the refunds flow. Source: the merged PR.

Approved record

The owner confirms it. A later PR that brings back inline refunds touches the same governed surface, so the check annotates it and both decisions are linked for review before merge.

Access & trust

GitHub App with a PR check. Configurable via .lockstep.yml.

What Lockstep reads

Pull requests in the repos you link: changed surfaces and PR descriptions
Merged diffs, read (never modified) to record verified changes

What Lockstep never does

Storing your source code: the ledger holds decisions and their source anchors
Writing anything to GitHub except the check result and a labeled PR comment
Blocking a merge unless you opt in with block-on-conflict

Full details on the security page.

Frequently asked questions

Does the PR check block our merges?: It warns by default. When you're ready, one line of config (block-on-conflict: true in .lockstep.yml) turns a conflict into a failing check. The judgment stays with your team; Lockstep flags, humans decide.
What does the check actually compare?: The surfaces a PR touches (endpoints, capabilities, flows) against the binding decisions that govern them. A change to a governed surface with an open conflict gets an annotation and a labeled PR comment linking both decisions.
Does Lockstep read our source code?: The check runs against changed surfaces and the decision record; Lockstep's coordination flow carries decisions and metadata, not your source. The only thing it writes to GitHub is the check result and a labeled comment.