AGI Theory / v1.1

Multi-Round Audit Convergence: An External Validation Mechanism and Recursive Task Loop toward Engineering AGI

Proposes MRAC as a second-order validation signal and uses non-convergence to trigger decomposition in a recursive task loop toward Engineering AGI.

2026-08-05 2026-08-05

Engineering AGIMulti-Round Audit ConvergenceMRAC

Author: Liu Ming
Date: August 5, 2026

This is the English translation of the original Chinese paper. In case of interpretive differences, the original Chinese version prevails.

Abstract

Current large language models can already perform a substantial range of software-engineering tasks, yet they still struggle to determine reliably whether their own results can be trusted in long-running, complex projects. Neither a successful execution nor a single audit that finds no issue is sufficient to distinguish between “the result is reliable” and “the current audit has simply failed to cover the remaining errors.” This paper proposes Multi-Round Audit Convergence (MRAC): repeatedly auditing, fixing, and re-auditing the same engineering artifact, while observing whether the number, severity, and structural significance of newly discovered valid issues decline overall and eventually remain stable across multiple consecutive rounds under a predefined audit scope.

This paper interprets MRAC as a second-order validation signal. It does not directly prove that an engineering result is absolutely correct. Rather, it provides evidence for judging whether a task, specification (Spec), or pull request (PR) has entered an effective search space that can be reliably covered by a given model, toolset, context, and audit protocol. When audit results continue to fail to converge, the system should not append local patches indefinitely within the original task boundary. Instead, it should stop the current task, return to task decomposition, reduce the search space, and restart. This yields a recursive task loop of “task decomposition - Spec audit - execution - PR audit - merge.”

Two internal software-engineering cases provide preliminary observations. In the first, a Spec continued to expose new P1 and P2 issues across many audit rounds, after which the original task was stopped and decomposed further. In the second, the Spec and PR proceeded to the next stage only after multiple consecutive rounds found no new substantive issues. The paper further proposes an engineering hypothesis: if a complex software project can be recursively decomposed into subproblems that AI can reliably cover, and if task dependencies, state, module boundaries, audits, and rollback mechanisms can be governed by the system, MRAC may serve as a key validation mechanism in an external engineering route toward Engineering AGI. This hypothesis has not yet been validated through complete-project, multi-model, or controlled experiments.

Keywords: Multi-Round Audit Convergence; Engineering AGI; autonomous software engineering; search-space governance; task decomposition; Spec; code review; agent harness

1. Introduction

1.1 An Engineering Definition of Engineering AGI

This paper adopts an engineering definition centered on the delivery of long-running, complex projects:

Engineering AGI is AI capable of autonomously completing complex projects that would otherwise require sustained collaboration by an ordinary human team.

Here, “autonomously” primarily means that project progress no longer depends on humans continuously decomposing tasks, tracking processes, locating errors, and performing local repairs. It does not exclude humans from supplying the initial engineering objective, product intent, permission grants, or high-cost trade-offs that current systems cannot yet resolve independently.

This paper begins with software engineering. This is not because software engineering represents all forms of complex human work, but because code, Specs, PRs, tests, logs, and version histories provide relatively complete engineering artifacts, evidence chains, and rollback conditions, making external validation mechanisms easier to define and evaluate.

At least two non-exclusive routes may lead toward Engineering AGI:

The internal model-capability route: continue expanding the model’s knowledge, reasoning, effective attention, and self-correction capabilities until it can directly complete long-running complex projects and reliably discover its own errors;
The external engineering route: build task decomposition, state management, auditing, rollback, and delivery mechanisms around the model, enabling an AI that still makes mistakes to continue advancing complex engineering work.

This paper does not treat Multi-Round Audit Convergence as the entirety of an external engineering system. Instead, it proposes the following research hypothesis:

MRAC may be one of the key validation mechanisms that enables the external engineering route to form an operational closed loop.

1.2 The Core Difficulty of Autonomous AI Engineering

Current large models can understand code, design solutions, implement features, add tests, and repair explicitly identified problems. On local tasks, they can already perform a substantial share of real engineering work.

The key obstacle to long-running autonomous engineering is not merely whether AI “knows how to do the work,” but rather:

AI cannot reliably determine when it has made a mistake, nor can it reliably distinguish between “the result is correct” and “no error has yet been found.”

In practice, AI may:

