Docs

Search Arxiu

Type to search across Arxiu.

How It Works

Decision Gate is a formally specified mechanism that converts selected agent assertions and workflow transitions into evidence-backed accepted claims. This page walks through how: what a claim has to become before it can be checked, what evidence has to establish before it can be used, and what "accepted" means precisely enough to build on. It does not claim to solve hallucination. It claims something narrower and more useful: that the claims a workflow chooses to care about can be made to produce proof before they produce consequences.

Reading mode

On this page Current section: The thesis

The thesis

Programs are deterministic but rigid. Humans are flexible but unreliable. Agents inherit the flexibility without inheriting the formal guarantees, and modern systems increasingly let them act anyway.

The failure is structural. An agentic workflow mixes two modes that do not belong in the same actor: generative reasoning, which proposes plans, explanations, code, and claims probabilistically; and operational commitment, where the surrounding system must decide whether work is complete, whether a transition is valid, whether an effect may be attempted. Without an external boundary, the same stochastic actor that performed the work also declares that the work succeeded.

Decision Gate places a deterministic boundary between proposal and acceptance. A workflow declares what must be established. Evidence is submitted or acquired, admitted under explicit policy, and evaluated against typed conditions. A claim or transition proceeds only when the declared proof relation is satisfied. If the obligation is false, unresolved, malformed, unavailable, or stale, the claim does not become accepted progress.

The actor may remain stochastic. Acceptance does not have to be.

Hallucination is only part of the problem

“Hallucination” usually names a model output that is false or fabricated. In agentic systems the commercially important failure is broader: the agent asserts that a condition is satisfied, and the host system proceeds as though the assertion were operational fact. “All tests pass.” “The cited case exists.” “The migration completed.” “The customer is eligible.”

These failures are not one thing, and collapsing them destroys the information needed to recover correctly. A claim can be semantically false: the test report shows a failing test. It can be unresolved: nobody ever submitted the report. Evidence can be present but insufficient: the report came from the actor being checked when policy demands an independent source. Absence can be positively observed: a complete registry query proves no record exists. And a check can fail operationally: the file would not parse, the source timed out. Each of these deserves a different response, and only some of them are the model’s fault.

Decision Gate begins by refusing the shortcut that causes the damage: treating the actor’s fluent declaration as the acceptance authority.

What it means to know something

Before any machinery, a question: what would it take to know that “the tests pass” is true?

Not certainty in the philosophical sense. Verification is always relative to a procedure: some named process, using named evidence from named sources, under stated assumptions, established a stated proposition at a stated time. That sentence has load-bearing parts. Change the source and you have a different fact. Change the scope, which commit, which account, which registry, and you have a different fact. Change when, and you may no longer have a fact at all.

Most systems flatten this into a boolean and lose everything that made the boolean meaningful. Decision Gate keeps the structure. Its claim is deliberately bounded: it can determine whether a named procedure, using named evidence under a named policy, established a named proposition. The credibility of the result depends on the law, the evidence, and the authorities that produced it, and the system is honest about that dependence rather than hiding it behind a confidence score.

That bounded claim turns out to be exactly what an agentic workflow needs, because a workflow does not need metaphysical truth. It needs to know whether it may proceed.

Typed conditions

An ambiguous instruction cannot be verified, so the first transformation is from prose to typed proof obligations. “Add five tests and make sure they pass” becomes a closed set of propositions:

P1: new_test_count == 5
P2: required_test_result_count == 5
P3: all(required_test_status == PASSED)
P4: tested_commit_digest == proposed_delivery_commit_digest

Completion law: P1 AND P2 AND P3 AND P4

The important move is not that language became truth. It is that an ambiguous sentence became a closed, inspectable set of obligations that either hold or do not.

Each condition declares an observation domain and a typed predicate over it, and the domains are closed on purpose: integers, exact decimals, booleans, bounded strings, dates, instants, closed records. Apparently trivial comparisons hide real semantics. Is 1 equal to 1.0? Does “contains” mean substring or set membership? Is an absent field different from a null one? Is a date a UTC instant or a local day? Decision Gate requires the law to answer these questions before evaluation. Invalid or incompatible operands are rejected when the condition is constructed; they do not drift into runtime and resurface as a convenient false.

