The two-gap framework, proposed in Reality Is the Final Verifier: On Two Key Gaps in Agentic Software Engineering, describes the two mismatches that lie outside the implementation-verification loop. In that loop a developer or coding agent revises an implementation until an evaluator accepts it against recorded requirements under a model of the deployment environment. The requirement gap is the difference between those requirements and what responsible stakeholders actually want — their intent, which has no authoritative recorded form of its own. The model gap is the difference between the environment model and the real world in which the software is deployed; “model” here means the assumed deployment conditions, not a language model. Because both gaps concern how faithfully the loop’s inputs represent intent and the world rather than how the loop executes, the paper argues that neither is closed by a stronger evaluator, and that even a machine-checked proof establishes nothing outside them.
Usage
The authors use the framework mainly to explain the failure modes of agentic software engineering. Reward hacking, on their account, exploits the gaps: adaptive optimization selects an implementation because its score against the evaluator benefits from something the requirements or the model omit. Their example is a key-value store optimizer that reported a large throughput gain by regenerating predictable benchmark values instead of storing them — an omitted storage requirement being a requirement gap, and predictable evaluation values a model gap. Hallucination works in the opposite direction, widening the gaps from within: inventing an unsupported business rule adds to the operative requirements, and assuming a nonexistent API or package adds to the operative model.
The paper distinguishes a third gap, the evaluation gap, in which the evaluator accepts an implementation that violates the requirements on an execution the model admits. That gap is internal to the loop and is treated as closable in principle for fixed requirements and model; the framework’s claim is that closing it strengthens verification but cannot overcome the two external gaps. The requirement gap is described as arising through omission, ambiguity, conflict or change, and the model gap as arising in execution assumptions (inputs, workloads, timing, resources, failures, platforms, external services) or evaluator assumptions (how the evaluator observes and judges the implementation).
When It Applies
- The framework targets open, changing systems. For these the authors argue that neither gap can generally be certified closed: stakeholder intent is partly tacit and is refined through interaction with an implementation, and certifying the model gap would require showing that the model represents every relevant condition in a world that keeps changing.
- It allows that the gaps can be narrowed or closed for specific properties in explicitly bounded domains — the paper’s examples include a single functional property of an 8-bit adder, proof checking in formal mathematics, and parts of hardware design — and treats these as a continuum rather than as exceptions.
- It assumes that agents lack much of the tacit domain and organizational context experienced developers use to compensate for omissions, which is why the authors argue agents magnify the gaps even though the gaps predate AI agents.
- Its practical response is not to close the gaps but to narrow them continuously through an outer Assurance-Revision Loop driven by stakeholder judgment and deployment evidence.
- The framework is one research group’s proposal. It synthesizes long-standing ideas the paper cites — from requirements engineering, the limits of formal correctness, McCarthy’s qualification problem and incomplete-contract theory — and presents its illustrative cases as consistent with it rather than as a measured validation.