omit requirement constraints that are not explicitly present in context;
misjudge system boundaries even when a local solution appears reasonable;
choose a solution that runs in the short term but accumulates structural debt;
mistake local test success for complete delivery when coverage is insufficient;
introduce new failure paths while fixing an existing problem;
repeatedly share the same blind spot because audit perspectives or contexts are too similar.

Engineering AGI therefore requires more than an executor with a lower error rate. It also requires an external mechanism that continuously answers:

Does the current engineering artifact still contain important undiscovered problems?
Is the current task within a range that the AI and audit mechanism can handle reliably?
When the current scope cannot be handled reliably, should the system stop the original task and return to task decomposition to reduce the search space further?

1.3 Three Levels of Claims in This Paper

To avoid conflating preliminary cases, mechanism-level interpretation, and long-term implications, this paper separates its claims into three levels.

Level One: Observed Engineering Phenomena

In the internal project records discussed here, some Specs or PRs showed fewer newly discovered issues after repeated audits and fixes, eventually reaching several consecutive rounds with no new substantive issue. Other Specs continued to expose new medium- or high-severity issues across multiple rounds and did not display a stable downward trend.

Level Two: The Proposed Mechanism-Level Interpretation

This paper proposes that convergence or non-convergence in audit results can be treated as second-order evidence that helps judge whether the current engineering artifact has entered an effective search space that a given model and audit protocol can reliably cover.

This is a mechanistic interpretation, not a fully validated causal law. Convergence may also be caused by insufficient auditor capability, an overly narrow audit protocol, or shared blind spots across rounds. Non-convergence may also arise because constraints continue to change, the audit scope changes, or fixes introduce new problems.

Level Three: A Research Hypothesis toward Engineering AGI

If MRAC can be applied reliably to key engineering checkpoints such as task decomposition, Specs, and PRs, and if it is combined with systems for dependency governance, state management, rollback, and parallel execution, complex projects may be recursively transformed into a sequence of small tasks that AI can reliably cover, enabling long-running autonomous delivery with less human propulsion.

The two cases in this paper provide only preliminary evidence for the first two levels. They are not sufficient on their own to establish the third-level hypothesis.

1.4 Contributions

The main contributions of this paper are:

It formally defines Multi-Round Audit Convergence (MRAC) and distinguishes it from single-round auditing, fixed-round revision, and ordinary quality-assurance stopping conditions;
It interprets the trend across audit rounds as a second-order validation signal that helps judge whether an engineering artifact lies within a reliably coverable search space;
It incorporates non-convergence into the engineering control logic, allowing it to trigger task rollback and further decomposition rather than indefinite patching within the original boundary;
It applies MRAC to key engineering checkpoints such as task decomposition, Specs, and PRs, proposing a recursive loop in which “convergence permits advancement; non-convergence returns the system to task decomposition”;
It presents two preliminary cases from an actual project, while explicitly stating the limits of the current evidence and the requirements for further validation.

2. Conceptual Model

2.1 Effective Search Space

An engineering task usually contains several types of uncertainty at once:

a requirement may admit multiple interpretations;
an implementation may offer multiple solution paths;
a change may affect multiple modules and implicit dependencies;
project history may have created undocumented constraints;
a local fix may alter the distribution of subsequent problems.

This paper refers to the effective set of possibilities that AI must consider, eliminate, or select in order to complete an engineering artifact as the task’s Effective Search Space.

“Search space” here is not a mathematically enumerated set. It is an engineering abstraction describing the decision complexity jointly created by requirement ambiguity, solution branches, dependency scope, failure paths, and implicit constraints.

2.2 Reliably Coverable Search Space

A model does not have a fixed task limit independent of its engineering environment. The range it can handle reliably in a single task also depends on:

the model’s own reasoning and knowledge capabilities;
effective attention and use of context;
available tools and code-retrieval capabilities;
project structure and module boundaries;
external feedback from tests, logs, and static analysis;
completeness of the Spec and the degree to which constraints are explicit;
audit prompts, audit perspectives, and variation across rounds.

This paper therefore uses Reliably Coverable Search Space to mean the task range that an AI can complete, audit, and repair with sufficient stability under a given model, toolset, context, engineering environment, and audit protocol.

Whether a task can proceed reliably depends on a relative relationship:

Has the effective search space of the current engineering artifact been governed so that it does not exceed the stable coverage capability of the current AI system?

This relationship cannot be observed directly. The purpose of MRAC is to obtain indirect evidence about this latent state from the results of repeated audits.

