Absence Blocks: Why No Evidence Is a Fail, Never a Skip

TL;DR: A required claim without satisfying evidence must fail, because a skipped check is not proof; a fresh Ranex clone starts red for exactly that reason. Read how the kernel works.

Your dashboard is green, yet a job did not run. Do you know which one? If the answer lives in a log nobody reads, your green result is carrying more confidence than the evidence earned.

Ranex treats absence as a blocker. When a gate requires a claim and no satisfying evidence exists, the verdict is FAIL — not a default, not a skip, not a warning waiting for a tired person to scroll past.

In this note

• A silent skip is not a pass
• A fresh clone starts red
• Make absence visible in your pipeline
• Failure names the missing proof

A silent skip is not a pass

A check that did not run has established nothing. Treating that empty space as success turns missing work into a green light.

You know the shapes. A condition bypasses a job. A suite collects no tests and returns cleanly. A scanner stops early and leaves a warning below the fold. The summary says green because the system recorded an exit path, not because it recorded the evidence you needed. That is a failure mode, not an inconvenient edge case.

Ranex makes the missing piece explicit. A gate carries required claims. Evidence must satisfy those claims for the subject under judgment. If the required evidence is absent, evaluation returns FAIL. The rule is an invariant of the kernel, alongside subject-bound evidence and no self-approval — though approver identity is unauthenticated today, so that check compares unverified strings. A gate that cannot block is refused at construction, because a gate that cannot stop anything is decoration.

This is why absence and determinism belong together. A pure-function verdict gives the same answer for the same inputs. Absence blocks answers FAIL when an input cannot satisfy the rule. Without both, “same inputs” can still mean “missing evidence became permission.”

There is a cost. A fail-closed system will make you produce evidence before it lets you call the work done. That can feel fussy when you know the command would have passed. But the entire point is that the system does not accept what you know without a record it can evaluate.

A fresh clone starts red

A fresh Ranex clone fails gate evaluation because it has no evidence yet. That failure is correct: no record exists for the required tests-executed claim.

The README gives the operator path. Run the test suite with frozen dependencies, then ask the gate to evaluate the current subject. On a fresh clone, evaluation returns FAIL with a nonzero exit and names the missing claim. It does not create a cheerful initial state. It does not infer success from an empty evidence file. It tells you that nothing has been proven.

PYTHONPATH=src uv run --frozen python -m ranex.cli.main gate evaluate HEAD \
    --approver reviewer_alice

To produce evidence, the operator needs a signing identity whose private key lives outside the repository. The committed keyring contains public halves, not private keys. After deliberate dependency provisioning, ranex run records the observed command result and subject digest; evaluation then judges that evidence against the gate. The steps matter because the verdict is not an applause button for a command. It is a judgment about whether the bound evidence satisfies the required claim for this subject.

Fresh-clone failure is a fast test of your own mental model. If a system can announce PASS before any relevant evidence exists, what did PASS mean? It meant the system had another rule, even if nobody wrote it down. Ranex writes its rule down in behavior: no satisfying evidence, no pass.

Make absence visible in your pipeline

You do not need to adopt a kernel to look for this fault line. Pick a recent green deployment and inspect the evidence path rather than the badge.

• List every claim the release depends on, not only every job name.
• For each claim, identify the record that satisfies it and the exact subject it covers.
• Make a missing result fail rather than disappear into a default branch.
• Make skipped, errored, and missing test outcomes visible as distinct states.
• Change the tree and confirm earlier evidence no longer satisfies the new subject.
• Ask whether an operator can tell the difference between unfinished work and a rejected record.

That last distinction matters. A record that fails verification is not reported as “no evidence.” Ranex reports it as refused and includes a reason. Missing evidence means no satisfying record exists. Refused evidence means a record arrived but did not clear verification. An unfinished task and an attack are different events; hiding them under the same empty label destroys useful information.

Staleness is absence in another form. Evidence is bound to a subject digest, so the same command on a different commit proves nothing about the current one. Once the tree moves past the digest that evidence covered, it stops satisfying the claim. That is not the system being difficult. It is the system refusing to let yesterday’s proof stand in for today’s code.

Failure names the missing proof

A useful FAIL tells you which required proof is missing or refused. It does not pretend that all failures are identical, and it does not claim a guarantee it lacks.

The repository’s Status section lists absence blocks as working today and says the project is pre-release. The full flow-graph and scenario-compilation picture is designed rather than built. Keep that boundary in view. The working claim here is smaller: the verdict path fails when a required claim has no satisfying evidence.

That small claim changes the conversation during a release. Instead of “the pipeline was green,” you can ask “which evidence satisfied this claim for this commit?” If there is no answer, you do not need a debate about whether the omission feels safe. The gate already has the right response.

Go to the last build you trusted because it was quiet. Find one claim it was supposed to establish. Then remove its evidence in a disposable copy of the process. If the release still looks green, you found the work to do.

Questions people actually ask

What does absence blocks mean in CI?

Ranex treats a required claim without satisfying evidence as FAIL, never as a default or a skip.

Why does a fresh Ranex clone fail evaluation?

A fresh Ranex clone has no evidence for the required tests-executed claim, so gate evaluation correctly returns FAIL with a nonzero exit.

Is refused evidence the same as missing evidence?

Ranex reports a record that fails verification as refused with a reason, while missing evidence means no satisfying record exists.

Try it. Break it. Tell me what broke. Read the Ranex repository, then make one required check absent in a safe copy of your own pipeline.

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.