Evidence-Gated Agentic Development: Inside the EG Loop
A red pipeline is expensive in a way that has nothing to do with compute. An agent-generated change fails CI at 6 p.m., and now you are the diagnostic engine: paging through job logs, deciding whether the failure is the code, the test, the scanner, or the environment, then deciding who is allowed to fix it. When AI writes code faster than you can review it, every failure becomes a manual investigation, and every manual repair is a chance for something worse: a fix that makes the pipeline green by quietly lowering the bar. Failed pipelines requiring too much manual diagnosis and repair is not an annoyance at AI speed — it is the bottleneck that decides whether agentic development is leverage or liability.
The Koinessa white paper's answer to this is not a better chatbot. It is a delivery model — Evidence-Gated Agentic Development (EGAD) — with a specific operating loop, a specific result vocabulary, and one hard rule about who may never touch the definition of success. This post is part of a series on the verification gap in agentic development; here we open up section 4 of the white paper, the EG loop itself.
What the EG loop actually is
The white paper defines EGAD as a software-delivery model in which AI agents produce and integrate small mainline changes, while commit, push, promotion, and release authority remain constrained by deterministic verification, signed evidence, policy gates, and human-controlled exceptions. Agents do the producing. Everything that moves code closer to production is gated by proof.
The loop has ten stages, and the paper is explicit that each exists to kill a specific failure mode: observe current state; recall prior decisions, fixes, and failures from persistent shared memory; plan bounded work with declared verification requirements; claim ownership through leases and file claims; compile a bounded context packet from canonical state; execute inside the claimed boundary; verify with deterministic tools emitting canonical result states; approve consequential transitions per policy, with humans holding the exceptions; ship and observe the deployed outcome, not just the merge; and learn — write the verified outcome back into memory where the next session's recall will find it.
Three properties separate this from "autonomous coding," and each one maps directly to the diagnosis-and-repair pain above.
Evidence is the acceptance currency
First: authority derives from state, not confidence. An agent reporting that work is complete changes nothing. The evidence bundle attached to the current commit is what changes state. This is the single design decision that eliminates most manual adjudication — you never have to decide whether to believe a summary, because summaries are not the mechanism.
Second: capabilities are rungs, not a switch. Generate, stage, commit, push, merge, promote, and deploy are separate delegable capabilities, expanded per task class from verified history. The white paper notes that trunk-based small batches make each rung cheap to check, citing DORA's capability guidance on trunk-based development. DORA — the DevOps Research and Assessment program — describes the practice as developers dividing work into small batches and merging to trunk at least once a day, with branches lasting hours rather than weeks; its analysis of 2016 and 2017 research data found higher software delivery and operational performance in teams with three or fewer active branches, daily merges, and no code freezes or integration phases. Small batches are not an aesthetic preference — they are what makes per-change verification tractable, which is why the EG loop's rungs work at agent throughput.
Third: verification is independent of generation. Deterministic tools, separate models, or humans evaluate; the generator never grades its own work. Policy — encoded as versioned, testable rules rather than prompt text — decides whether the evidence satisfies the profile. The white paper points to the Open Policy Agent as one source for the general policy-as-code pattern, while being careful to note that Koinessa does not claim to embed OPA.
Six ways a check can end — and why that fixes diagnosis
Here is the part of the model that most directly attacks manual triage. A pipeline that only knows green and red will misclassify a missing scanner as a clean scan. Koinessa's verification model distinguishes six canonical result states — PASS, FAIL, SKIPPED-NOT-APPLICABLE, INFRASTRUCTURE ERROR, TOOL MISSING, and EVIDENCE INVALID — and this model is live.
The diagnostic value is immediate. FAIL means the code did not meet the bar; INFRASTRUCTURE ERROR means the runner, not the change, is broken; TOOL MISSING means a check never ran and therefore nothing was verified; EVIDENCE INVALID means a receipt did not survive scrutiny. This is fail-closed verification in practice: an unverified success is never a pass, and absence of evidence routes to its own state instead of silently upgrading to green. When the pipeline is red, the first question — "is this the code, the environment, or the evidence?" — is already answered by the state label. Diagnosis starts at the second question.
A seventh state shipped with EGD-002 (live, 12/12 stories closed 2026-08-15): ABSTAIN-SPEC-CONFLICT, a rewarded, first-class route for an agent to declare that work cannot legitimately be completed under its current specification. The reasoning is blunt: the measured alternative to a legitimate exit is gaming, and an explicit infeasibility path produced a 54-to-9 result in a separate experiment cited from the ImpossibleBench work on LLMs exploiting test cases. Give the agent an honest way to say "this spec is contradictory," and it has less reason to fake a pass.
Goodhart's law is why the repair loop may not touch the tests
This is the load-bearing rule of the whole design, and it answers the fear most technical founders name first about self-healing CI: what stops the repair agent from weakening a test to force a green result?
Optimizing systems learn to satisfy the measurement rather than the goal — Goodhart's law. The white paper cites Marilyn Strathern's 1997 paper in European Review, "'Improving ratings': audit in the British University system", an anthropological study of the "audit explosion" in British higher education whose most quoted observation is that audit does more than monitor — it has a life of its own that jeopardizes the life it audits. Her formulation of the idea — when a measure becomes a target, it ceases to be a good measure — is thirty years old and describes exactly what an unconstrained repair agent does to a test suite.
So Koinessa's local repair loop (Ralph, live) is bounded by construction. It may fix code, configuration, routing, or infrastructure. It may not lower thresholds, remove meaningful tests, disable scanners, or convert required checks into advisory ones. The rule generalizes beyond repairs: the optimizer must not control the definition of success. The same logic governs model improvement — a champion-challenger arrangement judges alternatives by independent criteria such as verified success rate, repair cycles, and regression rate after deployment, and a human promotes a claim only after reviewing measured evidence. High-impact behavior earns authority through simulation first: a repair agent patches an isolated workspace and passes verification before any shared state changes.
For the founder, the business outcome is that pipeline repair can be delegated without delegating the standard. The repair loop is human-gated automation in the precise sense: it operates autonomously inside a boundary it cannot redraw.
What the standards bodies actually ask for
Is this an idiosyncratic architecture, or an implementation of recognized expectations? The white paper anchors it to two NIST publications.
The NIST AI Risk Management Framework — AI RMF 1.0 (NIST AI 100-1) and its Generative AI Profile (AI 600-1) — is a voluntary framework for managing AI risk organized around govern, map, measure, and manage functions, with the generative-AI profile enumerating risks and suggested actions specific to systems like agentic coding. The NIST Secure Software Development Framework, SP 800-218 v1.1, published February 2022, recommends a core set of secure software development practices to integrate into any SDLC precisely because, as the document itself notes, few SDLC models address software security in detail; SP 800-218A, final in 2024, extends it with a generative-AI community profile.
The white paper's posture toward these frameworks is worth repeating: frameworks are guidance, a control is implemented behavior, evidence proves the behavior occurred, and certification is a separate determination. Koinessa's evidence bundles are built to map onto SSDF-style assurance expectations — when a client, investor, or auditor asks why a release was permitted, the answer is a receipt, not a narrative. No claim of certification or compliance is made.
Risk tiers: the same loop, different pressure
The EG loop does not apply one verification intensity to everything. As the companion post on risk-tiered autonomy covers, every work item in Koinessa carries a machine-readable risk tier, R0 through R3, that deterministically derives its verification profile and approval policy. This risk-adaptive behavior is live end to end (AAV-001, implemented 2026-08-12). The sharp edge: R2 and R3 work cannot even be claimed without a schema-valid task brief — a conversation-to-contract gate enforced inside the claim's compare-and-set — so exploratory conversation can never slide into high-risk implementation.
The loop also eats its own cooking. Verification debt is itself measured: defect-escape, review-load, rework, and lead-time metrics land in the same warehouse as every other receipt. And the evidence manifest accepts domain-pluggable evidence, with firmware and hardware checks as the first extension beyond software CI, under the standing rule that compilation is not proof. One qualifier the paper keeps: its 2026-08-23 repository inventory counts 1,614 git-indexed test or specification files, and that inventory does not claim the suites were rerun.
The takeaway
Failed pipelines consume founder hours because most delivery systems conflate three questions: what broke, what is allowed to fix it, and what proves the fix is real. The EG loop separates them by construction — canonical result states answer the first, bounded repair authority the second, signed evidence the third. Agents move fast inside this system not because they are trusted, but because the boundaries are explicit enough that speed is safe: evidence is the acceptance currency, verification is fail-closed, and the optimizer never controls the definition of success. The full argument is in the Koinessa white paper, section 4.