2.3 Why Auditing May Reduce the Search Problem

When implementing a task for the first time, AI usually needs to perform all of the following at once:

interpret the requirement;
select a solution;
locate relevant code;
implement the change;
design tests;
assess compatibility and regression risk.

This is a relatively open-ended generation process.

Once a Spec, design, or PR already exists, the audit objective can be constrained to questions such as:

Were any requirements omitted?
Are the boundaries appropriate?
Are there unhandled failure paths?
Does the implementation violate existing constraints?
Do the tests cover the target behavior?
Has the change introduced new structural problems?

When the target artifact is fixed, context is sufficient, and the audit protocol is effective, auditing often converts an open generation problem into a more narrowly defined defect-search problem. This does not guarantee that the search space is always smaller, nor that the auditor will not share the generator’s blind spots. In many engineering settings, however, it can reduce the number of decisions that must be handled simultaneously in a single round.

An AI that cannot produce a high-quality delivery in one pass may therefore still improve the result iteratively through the following cycle:

Generate a provisionally valid engineering artifact;
Identify problems within a relatively constrained audit space;
Repair the explicitly identified problems;
Re-run a full-scope audit on the modified artifact.

3. Multi-Round Audit Convergence

3.1 Definition

Multi-Round Audit Convergence (MRAC): the phenomenon and decision mechanism in which repeated auditing, fixing, and re-auditing of the same engineering artifact leads to an overall decline in the number, severity, and structural significance of newly discovered valid issues, followed by stability across multiple consecutive rounds under a predefined audit scope.

MRAC has two components:

Phenomenon layer: whether the audit results show an overall decline and enter a stable state;
Control layer: how the system uses convergence or non-convergence to decide whether to advance or return to task decomposition to reduce the search space.

3.2 What MRAC Does Not Prove

MRAC does not prove that an engineering result is absolutely correct, nor is it equivalent to formal verification.

When an engineering artifact appears to have converged, this paper claims only that:

Under the given model, tools, context, audit method, and project conditions, the artifact shows signs of having entered a reliably coverable search space.

The artifact may still contain:

problems missed by every audit round;
failure modes not covered by the audit protocol;
issues that emerge only at runtime, in real-user interaction, or after long-term operation;
product-intent or multimodal constraints that never entered the engineering artifact;
false stability caused by errors in tests or validators.

MRAC should therefore be understood as one component of engineering evidence, not as a universal substitute for testing, runtime validation, human product judgment, or safety review.

3.3 Why Multiple Rounds Are Necessary

A single audit that finds no issue has at least three possible explanations:

The result is already sufficiently reliable;
The audit path in this round failed to cover an existing problem;
The audit protocol, context, or model capability was insufficient to discover the problem.

A single result cannot distinguish among these states.

Multiple audit rounds additionally reveal trends:

Does the number of new issues decline overall?
Does issue severity decrease?
Do structural problems continue to reappear?
Do new failure paths continue to emerge after fixes?
Does the artifact remain stable across different audit perspectives?
Can clean rounds be reproduced consecutively?

Multi-round auditing therefore generates not only additional defect lists, but also a second-order signal about the audit process itself.

3.4 Operationalizing Convergence

At the current stage, MRAC should not be reduced to a single fixed formula. An executable decision should consider at least the following dimensions:

Dimension	Question to Observe
Number of new issues	Is it declining overall, or do many new issues continue to appear?
Issue severity	Are blocking and structural issues giving way to lower-severity details?
Issue structure	Do new issue categories or fundamental boundary conflicts continue to emerge?
Consecutive stability	Are there multiple consecutive rounds with no new substantive issue, rather than one accidental clean round?
Audit coverage	Do later rounds retain full or predefined scope, rather than gradually narrowing until nothing is found?
Round validity	Have invalid rounds caused by tool failure, missing context, or abnormal output been excluded?

The cases in this paper use “multiple consecutive rounds with no new substantive issue” as a practical signal. To remain consistent with recommendations in prior work, a minimum default stopping rule for future experiments may be:

After the audit protocol and scope have been locked, two consecutive full-scope audits find no new substantive issue.

However, “two” should not be understood as sufficient for every task. A stricter stopping condition should also account for task size, issue severity, auditor diversity, runtime tests, and risk level.

3.5 Meaning of Non-Convergence

If new P1, P2, or structural issues continue to appear after many audit rounds, the artifact has at least failed to demonstrate stable coverage.