Meaning, separated from retrieval

A condition defines what a proposition means: its domain, its predicate, and what evidence suffices for it. It deliberately does not define which API to call, which file to read, or which provider to trust. That is a separate, explicit binding: an acquisition path that describes how an observation can be produced for a condition.

The separation matters more than it first appears. “The tested commit matches the delivery commit” is one condition with one meaning. The digests might arrive from a CI receipt submitted by the calling harness, from a signed build manifest in a local document, or from a future registered integration that retrieves them directly. The condition does not change when the plumbing changes. Semantic law stays stable while acquisition varies by deployment, by privacy boundary, by customer environment.

Systems that fuse the two — where a condition simply is a provider query — cannot make this distinction, and it costs them: every change of data source silently becomes a change of meaning.

Evidence is a product, not a score

The common shortcut is to rank evidence on a single trust ladder. Decision Gate rejects the scalar. Evidence carries a set of independent facts: how it crossed into the system, what form its content takes, who or what produced it, what it was derived from, what exact scope it concerns, when it was observed, what integrity protections cover it, and how independent its source is from the actor being checked.

These axes do not reduce to one number. A value can have strong integrity and poor freshness. A source can be authoritative but out of scope. A local observation can be fresh and exact yet controlled by the very agent whose claim it supports. A signature can prove who signed the bytes without proving the statement is true. The evidence-use policy for each condition names the combination that suffices for that claim in that context — a development scenario may accept the coding agent’s own test report, while a release scenario demands an independent receipt bound to the exact commit. The same boolean does not carry the same proof.

Admission is also not sufficiency. Material first passes an admission boundary — bounded, validated, hostile by default. Admitted evidence is then assessed against the condition’s policy, and every condition required by an evaluation resolves exactly one way:

ResolutionMeaning
PresentA policy-satisfying typed value is available.
ObservedAbsentA complete admitted observation proves absence in a declared universe.
MissingThe evaluation has no candidate for this target at all.
InsufficientCandidates exist, but none satisfies the use policy.

The distinctions prevent specific, familiar mistakes. A court-records API timing out is not evidence that the case does not exist. A search whose pagination never completed cannot prove absence. “Not found” and “nobody looked” are different states, and a system that conflates them will eventually overclaim.

True, False, Unknown

A typed predicate over a valid evidence resolution produces one of three semantic results. True: the admitted evidence satisfies the predicate. False: it contradicts the predicate. Unknown: the admissible evidence does not determine the predicate under the declared policy.

Binary systems force one of two errors. Treat unresolved work as false, and you lose the distinction between “contradicted” and “not yet proven” — the workflow punishes missing data as if it were failure. Treat unresolved work as true or “best effort,” and unsupported progress walks through the boundary. Three-valued semantics let the workflow hold safely without pretending in either direction. The agent can acquire more evidence, repair the work, or escalate, knowing exactly which obligation is unresolved.

Unknown has a precise meaning, and it is not a garbage bin. It is a semantic result derived from validly admitted evidence. A parse failure is not Unknown. A timeout is not Unknown. A forged witness, an authorization denial, a malformed payload — these are operational and integrity failures, kept in their own typed families, because they require different handling: retry, alarm, audit, refusal. A system that launders its failures into Unknown has quietly destroyed its own failure taxonomy.

Requirement algebra

Single conditions rarely decide anything interesting. Requirements compose them:

ALL(tests_passed, coverage_met, NOT critical_vulnerability_present)

ANY(primary_registry_match, two_independent_attestations)

QUORUM(2 of: ci_passed, security_scan_passed, reviewer_approved)

Requirement evaluation is compositional and deterministic, and it preserves unresolved results: a requirement over True, False, and Unknown inputs stays Unknown when the inputs cannot yet decide it, rather than defaulting in either direction.

One structural distinction does real work here. Stage completion — is this unit of work done? — may use rich logic over condition results, including lawful negation, because evidence truth is not monotone: a vulnerability can be discovered. Workflow topology — which stages may open next? — is restricted to monotone requirements over completed progress, because progress must not flicker: once a stage is ready because its prerequisites completed, unrelated further progress cannot make it unready. Rich logic inside a stage; forward-only motion through the workflow.

