# Quality Signal Density in Autonomous Verification Pipelines: A Production Observational Study of QA-to-Build Ratios
**Vokrix Research (vokrix.co)** Technical Report — Observational Study Series Subject of study: a production autonomous software development system operated by a single organization
---
1. Introduction
Autonomous software development pipelines increasingly perform their own verification work. Rather than relying solely on human review, such systems execute scripted and model-driven checks, record outcomes, and in some configurations initiate corrective iterations without human intervention. The research literature on continuous delivery and continuous deployment has long examined the relationship between delivery frequency, test coverage, and operational stability, and a substantial body of work has considered how verification should be organized when release cadence increases (Lvov, 2026; Mukka, 2025; Neelapu, 2024). A smaller but rapidly expanding literature addresses verification specifically for agentic and large-language-model-driven systems, where the verification target is not only deterministic software behavior but also probabilistic system output (Kunda, 2025; Bandi Sudakara, 2024; Pandhare, 2025).
Across this literature, the dominant unit of analysis is either the test, the release, or the defect. The present study takes a different unit: the QA event counted against a completed build. The quantity of interest is *quality signal density* — the number of QA verification events executed per completed build — and its descriptive relationship to the corrective workload recorded against those builds. This framing differs from iteration-count studies, which analyze how many build cycles are required to reach a terminal state. Density framing instead asks how much verification instrumentation is applied per unit of delivered output, and whether that instrumentation co-occurs with less recorded corrective work.
The literature search conducted for this report did not identify a published production-scale study that treats QA-events-per-build as the primary explanatory variable and fix-history entries per build as the outcome. Existing continuous delivery research has examined architecting practices (An Empirical Study of Architecting for Continuous Delivery and Deployment, 2018), deployment challenges (Beyond Continuous Delivery: An Empirical Investigation of Continuous Deployment Challenges, 2017), and the principles and practices of continuous delivery and deployment (An empirical study on principles and practices of continuous delivery and deployment, 2016). Enterprise QA research has examined AI-augmented assurance (Singireddy & Sivagnanam, 2025), agentic autonomy under policy governance (Kunda, 2025), and multi-dimensional evaluation of autonomous agents (Bandi Sudakara, 2024). Metrics-oriented work has examined hybrid QA frameworks built on software metrics (Tyagi & Singh, 2026), and test-automation research has argued for intelligent, scalable automation as system complexity grows (Natarajan, 2020). None of these studies, as documented in their available abstracts, reports a QA-to-build density measure derived from production telemetry of an autonomous pipeline, nor relates such density to a fix-history record. This study therefore addresses a gap best characterized as a shortage of empirical production-scale data rather than a theoretical void: the concepts exist in the literature, but published operational density figures for autonomous pipelines are not established.
The contributions of this report are threefold and deliberately descriptive. First, it documents the QA-to-build ratio observed in one production autonomous pipeline, expressed in explicit units and with its derivation stated. Second, it reports the distribution of iteration counts across 500 build attempts alongside QA disposition and fix-history counts across 46 builds, while being explicit that these two record sets have different denominators and no documented join key in the material available. Third, it evaluates whether the stated hypothesis is answerable from the available records and reports the answer plainly: the hypothesis specifies a density regime that the observed aggregate does not enter, so the substitution claim remains untested rather than supported.
The report does not claim that verification density causes reductions in corrective work. The design cannot support such a claim. It reports what was counted, how the ratios were derived, and where the data cannot answer the question posed.
---
2. Related Work
**Continuous delivery, deployment, and verification practice.** Empirical work on continuous delivery has examined the architectural and organizational conditions under which organizations deliver software frequently and reliably. The empirical study of architecting for continuous delivery and deployment (2018) investigates how organizations adopt continuous delivery and continuous deployment practices in pursuit of higher delivery frequency and reliability. A related empirical investigation into continuous deployment challenges (2017) extends this line beyond continuous delivery, examining the difficulties organizations encounter when deployment itself is automated. Earlier empirical work on the principles and practices of continuous delivery and deployment (2016) establishes the practice baseline against which later studies are positioned. Taken together, this body of work establishes that delivery-frequency gains are accompanied by structural and procedural demands, but it does not, in the material available, quantify verification events per delivered unit. The relevance to the present study is directional: it establishes that increased automation of delivery is accompanied by increased verification demands, without supplying a density benchmark.
**Continuous verification and test coverage at scale.** Mukka (2025) examines continuous verification as a practice for ensuring software quality at speed and scale, exploring how engineering teams automate assurance in DevOps contexts. Lvov (2026) frames the tension between the speed of delivering changes and the operational stability of systems as a fundamental constraint on DevOps practice, and takes high test coverage within continuous integration and deployment pipelines as its subject. These two works are the closest conceptual antecedents to the present study: both treat verification as a variable whose quantity matters, and both situate that quantity against delivery velocity. Neither, as documented in the available abstracts, reports a per-build verification density figure or relates it to a corrective-work measure. The present study supplies a production observation in that space, at the cost of the generality that multi-organization studies can offer.
**Measurement frameworks and QA economics.** Tyagi and Singh (2026) propose a hybrid QA framework that combines traditional and Agile software practices and uses software metrics to improve quality, performance, and reliability. The analytical QA model integrated into the V-Modell XT (2016) argues that economic models of quality assurance can support decision-makers by grounding QA planning in economic factors of the product. These works motivate measuring verification effort explicitly rather than treating it as an unexamined constant, which is the methodological position adopted here. They do not, however, provide empirical production values for the specific ratio examined in this report.
**Automation and AI in verification.** Natarajan (2020) argues that test automation must be intelligent, scalable, and efficient given growing software complexity, and examines machine learning, natural language processing, and reinforcement learning as means to that end. Singireddy and Sivagnanam (2025) address quality at enterprise scale, noting that traditional QA approaches grounded in manual verification and static automation face new challenges as enterprise software ecosystems grow, and propose AI-augmented assurance. Neelapu (2024) measures the effect of continuous integration and continuous deployment integration on QA efficiency through a case study of automated testing and deployment. Bhagwat and Changappa (2026) present an automated framework for security compliance and quality assurance in DevSecOps pipelines designed for safety-critical avionics software. Automating Software Code Deployment Using Continuous Integration and Continuous Delivery Pipeline for Business Intelligence Solutions (2020) and the introductory treatment of continuous integration and continuous deployment (2025) describe the pipeline infrastructure within which such verification executes. These works establish that automating verification is both feasible and increasingly expected. Their focus is on the construction and capability of automation rather than on the population density of verification events relative to delivered builds.
**Autonomous and agentic verification.** Kunda (2025) describes a shift in the enterprise software landscape from deterministic, script-based automation toward probabilistic, agentic autonomous systems, and offers a policy-governed approach to autonomous quality assurance. Bandi Sudakara (2024) notes the rapid adoption of large language models and autonomous agents in enterprise software engineering and proposes a multi-dimensional evaluation framework covering reliability, safety, and quality. Pandhare (2025) argues that as enterprises embed large language models in core operations, scalable quality assurance pipelines for AI systems become urgent. Gupta and Vanteru (2026) examine LLM coding assistants in AI-assisted development workflows and measure the impact of hallucination on those workflows. These four works speak most directly to the setting examined here — verification performed by and for autonomous systems — and they collectively argue that evaluation must be structured and measured. They do not report production QA-to-build density, and they do not report fix-history counts as an outcome measure in an autonomous build pipeline. The remaining consideration of verification as a formal program of verification and validation activities (The Software Quality Assurance Program: Software Verification and Validation Activities, 2002) and the systematic review of causal reasoning in software quality assurance (2024) situate the present descriptive study within a field that acknowledges quality assurance as an organized, measurable activity and that is actively exploring causal inference methods within it. The present study deliberately stops short of causal inference.
---
3. Study Design and Data Collection
3.1 Design
This is a cross-sectional, observational analysis of anonymized production records from a single autonomous software development system operated by one organization. No intervention was applied, no condition was assigned, and no comparison group was constructed. The analyst had access to aggregate summary tables exported by the operating organization, not to raw event streams, source code, internal state, or the system's runtime configuration. All system descriptions in this report are therefore limited to the observable surface: counts of inputs and outputs, the units in which they were recorded, and the rates derivable from those counts.
3.2 Record sets
Four primary record sets were analyzed.
*Build iteration telemetry.* Records covering 500 build attempts. For each attempt, an iteration count was available at the aggregate level. Reported statistics comprise the mean, median, minimum, maximum, and the number of attempts falling below and above specified iteration thresholds.
*QA execution records.* Records of QA verification events, reported as 1,000 executed QA checks, together with a pass rate and a fail rate, and a list of the most frequently failing named checks with occurrence counts.
*QA disposition records.* Terminal or near-terminal QA status assigned to builds, reported as counts of failed, escalated, and pending dispositions, together with a count of builds labeled as verified.
*Fix-history records.* Counts of builds that required at least one corrective fix attempt, the mean number of fix attempts when at least one was required, and the maximum number of fix attempts recorded against a single build.
Two secondary record sets were also available and are reported for context only: 500 collected intelligence signals with an average score and a three-category distribution, and 82 deployed production capabilities distributed across 17 categories.
3.3 Units and denominators
The unit of analysis for iteration statistics is the *build attempt*. The unit of analysis for QA disposition and fix-history statistics is the *build* as recorded in the QA and fix records, of which 46 are reported. The unit of analysis for QA execution is the *QA check*. The unit of analysis for corrective workload is the *fix attempt*.
These units are not interchangeable, and the denominators differ. Iteration telemetry is reported against 500 build attempts; QA disposition and fix statistics are reported against 46 builds. The internal consistency of the source tables supports this reading: the iteration thresholds sum consistently with a 500 denominator (314 of 500 equals 62%, 386 of 500 equals 77%, and 62 of 500 equals 12%), while the QA disposition and fix counts sum consistently with a 46 denominator (39 of 46 equals 84%). The source tables do not document a join key linking the two record sets, and the analyst did not have access to one. The present report therefore treats them as two parallel views of the same system observed over an unspecified common window rather than as a single linked dataset.
3.4 Derived quantities and their derivation
One derived quantity is central to this study: the QA-to-build ratio. It is computed as the reported number of executed QA checks divided by the reported number of builds with QA records, yielding approximately 21.7 QA checks per build. This figure is a derivation from two reported totals, not an independently observed measurement, and it is labeled as derived wherever it appears.
A second derived quantity is the complement of the fix-requiring builds: 46 minus 39 equals 7 builds with no recorded fix attempt. This is likewise a derivation.
A third derived quantity appears only in the consistency check of Section 4.5: 5% of 1,000 checks arithmetically implies approximately 50 failing checks. This figure is used solely to assess whether the reported failing-check list is complete, and no substantive inference is drawn from it.
3.5 Time period and collection
The extraction window for the records was not enumerated in the material made available to the analyst, and the study therefore treats the dataset as a single cross-sectional snapshot of one production state rather than as a time series. No seasonality, trend, or drift analysis was possible. Records were supplied in anonymized, aggregated form by the operating organization. No personally identifiable information was present, and no human subjects were involved.
3.6 Analysis approach
Analysis is descriptive. Counts and rates are reported as supplied; ratios are derived from supplied totals with the derivation stated. No hypothesis tests, confidence intervals, regression models, or effect-size estimates were computed, because the source material consists of summary tables rather than the individual-level observations that such procedures require. Where the data cannot answer a question, that is stated rather than estimated.
3.7 Hypothesis operationalization
The hypothesis under test states that autonomous build pipelines with more than 50 QA events per completed build exhibit proportionally fewer fix-history entries per build. Operationalizing this requires three quantities: the observed QA-to-build density, which the data supply as a derived aggregate; the proportion of builds with fix-history entries, which the data supply directly; and an internally comparable measure of fix entries per build, which the data supply only partially, as a conditional mean among builds that required at least one fix attempt. The third quantity is therefore available in a restricted form, a point revisited in Section 6.
---
4. Results
4.1 QA-to-build density
The records report 1,000 executed QA checks and 46 builds with QA records. The derived ratio is approximately 21.7 QA checks per build. The hypothesis specifies a density regime of greater than 50 QA events per completed build. The observed aggregate density falls below that threshold. The threshold condition of the hypothesis is therefore not satisfied by the observed data.
4.2 QA execution outcomes
Across the 1,000 executed checks, the reported pass rate is 94% and the reported fail rate is 5%. The two rates sum to 99%, leaving approximately one percent of checks unattributed in the reported summary. The analyst cannot determine from the available records whether the residual reflects rounding, checks that did not reach a terminal outcome, or checks whose outcome was recorded in a category not included in the pass/fail summary. This discrepancy is reported as an observation about the source data, not as a finding about the system.
Failing checks are distributed across named labels. The five most frequently failing checks, with occurrence counts, are: "Dashboard screenshot present" (10), "AI assistant responds" (10), "AI assistant button found" (7), "QA reasoning" (4), and "DOM checks (dashboard)" (2). No single named check exceeds 10 occurrences, and the five named checks together account for 33 labeled failures. QA failures were recorded against 17 unique products.
4.3 QA dispositions
Of the 46 builds, dispositions are reported as follows: 27 failed, 12 escalated, and 6 pending. These three categories sum to 45, leaving one build without a disposition recorded in the supplied summary. Eight builds, corresponding to 17% of the 46, are labeled as verified.
The disposition distribution is notable in one respect: escalated and pending dispositions together (18 builds) exceed the 8 verified builds. Terminal QA outcomes that indicate a completed, verified state thus form a minority of recorded dispositions.
4.4 Corrective workload
Fix-history records show that 39 of 46 builds, or 84%, required at least one fix attempt. The complementary set — builds with no recorded fix attempt — comprises 7 builds, derived as 46 minus 39. Among builds that required corrective work, the mean number of fix attempts is 2.3, and the maximum recorded on a single build is 7.
Two observations follow directly from these counts. First, the majority of builds in the QA and fix record set required corrective intervention. Second, corrective effort where it occurred was modest in magnitude, with a conditional mean of 2.3 and a maximum of 7 — that is, no build in the record set required a large number of corrective iterations.
4.5 Record consistency
Three consistency observations were made during analysis and are reported for transparency.
The QA disposition categories sum to 45 against a stated denominator of 46. The pass and fail rates sum to 99%. The five named failing checks account for 33 labeled failures; the reported fail rate of 5% applied to 1,000 checks arithmetically implies approximately 50 failing checks, so the named list accounts for a subset of the implied total and the residual is not itemized in the material available. These are properties of the supplied tables, and they bound the precision of any conclusion drawn from them.
4.6 Iteration distribution across build attempts
Iteration telemetry for 500 build attempts reports a mean of 71.3 iterations, a median of 29, a minimum of 4, and a maximum of 300. The distribution is strongly right-skewed: the mean exceeds the median by a factor of approximately 2.5, and the maximum approaches the upper bound of the reported range. Persistence above thresholds is as follows: 314 attempts (62%) completed in under 50 iterations, 386 attempts (77%) in under 100 iterations, and 62 attempts (12%) required over 200 iterations.
The shape of this distribution indicates a mixture of regimes rather than a single central tendency: the bulk of attempts resolve quickly, while a minority consume a disproportionate share of iteration volume.
A unit clarification is required here. The threshold of "under 50 iterations" reported for build attempts shares a numerical value with the "greater than 50 QA events" threshold in the hypothesis, but the units are different — build iterations versus QA verification events — and the two figures should not be conflated or compared. They are reported separately and no relationship between them is asserted.
4.7 Contextual records
For completeness, two secondary record sets are noted. Intelligence signals collected number 500, with an average signal score of 7.4, distributed across three categories: AI Tool (261), Business Opportunity (138), and Market Signal (101), which sum to 500. Deployed production capabilities number 82 across 17 categories. These records characterize the volume and breadth of the system's non-build output. They are not analyzed further, as no measurement in the available data connects them to verification density or corrective workload.
4.8 Summary of hypothesis evaluation
The hypothesis requires a density regime above 50 QA events per completed build. The observed derived density is approximately 21.7 QA checks per build. The hypothesis's stated condition is not met, and the substitution claim it advances cannot be evaluated against this dataset. Within the observed lower-density regime, 84% of builds required at least one fix attempt; the data do not establish whether that proportion would be higher, lower, or unchanged at the density the hypothesis describes. The hypothesis is therefore recorded as untested rather than as supported or refuted.
---
5. Discussion
5.1 What the density figure does and does not show
The derived figure of approximately 21.7 QA checks per build is the study's central descriptive product. Its value is that it converts an abstract commitment to "continuous verification" into a countable quantity with an explicit denominator. Its limitation is equally clear: it is a ratio of two reported totals, computed in the absence of a documented join between the QA record set and the build record set, and it describes one production state of one system at one unspecified point in time.
The figure permits one disciplined comparison internal to the study. The density observed in this production system falls below the threshold the hypothesis treats as characterizing a high-density pipeline. That observation matters because it means the hypothesis was written about a regime the system does not, on these records, occupy. A reader tempted to treat the study as a test of the substitution hypothesis should read Section 4.8 instead: the hypothesis remains untested.
5.2 High per-check pass rates alongside high per-build remediation rates
The coexistence of a 94% per-check pass rate with an 84% per-build remediation rate is, at first reading, counterintuitive. It is not contradictory, and the units explain why. A pass rate applies to individual checks; a remediation rate applies to builds. Where many checks execute against each build, a small per-check failure rate can still mean that most builds encounter at least one failing check, and a build that encounters a single failing check becomes a build requiring a fix attempt. The two rates therefore measure different things at different levels of aggregation, and neither is a proxy for the other.
This has a practical measurement implication that the literature on QA metrics does not, in the material reviewed, resolve. Reporting a single pass rate for a verification suite can obscure the per-build experience of that suite. Tyagi and Singh (2026) argue for metric-driven hybrid QA frameworks, and the present observation suggests that any such framework should report per-build encounter rates alongside per-check pass rates if it is to describe what a development pipeline actually experiences. This is offered as a measurement recommendation grounded in the observed coexistence of the two rates, not as a causal claim.
5.3 The distribution of corrective effort
Corrective effort, where it occurred, was small in magnitude: a mean of 2.3 fix attempts among builds requiring them, and a maximum of 7 on any single build. This pattern is consistent with two very different underlying situations. It could indicate that failures, when they occur, are localized and quickly resolved. Alternatively, it could indicate that corrective iterations are recorded incompletely, so that the fix history understates the corrective work actually performed. The available records cannot distinguish these explanations. This ambiguity, already present in the rationale for the study, is not resolved by the analysis and is carried forward into Section 6.
If the first explanation holds, the finding is unremarkable and reassuring: verification catches localized problems that are then repaired with little iteration. If the second holds, the fix-history record is not a reliable denominator for any study of corrective workload, and the density-to-remediation relationship the hypothesis describes cannot be measured from this record type at all. Both possibilities are live, and the analyst declines to prefer one without evidence.
5.4 Disposition mix and the meaning of verification success
The observation that 18 builds carry escalated or pending dispositions while 8 are labeled verified invites a question the data cannot answer: whether "verified" denotes a distinct terminal state reached by a minority of builds, or whether the label applies to a subset of builds for reasons related to scope, product, or timing. Because the record set does not enumerate the semantics of each disposition label, no interpretation is offered beyond the counts themselves.
What can be said descriptively is that the disposition distribution does not suggest a pipeline in which verification routinely terminates builds in a verified state. That statement is bounded by the record's definitional opacity and by the single-organization design.
5.5 Iteration distribution as a mixture
The right-skewed iteration distribution — mean 71.3 against a median of 29, with 62% of attempts below 50 iterations and 12% above 200 — suggests a pipeline in which a minority of attempts consume a disproportionate share of iteration volume. This is consistent with the general finding in continuous delivery research that delivery pipelines exhibit heterogeneous difficulty across changes, a theme present in empirical work on continuous deployment challenges (Beyond Continuous Delivery, 2017) and on architecting for continuous delivery and deployment (2018). Those studies examine the organizational and architectural conditions producing such heterogeneity; the present study reports only its distributional signature in one system. Any inference about the causes of the skew would exceed the data.
The relationship between iteration volume and verification density is, moreover, unexamined here, because the two quantities are recorded against different denominators and no join key is available. This is a limitation of the available records, not a finding.
5.6 Relation to autonomous verification literature
The results bear on the autonomous verification literature in a specific and modest way. Kunda (2025) and Bandi Sudakara (2024) argue that autonomous and agentic systems require structured evaluation across reliability, safety, and quality dimensions. Pandhare (2025) argues that scalable QA pipelines for AI systems are needed as model-based systems enter core operations. Gupta and Vanteru (2026) examine how hallucination affects AI-assisted development workflows. These works establish what autonomous verification ought to measure. The present study contributes a production observation about how much verification was actually executed per delivered build in one such system, and about the corrective workload recorded downstream. The gap it addresses is empirical rather than conceptual: the literature describes what dense verification should look like, and this record describes what one pipeline did.
5.7 Measurement implications
Three implications follow from the results, each stated at the level of measurement practice.
First, QA-to-build density is computable from records that production systems already generate, and reporting it explicitly would make cross-system and longitudinal comparison possible. The absence of such a figure in the reviewed literature is, on this evidence, a reporting gap rather than a technical barrier.
Second, per-check pass rates and per-build remediation rates should be reported together. Reporting either alone invites misreading, as Section 5.2 describes.
Third, fix-history completeness should be established before fix-history volume is used as an outcome measure. The ambiguity in Section 5.3 is a direct consequence of not being able to establish that completeness.
---
6. Limitations
**Single organization, no control group.** All observations derive from one production autonomous software development system operated by one organization. There is no comparison condition, no matched control, and no variation in exposure. Every reported association is therefore confounded with the characteristics of this system, this organization, and this operating period. Nothing in this study supports generalization to other pipelines.
**Observational design.** No variable was manipulated. The study cannot establish causation, directionality, or mechanism. Statements such as "dense verification substitutes for corrective iteration" are properties of the hypothesis under test, not findings of this study.
**Aggregate-only data.** The analyst received summary tables rather than individual-level observations. Consequently, no confidence intervals, significance tests, or regression estimates were computed, and no effect size is reported. Derived quantities, including the QA-to-build ratio and the complement of fix-requiring builds, are arithmetic consequences of supplied totals rather than independent measurements.
**Denominator mismatch.** Iteration telemetry covers 500 build attempts; QA disposition and fix-history records cover 46 builds. The two record sets have no documented join key in the material available. The study treats them as parallel views rather than a linked dataset, and no cross-unit analysis was attempted. Readers should not read the 500-attempt statistics and the 46-build statistics as describing the same population without qualification.
**Internal consistency of source tables.** The disposition categories sum to 45 against a stated denominator of 46; the pass and fail rates sum to 99%; the named failing-check list accounts for fewer failures than the reported fail rate arithmetically implies. These discrepancies bound the precision of the results. They are disclosed rather than adjusted.
**Recorded fix history may be incomplete.** As discussed in Section 5.3, a conditional mean of 2.3 fix attempts with a maximum of 7 is consistent both with efficient localized repair and with under-reporting of corrective iterations. The study cannot distinguish these and does not attempt to.
**Undocumented field semantics.** Disposition labels — failed, escalated, pending, verified — are used as recorded by the operating organization. The study did not have access to definitions governing when each label applies, so label counts are reported without interpretation of their internal meaning.
**No temporal window.** The extraction window was not enumerated in the available material. The dataset is treated as a cross-sectional snapshot. No trend, drift, or seasonality analysis was possible, and no claim about change over time is made.
**Unanalysed contextual records.** Intelligence signal records and deployed capability counts are reported for completeness but are not connected to the primary measures by any available linkage. They should not be interpreted as explanatory variables.
**Self-reported system records.** All data originate from the observed system's own record-keeping. Independent verification of the counts was not possible. The study is therefore an analysis of what the system recorded, which is not identical to what the system did.
**AI-assisted writing.** This report was produced with AI assistance. The analysis, framing, and reporting were drafted with the support of an AI system, working from the anonymized aggregate records described in Section 3. All quantitative statements trace to the supplied tables; all citations trace to the related-work material identified in the literature search. AI assistance was used for drafting and structuring, and the resulting text was reviewed against the source data for numerical fidelity. Readers should weigh the report's conclusions with this assistance disclosed.
**Black-box access.** The analyst had no access to the system's internal design, and no description of internal mechanisms is offered anywhere in this report. The study describes inputs, outputs, counts, and rates only. Statements about why the observed values take the values they do are outside the evidence.
---
7. Conclusion
This study set out to test whether autonomous build pipelines with more than 50 QA events per completed build exhibit proportionally fewer fix-history entries per build. The observed production records from a single autonomous software development system report 1,000 executed QA checks against 46 builds, a derived density of approximately 21.7 QA checks per build. That density falls below the threshold the hypothesis specifies. The hypothesis was therefore not tested in the regime it describes, and this report records it as untested rather than as supported or refuted.
What the data do show is descriptive. Across 46 builds, 39 (84%) required at least one fix attempt, with a conditional mean of 2.3 fix attempts and a maximum of 7. The per-check pass rate was 94% and the per-check fail rate was 5%; QA dispositions were recorded as 27 failed, 12 escalated, and 6 pending, with 8 builds (17%) labeled verified. Across 500 build attempts, the mean iteration count was 71.3 against a median of 29, with a range of 4 to 300, 62% of attempts completing in under 50 iterations and 12% exceeding 200.
The contribution of the study is the explicit measurement of a ratio that the reviewed literature treats conceptually but does not report at production scale, together with an honest account of what that measurement cannot settle. The coexistence of a high per-check pass rate with a high per-build remediation rate is a unit-of-analysis phenomenon that measurement frameworks should accommodate. Whether dense QA verification substitutes for downstream corrective iteration remains an open question, and answering it will require pipelines that record QA density and fix history against a common, joinable denominator. That condition was not met here, and it is stated here so that the next study can meet it.
---