Possible causes include:

the task is too large;
task or module boundaries are incorrect;
the Spec contains a fundamental design conflict;
key constraints have not been made explicit;
the audit scope or protocol continues to change;
fixes keep introducing new defects;
the current model, tools, or context are insufficient;
model stochasticity creates high variance across audit rounds.

Non-convergence should therefore not be mechanically equated with “the task is necessarily too large.” It first indicates that the current engineering artifact has not demonstrated reliable coverage. For an operational system, the control logic should remain simple:

Under predefined and locked valid audit conditions, continue auditing, fixing, and re-auditing;
Advance to the next stage when the convergence condition is met;
When a predefined non-convergence condition is met, stop the original task, return to task decomposition, reduce the search space, and restart.

Whether the audit protocol is sufficient and whether the constraints are complete are matters of system design and experimental validity. They should be fixed before execution and validated through subsequent research, rather than introduced as dynamic branches that depend on human intervention within the main operating loop.

Under this control logic, non-convergence is not a process failure; it is a valid result that automatically triggers renewed search-space governance.

4. Recursive Task-Governance Loop

4.1 Why Audit Key Engineering Checkpoints

A practical engineering system does not need to audit every intermediate reasoning step independently. A more feasible approach is to audit a small number of key artifacts that freeze engineering state and shape the subsequent search space:

Task decomposition results: determine task boundaries, dependencies, and parallel relationships;
Spec: freezes requirements, design, constraints, and acceptance criteria;
PR: freezes the actual implementation, tests, and code changes.

When each key artifact must satisfy a predefined convergence condition before advancing, many local decisions between checkpoints can be indirectly inspected through the subsequent frozen artifacts.

4.2 Basic Process

%%{init: {"theme":"base","themeVariables":{"fontFamily":"Inter, Arial, Helvetica, sans-serif","fontSize":"17px","lineColor":"#64748B","textColor":"#0F172A","primaryColor":"#FFFFFF","primaryTextColor":"#0F172A","primaryBorderColor":"#94A3B8"},"flowchart":{"curve":"basis","nodeSpacing":34,"rankSpacing":42,"htmlLabels":false,"useMaxWidth":true}}}%%
flowchart TB
    accTitle: MRAC recursive task-governance loop
    accDescr: An engineering objective proceeds through task decomposition, Spec multi-round audit, task execution, PR multi-round audit, and merge. If the Spec or PR fails to converge, or if the engineering objective remains incomplete, the system continues task decomposition.

    A(["Engineering Objective"]) --> B["Task Decomposition"]
    B --> C["Generate Task Spec"]
    C --> D["Spec MRAC: Audit - Fix - Re-audit"]
    D --> E{"Spec Converged?"}

    E -- "Yes" --> F["Execute Task and Submit PR"]
    F --> G["PR MRAC: Audit - Fix - Re-audit"]
    G --> H{"PR Converged?"}

    H -- "Yes" --> I["Merge into Mainline"]
    I --> J{"Engineering Objective Complete?"}
    J -- "Yes" --> K(["Delivery Complete"])

    E -- "No" --> R["Continue Task Decomposition"]
    H -- "No" --> R
    J -- "No" --> R
    R -.-> B

    classDef terminal fill:#0F172A,color:#FFFFFF,stroke:#0F172A,stroke-width:1.5px;
    classDef process fill:#FFFFFF,color:#0F172A,stroke:#94A3B8,stroke-width:1.25px;
    classDef artifact fill:#F8FAFC,color:#334155,stroke:#CBD5E1,stroke-width:1.25px;
    classDef audit fill:#EFF6FF,color:#1E3A8A,stroke:#3B82F6,stroke-width:1.5px;
    classDef decision fill:#FFF7ED,color:#9A3412,stroke:#F97316,stroke-width:1.5px;
    classDef delivery fill:#F0FDF4,color:#166534,stroke:#22C55E,stroke-width:1.5px;
    classDef recycle fill:#F8FAFC,color:#334155,stroke:#64748B,stroke-width:1.25px,stroke-dasharray:5 3;

    class A,K terminal;
    class B,F process;
    class C artifact;
    class D,G audit;
    class E,H,J decision;
    class I delivery;
    class R recycle;

    linkStyle 13 stroke:#64748B,stroke-width:1.5px,stroke-dasharray:6 4;

The process can be summarized as:

Task decomposition -> Spec multi-round audit -> execution -> PR multi-round audit -> merge.

