The facts BLOM keeps apart

Seven facts

Software moves through several states on its way to users. The BLOM method names seven, and keeps each one a fact of its own:

Intended

What you mean the product to do: a spec, or a Job's desired outcome.

Approved

Someone allowed to approve said yes to one exact revision, for a stated purpose.

Implemented

The change exists: code written, or a spec revised.

Verified

Evidence shows it meets its criteria: a test, a check, a review.

Integrated

It's merged into a shared branch, such as dev.

Deployed

It's running in an environment.

Exposed

Users can reach it.

Why they stay apart

Each fact can be true while the next isn't. An approval says a revision may be built, not that it was. A merge puts a change on a branch, and runs it nowhere. A deployment can sit behind a flag no user sees.

A single status, such as Done, hides which of these is true. So BLOM records each fact on its own, from its own source, and never counts one as another. Evidence that's missing, stale, or unknown never counts as passed, and a summary never turns a gap into success. See Core distinctions and Results in the method.

A merge isn't a deployment

Say Codex opens pull request #158 for the Job invite-expiry-build and links it to the Job, and Grace Hopper merges it into dev. The Job's GitHub observations show the merge, with its commit and the GitHub account that made it, and say: "The merge records integration to dev. It grants no approval or completion."

Invitations still has no new version. A version is made only when someone completes the Job's Release step with Released to set to Production, and an outcome that isn't a failure. A release to another environment records where it went, and makes no version. Items and Jobs covers versions.

Where BLOM records each fact

A task's phase and a session's closure aren't on this list. A phase says where work stands, and a closure reports what a session did. Neither proves any of the seven facts. Handoffs explains why a closure is a handoff, not completion.

Verification and releases

Each product has a Verification and releases page. It lists the product's open Jobs, those needing attention first, each with its coverage, such as "6 required: 4 satisfied · 1 failed · 1 missing", its unmet requirements, and its open gaps. Below them, each environment in your PDLC shows its recorded deployments, newest first.

The page keeps verification, merges, and deployments apart, and none implies another. A requirement whose result is missing, stale, or unknown never counts as satisfied. BLOM also compares the schema observed in each environment with the approved DB-Spec, and a difference shows as a gap.

GitHub, read-only

BLOM reads pull requests, merges, direct pushes, and check results from the repositories you connect, and makes no change in GitHub. On a task's page, GitHub observations lists what GitHub reported about the branches and pull requests linked to the task. As the page says, these observations approve, verify, and complete nothing.

• Each observation keeps the time GitHub reported, the time BLOM observed it, the commit, and the GitHub account that acted.
• A check shows its name and run, and its status and conclusion as GitHub reported them.
• A link to a task made after the change was observed says so. It doesn't show the change was governed when it happened.

A merge or direct push that no linked task covers is an unlinked change, and BLOM records a gap for it, with an owner. The gap is resolved by linking the change to a Job, or by recording why no task applies. Resolving records an explanation after the fact: it grants no approval and meets no gate. On any task's page, Open unlinked-change gaps assigned to me lists the gaps you own, and each product's Verification and releases page links to its unlinked-change gaps, listed apart.

Through the public API, verification.readCheckResults reads one named check on an exact commit, as passed, failed, missing, stale, or unknown. A check that's missing, still running, out of date, or conflicting never reads as passed.

Reviews are evidence

A review records someone's assessment of exact subjects: a pull request at its head commit, a commit, or a document revision, each pinned by its full hash. Select Record a review on the Job it serves, and give its independence, its verdict, and its findings. An agent records its own with blom_record_review.

A verdict reads like Verdict: Approved: the reviewer's conclusion, never an approval. A review grants nothing, changes no gate, and completes nothing. It's recorded whole and never edited, and a later round is a new review. Each finding stays open until it's marked fixed by a later step of the Job, or moved to a Job or a Bug. Items to Jobs walks through the form.

Tracing a change, and the decisions behind it

The trace view follows the links between BLOM's records in either direction. Back from a deployment, it runs through the merge, the checks, the reviews, the approvals, and the claims to the Job, its reason, and any report it took on. Forward from a task or a decision, it runs to everything it affected, starting with the items its Jobs targeted. Each step shows who acted, through which channel, why, and under what authority. A missing link shows as missing, never filled in.

Decision records keep the choices behind the work: who decided, in what words, why, what it replaced, and where it applies. A decision changes only when a later one supersedes it, and the chain stays readable. A decision record explains authority. It grants none.

Related