Decision Gate Basics

You met three claims on the overview page: a research agent cited a case that does not exist, a coding agent reported five passing tests it did not have, and a release agent said "ready to ship" and was right. This page walks the same ground slowly: what happens between an agent saying something and a workflow accepting it.

The agent says something happened

Every one of those scenes starts the same way: fluent prose asserting a fact. “Cited: Varghese v. China Southern Airlines.” “I added 5 tests and they all pass.” “v2.1 is ready to ship.”

The failure mode is not that agents lie more than they used to. It is that the surrounding system treats the sentence as the fact. Nothing in “they all pass” carries the test run, the commit it ran against, or who observed it. A claim is a proposal about reality, and a proposal needs something outside the proposer before it becomes operational truth.

The proposition that matters

The first move is deciding what the sentence actually commits to, and writing it down as typed conditions:

Claim: "I added 5 tests and they all pass."

C1: new_test_count == 5
C2: all(required_test_status == PASSED)
C3: tested_commit_digest == delivery_commit_digest

Each condition names a closed observation domain (an integer count, a status enum, a fixed-width digest) and a predicate over it. There is no room for “roughly five” or “mostly passing,” and no implicit coercion deciding late whether 1 equals 1.0. Note C3: nothing in the original sentence mentioned commits, but “passed” is meaningless without “passed on what.” Writing conditions down is where quiet assumptions become explicit obligations.

Evidence

Conditions are met by evidence, and evidence never gets the benefit of the doubt. Every piece carries its facts openly: how it arrived (submitted by the calling harness, or acquired from a declared local source), what exactly it concerns (which run, which commit, which account), when it was observed, what integrity protections cover it, and how independent its source is from the agent being checked.

Those facts are not collapsed into a single trust score. A condition’s evidence-use policy names the combination that suffices for that claim in that context. A development workflow may accept the agent’s own test report; a release workflow may require a receipt from an independent system, bound to the exact commit. The same boolean value, under two policies, carries two different amounts of proof — and the system keeps that distinction instead of flattering it away.

Present, absent, missing, insufficient

When a condition asks for evidence, the answer resolves exactly one of four ways:

ResolutionMeaning
PresentA value satisfying the policy is available.
ObservedAbsentA complete observation proves absence in a declared universe.
MissingNothing was ever supplied or acquired for this target.
InsufficientEvidence exists, but none of it satisfies the policy.

The two middle rows are where ordinary systems overclaim. A registry query that times out proves nothing. A search that returned no rows but never finished paginating proves nothing. Only a complete query over a declared universe can prove a record is absent — which is exactly the check the fabricated-citation scene needed: not “we did not find it,” but “a complete search of the reporter proves it is not there.”

True, False, Unknown

A typed predicate over a valid resolution produces one of three semantic results:

ResultMeaning
TrueThe evidence satisfies the predicate.
FalseThe evidence contradicts the predicate.
UnknownAdmissible evidence does not decide the predicate.

Unknown is the working state, not an error. Two-valued systems must round it away — unproven becomes false (missing data punished as failure) or unproven becomes true (unsupported progress waved through). Three values let the gate hold: the coding agent’s claim with no test report is not false, it is undecided, and the workflow can say precisely which obligation is open.

Failures stay outside this triangle. A parse error, a timeout, a denied authorization — those are operational events with their own handling. They are never dressed up as Unknown, and never quietly converted into False.

Requirements

Single conditions combine into requirements — the logic of “done”:

ALL(C1, C2, C3)                          -- every obligation holds

ALL(tests_passed, coverage_met,
    critical_findings == 0)              -- the release gate from the overview

QUORUM(2 of: alice_approved,
             bob_approved,
             carol_approved)             -- human sign-off as evidence

Requirement evaluation is deterministic and preserves Unknown: a requirement whose inputs cannot yet decide it stays undecided rather than defaulting. Human approval composes like any other condition — a recorded sign-off is evidence, a missing one holds the gate, and two-of-three quorums stop meaning “whoever answered Slack first.”

Workflows are graphs

Real work is not a straight line. Tests and a security scan can run in parallel; approval waits on both; delivery waits on approval. Decision Gate models a workflow as a dependency graph over stages:

build --> verify-tests ----+
                           +--> approval --> bind-artifact --> release
build --> security-scan ---+

A stage is not ready, ready, open, or completed — and readiness derives from accepted completed progress, not from anyone’s narrative of it. Progress only moves forward: once a stage is ready because its prerequisites completed, later progress elsewhere cannot un-ready it. Finishing the last box proves nothing by itself; the scenario declares its own completion law over completed stages.

Accepted progress

Evaluation produces a result; acceptance makes it history. Each run keeps one accepted record of what was established: which conditions resolved, from which evidence, under which policy, completing which stages. Proven claims are recorded with their proof. Unproven claims are held — fail-closed — with the unresolved obligation named. Nothing advances because a sentence sounded finished.

The record is built to be checked later: what was claimed, what was observed, and what was decided can be re-verified without trusting the system that recorded it. That is what turns “the agent said so” into “the run shows it.”

Keep going

Applications shows these pieces inside real product surfaces. How It Works makes the argument rigorously — including what this machinery deliberately does not claim. The Docs carry the full reference.