Specifically:

A Spec enters execution only after it converges;
If the Spec does not converge, the original task is stopped and the system returns to task decomposition;
PR auditing performs audit, repair, and re-audit within the current task boundary; if a predefined non-convergence condition is reached, the system likewise returns to task decomposition;
A PR may be merged only after it converges and passes other necessary validation;
If the project objective is not yet complete, the system continues to decompose and execute the remaining objective.

In the figure, the vertical backbone represents forward delivery. The “Continue Task Decomposition” node consolidates three recursive conditions: Spec non-convergence, PR non-convergence, and an unfinished engineering goal. The dashed line indicates that the system returns to task decomposition. The main operating loop contains no branch that depends on ad hoc human intervention.

4.3 Role of Recursive Decomposition

If a task exceeds the current AI system’s stable coverage capability, simply increasing the number of execution rounds may not solve the problem. Recursive decomposition transforms a large effective search space into multiple smaller search spaces with clearer boundaries and governable dependencies.

Ideally, each subtask should:

deliver a clearly defined unit of functionality;
have describable dependencies;
support an independent Spec;
support independent execution and auditing;
support rollback;
preserve the overall module boundaries when merged.

MRAC is therefore more than a quality-control method that answers “when should auditing stop?” It may also serve as a signal for determining task scale and governing recursive decomposition.

5. Preliminary Project Cases

5.1 Nature of the Data and Limits of Interpretation

The following cases come from internal audit records in the author’s actual software project. The complete repository, audit prompts, model versions, context-loading process, issue-severity rules, and full repair evidence have not yet been made public. The cases are therefore suitable as preliminary observations and illustrations of the mechanism, but they do not constitute independently reproducible empirical proof.

P1 and P2 in the tables are internal project severity labels. Because the present version does not provide a complete operational definition of severity, no claim is made that they are comparable across projects.

Rounds marked “result discarded” are excluded from the valid audit results. The exact discard criteria should be specified in a future public experimental protocol.

5.2 Case One: Persistent Spec Non-Convergence Triggers Decomposition

Task: A5PR1 Unification of Exit Ordering

Audit Round	Newly Discovered Issues
R2	P1 × 2, P2 × 1
R3	None
R4	P1 × 1, P2 × 2
R5	P2 × 3
R6	P2 × 2
R7	P1 × 1, P2 × 1
R8	P1 × 1, P2 × 1
R9	Result discarded
R10	P1 × 1
R11	P1 × 2, P2 × 2
R12	P1 × 1, P2 × 2
R13	P1 × 2, P2 × 1
R14	P2 × 2

This Spec produced one round with no new issue at R3, but subsequent rounds continued to reveal P1 and P2 issues. By R14, the number of newly discovered issues still had not formed an interpretable and stable downward trend.

The record supports at least two judgments:

One round with no new issue is insufficient evidence of convergence;
Under the current audit conditions, the Spec did not demonstrate stable coverage.

The project subsequently stopped adding patches within the original Spec and decomposed the task further. According to the project records, the resulting subtasks separately completed Spec auditing, execution, and merge.

The case is consistent with the MRAC control logic:

When valid rounds continue to reveal new medium- or high-severity issues, a clean result in one round should not be interpreted as completion; the current search space should be governed again.

However, this case alone cannot exclude alternative explanations such as changes in the audit protocol, model stochasticity, or new issues introduced by prior fixes.

5.3 Case Two: Convergence of Both Spec and PR

Task: B2PR-01 Retirement of the Stage Failure Surface

5.3.1 Spec Audit Record

Audit Round	Newly Discovered Issues
R1	P1 × 2, P2 × 2
R2	P1 × 1, P2 × 1
R3	None
R4	Result discarded
R5	None
R6	P1 × 1
R7	None
R8	None

The number of newly discovered issues decreased from R1 to R2, and R3 temporarily found no new issue. However, R6 later found another P1, showing that one clean round, or even isolated clean rounds, remained insufficient for stable confirmation of convergence.

After the R6 issue was repaired, R7 and R8 found no new issue in two consecutive rounds. The project therefore judged the Spec to have met its practical convergence condition and advanced it to execution.

5.3.2 PR Audit Record

Audit Round	Newly Discovered Issues
R1	P2 × 1
R2	P2 × 1
R3	None
R4	Result discarded
R5	None
R6	None

