Evidence-Bound Autonomous Research (EviBound): A Governance Framework for Eliminating False Claims

TL;DR

EviBound is an evidence-bound execution framework that eliminates false claims through dual governance gates requiring machine-checkable evidence, and this package includes execution trajectories, MLflow run IDs for all verified tasks, and a 4-step verification protocol.

Abstract

LLM-based autonomous research agents report false claims: tasks marked "complete" despite missing artifacts, contradictory metrics, or failed executions. EviBound is an evidence-bound execution framework that eliminates false claims through dual governance gates requiring machine-checkable evidence. Two complementary gates enforce evidence requirements. The pre-execution Approval Gate validates acceptance criteria schemas before code runs, catching structural violations proactively. The post-execution Verification Gate validates artifacts via MLflow API queries (with recursive path checking) and optionally validates metrics when specified by acceptance criteria. Claims propagate only when backed by a queryable run ID, required artifacts, and FINISHED status. Bounded, confidence-gated retries (typically 1-2 attempts) recover from transient failures without unbounded loops. The framework was evaluated on 8 benchmark tasks spanning infrastructure validation, ML capabilities, and governance stress tests. Baseline A (Prompt-Level Only) yields 100% hallucination (8/8 claimed, 0/8 verified). Baseline B (Verification-Only) reduces hallucination to 25% (2/8 fail verification). EviBound (Dual Gates) achieves 0% hallucination: 7/8 tasks verified and 1 task correctly blocked at the approval gate, all with only approximately 8.3% execution overhead. This package includes execution trajectories, MLflow run IDs for all verified tasks, and a 4-step verification protocol. Research integrity is an architectural property, achieved through governance gates rather than emergent from model scale.

Figures (11)

• Figure 1: Complete System Overview: The full research cycle spans three teams—Execution (left, blue) handles task implementation with phases 1--7 and retry mechanisms (4.5/5.5/6.5), Reflection (center, pink) monitors execution via error signals, generates patches through the policy layer, and performs adaptive learning, and Planning (right, green) reads results, synthesizes new tasks, and sends them to execution. The memory system (episodic → semantic → procedural) enables cross-cycle learning. Iterations flow between components: execution outputs hand off to reflection for analysis, reflection provides suggestions back to execution retries, and planning consumes verified results to generate the next cycle's tasks.
• Figure 2: System Architecture: End-to-end governance pipeline (Phases 3--7) with bounded retry mechanisms (4.5/5.5/6.5). The Planning Team generates task specifications, the Executive Team (3 agents: Ops, Quality, Infrastructure) enforces dual governance gates, and verified results flow to Phase 7 reporting. Retry sub-phases enable confidence-gated recovery while avoiding infinite loops.
• Figure 3: Three-Agent Collaboration: Executive team structure showing dual-role pattern. Agents participate in both pre-execution review (Phase 3→4 Approval Gate) and post-execution inspection (Phase 5→6 Verification Gate). Phase 4 requires consensus approval with confidence threshold $\tau \approx 0.7$. Verification routing directs failures to minimal necessary phase: missing evidence → Phase 6.5, runtime errors → Phase 5.5, spec misalignment → Phase 4.5, scope issues → Phase 3.
• Figure 4: Evidence Contract Schema: Fields required for machine-checkable evidence (run_id, metrics, artifacts, status).
• Figure 5: Verification Pipeline: Evidence-binding flow from acceptance contract to MLflow validation. The verifier resolves run_id, checks artifact presence, validates execution status (FINISHED), and optionally validates metrics when specified by acceptance criteria. Failures route to the minimal necessary phase: missing evidence $\rightarrow$ Phase 6.5, runtime errors $\rightarrow$ Phase 5.5, metric violations $\rightarrow$ Phase 4.5, scope issues $\rightarrow$ Phase 3.