Specs, under version control
Keep specs and code in sync when AI agents write the code.
BLOM is product management software built for building with AI. It keeps your people and AI agents working from the same plan. Your specs live in your Git repository as Markdown. BLOM pins every revision to a commit, so people and agents work from the same exact text.
P-Spec 1-2 · Invitations
Read from your repository. Each revision is pinned to a commit.
Jobs on this capability
Specs, under version control.
A spec says what's intended: what a product or one of its items should do, how it's designed, or how it will be checked. Intent changes, so "the spec" alone is never precise enough.
So BLOM treats specs the way you treat code. You write and change them in your repository. BLOM reads them, and records exactly which text each revision held.
A revision for each change
When a commit on the document branch changes a document's content, BLOM records a revision pinned to that commit. A commit that leaves the content alone makes no new revision.
A number and a pin
Each revision BLOM records has a number and a pin, written like r1 @ 4e1a9c2. A citation names both, so it always means the same text, whatever happens to the file later.
Markdown in your own repository
Specs are Markdown in your own Git repository. BLOM pins each revision to a commit, such as P-Spec 1-2 r4 at commit 4e1a9c2.
Eight document types
BLOM reads eight types of document. Each has one purpose: P-Spec, D-Spec, T-Spec, DB-Spec, S-Std, ADR, V-Plan, and R-Plan.
Jobs change the spec, then Jobs build it.
A Job names the items it changes and the spec revision it follows. One Job revises the spec, and the next builds that revision.
Revise the spec
A Job changes P-Spec 1-2. BLOM pins r4 to its commit.
Approve that revision
Grace answers what Claude left open, approves that exact revision, and assigns the build.
Build that revision
The spec Job's handoff is where the build Job starts. A Job builds r4 exactly.
Build from fixed text while the spec moves on.
A citation stays put. When a document gets a newer revision, the Job still cites the one it named, until someone revises its brief to cite the newer one. The Job's page says when a newer revision exists.
That's how a Job builds against the text it was given, even while someone else revises the spec.
Each citation names a revision and a pin
A Job's brief says what the work is for: its desired outcome, its target items, and the documents that govern it. Each citation names an exact revision and pin.
Agents read the text as it was
A context export supplies each cited document's text at its exact revision. For a file in your repository, that's the file as it was at the pinned commit.
Approve one exact revision.
A document revision is approved for a purpose, such as Build, by one person's sign-off. The approval binds that exact revision, its purpose, and its scope: the whole document, or the sections the approver names.
A newer revision starts with no approval
One revision can hold approvals for different purposes, and a newer revision holds none until someone approves it.
An approval isn't a build
An approval says the revision may be used for its purpose. It isn't proof that anything was built. The facts BLOM keeps apart covers why.
BLOM reads your repository, and never writes to it.
Connect a GitHub repository so BLOM reads its specs, pull requests, merges, and checks. BLOM only reads: it changes nothing in GitHub.
No commit of its own
It never writes to the repository. Its requests to GitHub only read, so it makes no commit, branch, comment, review, or check of its own.
To change a spec, change the file
To change a spec, change the file in your repository. BLOM records the new revision when the change reaches the document branch, and never edits your files.
What GitHub reports is a record
All of it is a record of what GitHub reported. It approves, verifies, and completes nothing. A merge records integration into a branch, never an approval or a completion.
A record of who did what
Every change records who made it, a person or an agent with the person it answers to, and when, why, and under what authority.
Read next.
The Docs guides behind this page.
Build with AI, and know who did what.
Specs under version control. Jobs that change them, then Jobs that build them.