The first two PR rounds each found one P2 issue. After the repairs, later valid audits found no additional issue. The PR was judged to have converged and was merged.

5.4 Limited Conclusions Supported by the Two Cases

Without exceeding the current evidence, the cases jointly support the following preliminary observations:

A single round with no new issue should not be interpreted directly as convergence;
Multi-round trends in issue count and severity provide more information than a single-round result;
Continued discovery of new P1 and P2 issues can serve as a warning that the current artifact has not been reliably covered;
Multiple consecutive rounds with no new substantive issue can serve as one practical signal for advancing to the next stage;
Non-convergence can trigger task decomposition rather than indefinite patching within the original artifact.

The cases do not establish that:

MRAC necessarily improves final runtime quality;
two consecutive clean audits are sufficient for every task;
non-convergence is necessarily caused by an oversized task;
multiple rounds by the same model are equivalent to independent search paths;
the mechanism can already cover a complete large project.

6. Relationship to Prior Work

6.1 Research on Iterative Audit Convergence

Elias Calboreanu submitted the arXiv preprint on May 12, 2026, and the paper Iterative Audit Convergence in LLM-Managed Multi-Agent Systems: A Case Study in Prompt-Engineering Quality Assurance was formally published in Software on June 18, 2026.[1]

The study audited the prompt specification of the AEGIS multi-agent orchestration system. The audited artifact consisted of eight documents totaling 7,152 lines. Across nine audit rounds, the study found 51 consistency defects, with the following number found in each round:

15, 8, 12, 2, 8, 1, 4, 1, 0.

The study documented a non-monotonic convergence process and used one full-scope audit with no new finding as the stopping rule in the case. It also recommended that future replication studies adopt the stricter rule of “two consecutive full-scope audits with no new finding.”

The paper explicitly limits its claims: audit convergence demonstrates only internal consistency under the coverage of a locked protocol; it does not prove absolute correctness, and the study did not measure whether the repairs improved runtime behavior. The study covered a single system, the audit protocol evolved during the case, and the same model family participated in both specification writing and auditing. The author therefore called for future multi-system studies, single-pass full-scope controls, and human verification.[1]

6.2 Automated Plan Reviser Pro

The open-source project Automated Plan Reviser Pro (APR) performs multi-round AI revision of complex Specs and retains the revision history. Its convergence analysis combines three weighted signals:

output-size trend: 35%;
revision velocity: 35%;
adjacent-round content-similarity trend: 30%.

APR uses these signals to generate a convergence score estimating specification stability.[2]

APR demonstrates that “multi-round Spec revision with quantified stability trends” has already entered public engineering practice. However, shorter output, slower revision, and higher textual similarity primarily measure stability in document change. They do not directly demonstrate declining issue severity, coverage of engineering constraints, or entry into a reliably coverable search space.

6.3 Distinction from Prior Work

This paper does not claim to be the first to observe the basic phenomenon that repeated auditing or revision may stabilize, nor does its contribution depend on priority over the exact terminology.

The intended advances are:

Interpreting multi-round audit results as second-order evidence about whether an engineering artifact has entered a reliably coverable search space;
Turning non-convergence from an anomaly in quality assurance into a signal that task boundaries and search space must be governed again;
Applying MRAC to key engineering checkpoints such as task decomposition, Specs, and PRs;
Forming a recursive task-governance loop in which “convergence permits advancement; non-convergence returns the system to task decomposition”;
Proposing this loop as a candidate core mechanism for an external engineering route toward Engineering AGI.

Compared with Calboreanu’s study, the focus here is not merely to describe an audit curve in a prompt-specification system, but to examine how convergence can participate in task-scale decisions and long-running engineering control. Compared with APR, the focus is not merely the stability of Spec text, but changes in the number, severity, and structure of newly discovered valid issues, together with the task-governance implications of non-convergence.

7. Research Hypothesis toward Engineering AGI

7.1 From Local Tasks to Long-Running Projects

Suppose a complex software-engineering objective can be decomposed into subtasks with clear boundaries and dependencies, and each subtask can produce an auditable Spec and PR. The system can then execute the following recursively:

Decompose the remaining engineering objective into tasks;
Audit task boundaries and the Spec;
If the Spec does not converge, stop the original task and decompose it further;
Execute the task after the Spec converges;
Audit the resulting PR;
If the PR reaches a predefined non-convergence condition, stop the original task and return to task decomposition;
Merge the PR after it converges and passes other validation;
Continue with the remaining engineering objective.

