Subject-Bound Evidence: Why “It Passed” Means Nothing Without a Commit Digest

TL;DR: “It passed yesterday” is not evidence about the code in front of you. A command result must be bound to the exact commit it observed. The accountability apparatus needs a record tied to the artifact, not a comforting memory.

You have seen the familiar green check on a branch that moved after the job ran. The label still says tests passed. The code is different. What does that result prove now?

In this note

• Why a result describes only one subject
• What the runner observes
• Why stale evidence must expire
• A binding checklist

A passing command describes one subject

A test command ran against some bytes, with some inputs, at a particular point in time. Its result can speak about that subject. It cannot automatically speak about the next commit, the next checkout, or the branch name after somebody moved it.

This is not paperwork. A small change can alter the behavior a test was meant to establish. A test result that continues to vouch for code it never observed turns green into a reusable mood. You need a claim, an artifact, and a link between them.

Ranex calls that link subject-bound evidence. The README’s “What makes a verdict trustworthy” and “Status” sections describe the invariant directly: the same command against a different tree proves nothing about this one. A changed subject is a changed question.

Think about a report handed from one engineer to another. “The suite passed” sounds complete until you ask: passed against which commit? If nobody can answer, the report has lost the one fact that tells you whether it applies. The test result may be genuine. It is still not evidence for the code you are about to merge.

The runner observes the committed tree

Binding a digest in a record is not enough if the command ran somewhere else. Your working tree can contain edits. Tool inputs can drift. A checkout can be adjacent to the commit you intended rather than the commit itself. “Close enough” is where false proof enters.

Ranex materialises the committed tree from verified blobs before it runs the bound command. Each blob is checked against the object identifier carried by the commit tree. The command runs in an environment built from empty, with a toolchain pinned to directories the observed party cannot write.

That is a strong claim, and it has a cost. The README says trees that need installed dependencies, or carry a symlink or submodule, cannot be observed through this path. The system refuses them rather than pretending an altered observation was the same subject.

Do not confuse a checkout with an observation. A checkout is convenient. An observation is the exact tree and execution context your record says it measured. When an agent has influence over the code and the environment, that distinction is not academic.

The project reached this shape after recorded false-PASS paths shared a root problem: the observed tree was not the tree HEAD named, and inputs were chosen by the party being measured. The current README says those paths are closed. The useful lesson for you is simpler: verify the subject before you let a result describe it.

Stale evidence must stop counting

Once the tree moves past the digest attached to an evidence record, that record stops satisfying the claim. Ranex turns the missing applicable evidence into FAIL. It does not keep yesterday’s test result alive because a branch name stayed familiar.

That can feel strict when you changed one line. Good. The claim is not “a related version passed a command.” The claim is about this subject. If the evidence no longer matches, the correct result is that you need fresh evidence.

This works with absence blocks. A required claim without satisfying evidence is FAIL, never a default and never a skip. Evidence that is absent and evidence that is stale arrive by different paths, but neither can support the claim under judgment.

The principle also carries beyond agents. A human-written patch deserves the same treatment. Better models do not change it. Faster CI does not change it. If you cannot bind the result to the artifact, you cannot tell whether the result applies.

Bind the claim before you trust the result

Use this before you accept “it passed” in a review, a release note, or an agent summary.

• What exact claim is this command meant to support?
• Which commit digest is the subject?
• Did the command observe that committed tree rather than a working copy?
• Were the command inputs chosen outside the party being measured?
• Does the record stop applying when the subject changes?
• Does missing applicable evidence refuse the claim?

Run that checklist on the next green build. If the answer to the digest question is a branch name, you have work to do. If a result remains valid after the code changes, ask what it is really asserting. Do not let the label do more work than the evidence can carry.

The working path is narrow

Ranex is pre-release. Subject-bound evidence and the run-to-evaluate path are listed as working today. The flow graph and scenario compilation that would feed a broader build workflow are designed, not built.

That limit matters. This post is not a claim that every engineering property is covered. It is a claim about an evidence boundary: the recorded command result is pinned to the subject it observed. Read the status, then judge the working path on that narrower promise.

Questions people actually ask

What is subject-bound evidence?

Ranex subject-bound evidence is evidence pinned to the exact commit digest it describes.

Why does a passing test stop counting after code changes?

Evidence for an older subject does not support a claim about the changed subject, so Ranex refuses it.

What tree does Ranex run a command against?

Ranex materialises the committed subject tree from verified blobs before running the bound command.

Try it. Break it. Tell me what broke. Read the MIT-licensed repository, then ask your next green build which bytes it actually observed.

Disclosure: this post was drafted with AI assistance. Every factual claim traces to the repository’s README or slice records — the same fact gate the product enforces on code. It ships only after Anthony’s own review.