Progress is a graph

Real workflows are not lists. Tasks fork and rejoin; a release wants two of three reviews; unrelated components proceed in parallel. Decision Gate models a scenario’s topology as a finite dependency graph — chains, forks, diamonds, multiple roots, disconnected components — with a stage’s readiness derived from accepted completed progress under its monotone prerequisite law.

Every stage is in exactly one of four states: not ready, its prerequisites do not yet hold; ready but unopened; open and incomplete; or completed, meaning its completion law evaluated True in an accepted mutation. Opening a stage assigns no agent, reserves nothing, and cancels nothing — work scheduling stays outside, where it belongs. And a scenario finishes only by its own explicitly declared completion law over completed stages, never by a structural accident like “the last node in the diagram was reached.”

The graph is what prevents a fluent narrative of progress from becoming an implicit workflow cursor. The system can always answer, from accepted facts rather than from the transcript: which stages are provably eligible right now?

Evaluate first, accept second

Evaluation is pure. The evaluator consumes validated law, accepted progress, and an admitted evidence snapshot, and performs no I/O — no file reads, no clock, no network, no storage. From those inputs it derives a candidate: perhaps a completion delta and a new frontier, perhaps a False or Unknown attempt that changes nothing.

A candidate is not yet progress. Each run has a single accepted history with an exact current head, and a candidate commits only if the head it was derived from is still the head. Two workers may race to extend the same run; one commits, and the other’s candidate is stale — not corrupt, not partially applied, just derived from a superseded state, and re-derivable. Repeated submissions of the same operation replay the original result instead of double-applying. When a commit’s outcome is genuinely unknowable — storage may have committed while the response was lost — the protocol reports that state honestly instead of guessing.

The separation is what makes the whole system auditable: evaluation is a deterministic function you can replay, and acceptance is a serialization point you can inspect.

Acceptance is not effect

An accepted mutation may carry an intent: send the refund, publish the artifact, deploy the release. Acceptance proves that the intent belongs to an accepted revision of the run and is eligible for dispatch. It does not prove the external system received it, performed it, or performed it exactly once. Effects live outside the boundary, in systems with their own failure modes, and pretending otherwise is how workflows come to believe in refunds that never happened.

The same honesty applies to the record itself. Durable state is revalidated on load rather than trusted because the system wrote it earlier. An exported run history can be independently re-verified — its artifacts re-hashed, its evaluations replayed against recorded evidence. And the verification claims stay separate on purpose: integrity of the record, authenticity of the source, currentness of the bundle, and truth of the original evidence are different properties, established by different means. A green check that collapses them is a green check you cannot trust.

What this does not solve

Decision Gate hardens workflows against unsupported and false claims that can be expressed as explicit proof obligations. That sentence has edges, and they are load-bearing.

It does not automatically decompose arbitrary prose into the right propositions; the workflow author, or an upstream tool, declares what matters. It does not make weak evidence strong: a lazily written predicate or a permissive evidence policy produces exactly the proof relation it declares, checked exactly. It does not see hidden reasoning, adjudicate contested interpretation, or detect deception outside the assurance facts the policy names. A source can be honestly queried and still be wrong; the policy decides how much independence and integrity a claim class requires.

What it removes is narrower and structural: the actor’s own fluency as the deciding authority. Every claim the workflow chooses to gate must produce evidence that survives a declared policy, and every acceptance leaves a record of exactly what was established, from what, under which law.

Where this leaves us

The mechanism is formally specified; its semantic and protocol properties are established; a working implementation exists, and its formal models and their bounds are documented rather than waved at. What its adoption changes about agent behavior across models, harnesses, and domains is an open empirical program — this system is the instrument that makes the question testable, not a claim that the answer is already in.

Agents will keep proposing reality fluently. The systems around them get to decide whether proposals become facts. Basics teaches the working vocabulary, Applications shows the boundary inside real products, and the Docs carry the full formal treatment: the requirement algebra, the graph model, the evidence standards, and their proofs.