In such a system, AI does not need to traverse the entire search space of a complete project in one pass. The system needs only to:

detect when the current boundary has not been reliably covered;
recursively reduce the problem to a local scope;
execute, audit, and repair within that local scope;
preserve state, dependencies, evidence, and rollback points.

7.2 Why This May Reduce the Requirement for a Perfect Model

Waiting for a model alone to achieve Engineering AGI would require the model not only to complete long-running complex tasks, but also to determine reliably whether it is correct, while managing state, dependencies, and error recovery over extended execution.

The external engineering route lowers this requirement. It does not require a model that never makes mistakes. It requires a model that, within a governed local search space, has three capabilities:

Complete a task with a clear boundary;
Discover some unresolved problems within a constrained audit scope;
Repair problems that have been explicitly identified.

The project experience in this paper shows only that current models exhibit these capabilities on some tasks. It does not justify the claim that they already cover most software-engineering problems.

7.3 Conditions Required for the Hypothesis to Hold

The hypothesis that MRAC can contribute to Engineering AGI depends on at least the following conditions:

complex projects can be recursively decomposed into governable engineering artifacts;
module boundaries and task dependencies do not become unmanageable as a result of decomposition;
auditors can cover major failure modes through sufficiently diverse search paths;
auditing, fixing, and re-auditing do not introduce new problems faster than they remove them;
tests, runtime validation, and product constraints can enter the evidence loop;
the system can manage long-term state, parallel execution, merge order, and rollback;
audit costs remain acceptable as project scale grows;
shared “stable but wrong” blind spots can be controlled through multiple models, tool-based validation, or human sampling.

If any one of these critical conditions remains persistently unsatisfied, MRAC may remain a high-quality AI development process without being sufficient to support Engineering AGI.

7.4 Conclusions Not Yet Demonstrated

This paper has not demonstrated that:

MRAC can cover a complete, long-running, large-scale software project;
every engineering problem admits a feasible recursive decomposition;
search space can always be governed so that it remains within model capability boundaries;
convergence signals have a stable causal relationship with final defect rates, runtime quality, or business outcomes;
the audit cost and delivery speed of MRAC outperform alternative governance methods;
non-code constraints such as product intent, visual quality, safety, and organizational collaboration can be incorporated into the loop with equal effectiveness.

“MRAC may lead toward Engineering AGI” should therefore be understood in the current version as a research hypothesis with preliminary engineering motivation, but still requiring systematic validation.

8. Limitations and Threats to Validity

When the same model or similar prompts are used across multiple audit rounds, the rounds are not equivalent to genuinely independent samples. They may repeat the same reasoning path and share the same blind spot. Multiple rounds with no new issue may merely show that the auditor cannot discover the remaining problems.

8.2 Evolving Audit Protocols

If the audit prompt, context scope, or focus changes from round to round, the change in issue count may be caused by protocol changes rather than by increasing stability in the engineering artifact. Future experiments should lock the core protocol before repairs begin and separately record intentional expansions of audit scope.

8.3 New Problems Introduced by Repairs

A newly discovered issue is not necessarily an issue missed in the prior round; it may have been introduced by the previous repair. The convergence curve is therefore shaped jointly by discovery capability and repair disturbance.

8.4 Subjectivity in Severity Classification

Severity labels such as P1 and P2 require clear operational criteria and inter-rater consistency checks. Otherwise, an apparent decline in severity may reflect changes in the auditor’s or recorder’s judgment.

8.5 Arbitrariness of the Stopping Rule

Two consecutive full-scope audits with no new issue are a stricter practical rule than one clean audit, but there is currently no evidence that “two” is the optimal threshold across tasks. High-risk tasks may require more rounds, multi-model auditing, or external validators.

8.6 External Validity

This paper contains only two internal cases from the same project environment. Project architecture, code quality, testing capability, models, tools, and author experience may all affect the results. The findings cannot be directly generalized to other teams, languages, repositories, or engineering domains.

8.7 Absence of Control Groups

There has not yet been a systematic comparison among:

one full-scope audit;
a fixed number of audit rounds;
MRAC with adaptive stopping;
human review;
parallel multi-model auditing;
direct delivery without auditing.

The current evidence therefore cannot quantify the net benefit of MRAC relative to alternative processes.

8.8 Difference between Process Convergence and Result Correctness

Process convergence describes only the stabilization of audit findings. Final correctness still requires tests, runtime monitoring, formal constraints, user feedback, and other external evidence. The two must not be conflated.

9. Future Research Plan

9.1 Phase One: Lock a Reproducible Protocol

Future work should publish and fix:

the audited artifact and context-loading method;
model, version, temperature, and reasoning settings;
audit prompt and audit perspectives;
P0/P1/P2 severity rules;
issue deduplication and “new issue” criteria;
invalid-round and discarded-round criteria;
repair workflow;
convergence stopping rule;
raw audit outputs and version differences.

9.2 Phase Two: Expand the Case Base

Across multiple tasks, modules, and projects, future work should record:

the number and severity of newly discovered issues in each round;
changes in issue categories;
regression defects after repairs;
number of rounds required for convergence;
whether decomposition after non-convergence improves the outcome;
token, time, and compute cost;
post-merge defects and rework.

9.3 Phase Three: Establish Controlled Experiments

At minimum, future experiments should compare:

one full-scope audit;
a fixed two-round or multi-round audit;
MRAC with dynamic stopping;
multi-round auditing by the same model;
multi-model or multi-perspective auditing;
human, AI, and hybrid auditing.

Primary outcome metrics should include final defect-discovery rate, post-merge defects, rework, total cost, delivery time, and error severity, rather than only the number of audit rounds.

9.4 Phase Four: Complete-Project Validation

A representative complete software project should be used to validate whether:

engineering objectives can be continuously decomposed into auditable tasks;
both Specs and PRs can be incorporated into the same convergence loop;
non-convergence can reliably trigger effective decomposition or rollback;
multi-task dependencies, parallel execution, and merge order can be governed;
the system can run for extended periods with limited human propulsion and deliver in stages;
human blocking items, confirmation items, and rollback costs can be explicitly recorded.

Only after this phase can MRAC be discussed more convincingly as having developed from a local quality mechanism into a systems foundation for Engineering AGI.

10. Conclusion

One of the core limitations of current AI software engineering is not that models are wholly incapable of executing tasks, but that they cannot reliably determine whether their own results can be trusted. Neither a successful single execution nor a single audit with no issue is sufficient to establish that an engineering artifact is reliable.

MRAC repeatedly performs auditing, fixing, and re-auditing, while observing changes in the number, severity, and structure of newly discovered issues. This adds a second-order evidence signal to the engineering system. Convergence does not prove absolute correctness, but it may indicate that the artifact has entered a reliably coverable search space under the given conditions. Non-convergence triggers rollback to task decomposition and further reduction of the search space.

The basic loop is therefore:

Execute, audit, fix, and observe convergence; when convergence cannot be achieved, return to task decomposition and repeat the process.

This paper proposes that, if this mechanism can reliably cover task decomposition, Specs, and PRs, and can be integrated with dependency management, state management, parallel execution, and rollback systems, complex projects may be recursively transformed into local tasks that AI can handle reliably. Engineering AGI may therefore depend not only on waiting for a perfect model capable of doing everything in one pass, but also on building an external engineering system that continuously identifies capability boundaries, reduces search spaces, and validates stage-level convergence.

At present, this remains an engineering hypothesis derived from local project observations. The critical next step is not to expand the claim further, but to publish protocols, enlarge the sample, establish controls, and determine whether convergence signals can reliably predict final delivery quality and autonomous progress across complete projects.

Appendix: Chinese-English Terminology

Chinese Term	Fixed English Term	Description
多轮审计收敛	Multi-Round Audit Convergence (MRAC)	Core term of this paper
多轮审计	Multi-Round Auditing	Repeated audit, repair, and re-audit of the same artifact
工程 AGI	Engineering AGI	Engineering definition centered on long-running complex-project delivery
自主软件工程	Autonomous Software Engineering	Long-running autonomous execution in software engineering
有效搜索空间	Effective Search Space	Effective set of possibilities that must be handled for the current artifact
可稳定覆盖的搜索空间	Reliably Coverable Search Space	Range that can be handled reliably under given system conditions
搜索空间治理	Search-Space Governance	Reducing complexity through boundaries, decomposition, context, and tools
递归任务治理	Recursive Task Governance	Returning to decomposition or boundary governance when convergence fails
二阶验证信号	Second-Order Validation Signal	Evidence generated by trends across rounds rather than by a single result
工程固化点	Engineering Checkpoint / Frozen Artifact	Auditable state nodes such as task decomposition, Spec, and PR

Core Definition