# Opportunity-to-Build Conversion Efficiency in Autonomous Product Pipelines: A Production Observational Study
**Publisher:** Vokrix Research (vokrix.co) **Study type:** Single-organization observational study of a black-box production system
*Note on anonymization: the organization that operates the observed production system is referred to throughout as "the study organization." No internal architecture, component names, or implementation details of the observed system are described in this report. Only measured inputs, outputs, counts, and rates are reported.*
---
1. Introduction
Autonomous and semi-autonomous software development pipelines have become a subject of increasing empirical interest. The literature that has accumulated around these systems, however, has concentrated on a specific band of the development lifecycle: verification depth, the density of quality-assurance signals, and the concentration of iteration effort within individual build tasks. Substantially less attention has been paid to the upstream boundary of the pipeline — the point at which a generated business opportunity is either advanced into a build or discarded. This asymmetry leaves an important empirical question unanswered: among the opportunities a production system generates, what proportion survives to become a completed build?
The question is not only descriptive but structural. Conversion rate is the multiplicative product of every selection decision, triage rule, prioritization heuristic, and quality gate that sits between opportunity generation and build completion. A high conversion rate implies a permissive pipeline that advances most candidates; a low rate implies either substantial funnel loss (candidates are generated that cannot progress) or deliberate selectivity (candidates are generated broadly and filtered aggressively). These two explanations carry very different implications for how a system should be evaluated, yet they are observationally indistinguishable without measurement of the conversion rate itself, together with the distributions that surround it.
Adjacent bodies of work provide framing but not direct evidence. The opportunity-scoring and opportunity-solution literature treats prioritization as an explicit analytical activity, in which candidate opportunities are evaluated and ranked before commitment ("Opportunity Scoring," 2022; "Opportunity Solution Tree," 2022). Work on AI-driven analytics for sales performance positions automated assessment as a response to fragmented, multi-channel demand and rapidly evolving markets (Thota, 2024). Empirical work on conversion rates exists in consumer-facing contexts — for example, an empirical study of conversion rate effects on product sales using merchant data under the AISAS model ("The Effect of Conversion Rate on Product Sales…," 2022) — but the unit of analysis there is a consumer purchase, not a completed engineering build. Similarly, the software repair literature characterizes how many attempts automated fixing requires (Mining Software Repair Models…, 2013; AIBugHunter, 2023), and the verification literature characterizes how coverage-based validation is structured for autonomous systems (Intersection focused Situation Coverage-based Verification and Validation Framework…, 2021), but neither measures upstream opportunity attrition. The literature search conducted for this study returned limited directly relevant material on opportunity-to-build conversion in autonomous product pipelines; accordingly, the gap is framed here as a deficiency of empirical production-scale data rather than as an absolute absence of prior work.
This report makes four contributions. First, it quantifies opportunity-to-build conversion in a single production autonomous pipeline, reporting an observed rate of 5.6% across 824 generated opportunities and 46 completed builds. Second, it characterizes the distribution of iteration effort across 500 build attempts, reporting mean, median, range, and banded shares. Third, it reports the quality-assurance outcome distribution and fix-attempt intensity across the 46 completed builds, distinguishing check-level pass rates from build-level verification outcomes. Fourth, it documents the dataset's internal consistency problems and interpretive limits explicitly, so that downstream readers can assess which reported quantities are stable enough to be used as comparators.
---
2. Related Work
**Opportunity identification and prioritization.** Reference treatments of opportunity scoring and opportunity solution trees ("Opportunity Scoring," 2022; "Opportunity Solution Tree," 2022) address the problem of structuring and ranking candidate opportunities before committing resources. These works establish that prioritization is typically modelled as an explicit scoring or tree-structuring activity. The retrieved records for these entries supplied bibliographic metadata only, without abstract text; they are cited here as evidence that the concept of structured opportunity assessment is established in the literature, not as sources of quantitative benchmarks. Their relevance to the present study is definitional: they describe the activity whose downstream yield this study measures.
**Automated assessment in commercial pipelines.** Thota (2024) situates automated sales performance optimization within a market environment characterized by fragmented customer experience, multi-channel communication, and rapidly evolving demand, and positions AI-driven cloud analytics as the mechanism for optimization. The abstract does not report a conversion rate or a funnel statistic. Its relevance here is contextual: it documents that automation of opportunity and performance assessment is an active applied domain, which makes the absence of production-scale conversion measurement in that domain more notable.
**Conversion rate as an empirical construct.** An empirical study of conversion rate effects on product sales, conducted from the perspective of the AISAS model using merchant data ("The Effect of Conversion Rate on Product Sales…," 2022), treats conversion as a measurable outcome with downstream commercial consequences. The retrieved record provided only the title and identifier, so no claim is made here about its method or findings beyond what the title states. Its relevance is that it demonstrates conversion rate is an established dependent variable in empirical work, while using a different unit of analysis (consumer purchase) than the present study (completed engineering build).
**Automated repair and fix-attempt behaviour.** The software repair literature directly informs the fix-attempt measures reported in Section 4. "Mining Software Repair Models…" (2013) analyses thousands of bug-fix transactions from software repositories in order to characterize the nature of bug fixing, and then situates that learned characterization within automated program fixing. AIBugHunter (2023) reviews machine-learning approaches for detecting, localizing, and repairing software vulnerabilities, noting that such methods have been described as more effective than program-analysis-based approaches. These works jointly establish that automated repair is typically an iterative, multi-attempt process. They do not, however, report distributions of fix attempts at the level of a completed build within a production autonomous pipeline, which is what the present study reports descriptively.
**Verification and review signals.** "Intersection focused Situation Coverage-based Verification and Validation Framework for Autonomous Vehicles Implemented in CARLA" (2021) presents a verification and validation framework built around situation coverage, motivated by the safety-critical nature of autonomous driving software. "Developers Perception of Peer Code Review in Research Software Development" (2021) examines how developers perceive peer code review in research software, a context the abstract describes as complex. Both works concern how verification signals are structured and received. They are relevant here because the observed system's quality-assurance layer is a verification-signal layer; the present study measures the density and outcome distribution of those signals without describing the mechanism that produces them.
**Automated decision-making and accountability.** Turdialiev (2024) explores the integration of AI and automated decision-making systems within private international law, framing the intersection as presenting both challenges and opportunities. The relevance to the present study is narrow but real: opportunity advancement in an autonomous pipeline is an automated decision with resource consequences, and the volume of unadvanced candidates reported in Section 4 is a governance-relevant quantity, not merely an efficiency statistic.
**Data pipelines.** "Data Pipelines" (2026) is a reference treatment of data pipeline concepts. Only the title and identifier were available in the retrieved record, and no substantive claim is attributed to it here. It is cited solely to acknowledge that pipeline structure is a documented subject of reference literature, distinct from the production-observational measurement this study undertakes.
**Summary of the gap.** Across the retrieved material, no work was found that reports the proportion of generated business opportunities that become completed builds within an operating autonomous product pipeline. The gap is therefore stated conservatively: limited empirical production-scale data exists on this conversion step, and no retrieved study supplies a directly comparable benchmark.
---
3. Study Design and Data Collection
3.1 Design
The study is a retrospective, observational analysis of production records generated by an autonomous software development system operated by a single organization. No experimental manipulation was performed, no condition was assigned, and no control group exists. The observed system was treated as a black box: the unit of analysis is the record, not the mechanism. Accordingly, the study design specifies what was counted and how counts were aggregated, and deliberately does not characterize the internal processing that produced those counts.
3.2 Data source and access
Data consisted of an anonymized extract of production logs and associated record tables, provided to the research team with organizational identifiers, user identifiers, and repository-level naming removed. The extract covered a single contiguous production observation window. The released extract did not carry explicit calendar boundaries, and this study therefore reports no time-based rates (for example, builds per week). All quantities reported in Section 4 are cumulative counts and ratios over the extract as released.
3.3 Measured units
The following units were recorded and are used consistently throughout:
- **Opportunity** — a generated business opportunity record. Count: 824.
- **Completed build** — a build record present in the system at the time of extraction. Count: 46.
- **Build attempt** — an individual attempt at producing a build, tracked at attempt level. Count analysed: 500. Each attempt carries an iteration count, defined as the number of internal iteration cycles recorded against that attempt.
- **Fix attempt** — a corrective cycle recorded against a build that did not pass validation on first presentation. Counted per build where present.
- **Quality-assurance (QA) check** — a single named check executed against a build, with a pass or fail outcome. Count: 1,000.
- **Intelligence signal** — an externally sourced item collected by the system and assigned a numeric score. Count: 500.
- **Production capability** — a recorded deployed capability, grouped by category. Count: 82 across 17 categories.
3.4 Collection procedure
Counts were obtained by aggregating the released records by the units defined above. Build-level QA status was taken from the status field recorded against each build. Iteration counts were taken from the attempt-level field. Fix attempts were counted per build. QA check outcomes were counted per check execution, and failing check names were tabulated by frequency. Intelligence signals were tabulated by category and summarized by mean score. No imputation was performed. No records were excluded, and no outliers were trimmed; the full reported range of iteration counts (4–300) is retained in the analysis.
3.5 Derived quantities
Two ratios are central. Opportunity-to-build conversion is the count of completed builds divided by the count of generated opportunities. Build verification rate is the count of verified builds divided by the count of completed builds. Where the source extract reported a share directly alongside a count, both are reported; where a share and its underlying counts were mutually inconsistent, the discrepancy is reported rather than resolved (Section 4.7).
3.6 Reproducibility
The design is reproducible in the sense that the aggregation rules above are fully specified and can be applied to an equivalent record extract from another system. It is not reproducible as a controlled experiment, because the underlying production process cannot be re-run under identical conditions and no comparison condition was observed.
---
4. Results
4.1 Opportunity-to-build conversion
The system recorded 824 generated business opportunities and 46 completed builds. The observed opportunity-to-build conversion rate is therefore 5.6%. This value is below the 10% threshold specified in the study hypothesis; the hypothesis that fewer than 10% of generated opportunities result in completed builds is consistent with the observed data for this single organization and observation window.
The conversion figure is the ratio of two counts recorded at different layers of the pipeline. It is reported as a single observed proportion and is not accompanied here by an interval estimate, because the denominator and numerator are census counts of the released extract rather than samples from a defined population.
4.2 Iteration effort across build attempts
Across 500 build attempts, the mean number of iterations per attempt was 71.3 and the median was 29, with an observed range of 4 to 300 iterations. The excess of the mean over the median indicates a right-skewed distribution in which a minority of attempts accounts for a disproportionate share of iteration effort.
Banded shares are as follows:
| Iteration band | Attempts | Share | |---|---|---| | Fewer than 50 iterations | 314 | 62% | | Fewer than 100 iterations | 386 | 77% | | More than 200 iterations | 62 | 12% |
Because the "fewer than 100" and "more than 200" bands do not overlap, the remainder of the 500 attempts falls in the interval between 100 and 200 iterations. The distribution is therefore not bimodal in the observed data; it is a heavy right tail attached to a large low-iteration mass.
4.3 Build-level QA status
Of the 46 builds in the system, QA status was recorded as follows: failed, 27; escalated, 12; pending, 6. Verified builds numbered 8, corresponding to 17% of the 46 builds.
Two observations about these figures are recorded here rather than reconciled. First, the three non-verified status categories sum to 45, one fewer than the reported total of 46 builds. Second, verified builds are reported as a separate count of 8; if verified builds are treated as an additional category, the combined total exceeds 46. The status field therefore does not partition the 46 builds cleanly as released, and the individual category counts should be treated as reported values rather than as a fully consistent partition.
4.4 Fix-attempt behaviour
Of the 46 builds, 39 required at least one fix attempt, corresponding to 84% of builds. Among builds where fix attempts were required, the mean number of fix attempts was 2.3. The maximum number of fix attempts recorded on a single build was 7. No build in the extract required more than 7 fix attempts.
4.5 Check-level QA outcomes
A total of 1,000 QA checks were executed. The reported pass rate was 94% and the reported fail rate was 5%. The two reported shares sum to 99%, leaving a residual share of the check population unaccounted for by the pass and fail categories as reported. This residual is noted as a reporting limitation; the present study does not assign it to any category.
The most frequently recorded failing checks, by count, were: "Dashboard screenshot present" (10), "AI assistant responds" (10), "AI assistant button found" (7), "QA reasoning" (4), and "DOM checks (dashboard)" (2). These five check names account for the listed failure counts. The remaining failing checks, if any, are not itemized in the released extract.
QA failures were distributed across 17 unique products, indicating that failures are not confined to a single product line within the observed population.
4.6 Intelligence signal layer
The system collected 500 intelligence signals with a mean signal score of 7.6. The category distribution was: AI Tool, 255 signals; Business Opportunity, 142 signals; Market Signal, 103 signals. These three categories sum to the full set of 500 signals. The extract did not include a score scale definition, a score distribution, or a score threshold associated with advancement, so the mean of 7.6 is reported as a descriptive summary of the released values only. No relationship between signal score and build outcome is reported, because the released extract does not support linkage at that level.
4.7 Deployed production capabilities
The system recorded 82 deployed production capabilities distributed across 17 categories. This figure describes the breadth of the recorded capability inventory at the time of extraction. It is reported here as a descriptive property of the observed system's surface area and is not used in any analysis of conversion, iteration, or QA outcomes.
---
5. Discussion
5.1 Interpretation of the conversion result
The observed opportunity-to-build conversion of 5.6% (46 of 824) is consistent with the study hypothesis that fewer than 10% of generated opportunities result in completed builds. Within the limits of a single-organization observation, this indicates that the observed pipeline generates substantially more opportunities than it completes as builds.
The design cannot distinguish between the two explanations identified at the outset. Either the pipeline generates candidates that cannot progress — funnel loss — or it generates candidates broadly and filters them aggressively — deliberate selectivity. Both produce the same aggregate ratio. The distinguishing evidence would lie in the reasons recorded against unadvanced opportunities, which the released extract does not contain. Care is warranted here: a low conversion rate is not intrinsically a defect. If opportunity generation is inexpensive relative to build execution, low conversion is the arithmetic consequence of generating broadly and gating tightly, and the efficiency question becomes one of generation cost rather than conversion rate.
5.2 Iteration distribution and effort concentration
The gap between the mean (71.3) and median (29) iterations per attempt indicates that typical attempts are considerably cheaper than the average attempt. With 62% of attempts completing in fewer than 50 iterations and 12% exceeding 200, the observed system exhibits the effort-concentration pattern familiar from long-tailed engineering workloads. The presence of attempts at the 300-iteration ceiling suggests that the recorded range may be bounded by the measurement instrument rather than by the underlying process; the extract does not state whether the ceiling is a hard limit.
This distribution matters for interpretation of the conversion rate. If a small share of attempts consumes a large share of resources, then conversion measured in events and conversion measured in effort are different quantities. The present study measured events only.
5.3 Fix-attempt intensity and comparison to repair literature
That 84% of completed builds required at least one fix attempt, with a mean of 2.3 attempts where required and a maximum of 7, is consistent with the characterization of automated repair in the software repair literature as an iterative process ("Mining Software Repair Models…," 2013; AIBugHunter, 2023). Those works establish that automated fixing involves search over a space of candidate repairs; an observed mean of 2.3 corrective cycles is not in tension with that characterization.
What the present study adds is not a mechanism but a production frequency. The repair literature does not, in the retrieved material, report the proportion of completed builds in an operating autonomous pipeline that required corrective cycles. The 84% figure is therefore reported as a descriptive production characteristic rather than as a confirmation or refutation of any specific prior result.
5.4 Check-level and build-level QA outcomes diverge
The check-level pass rate of 94% and the build-level verified rate of 17% describe different things and should not be read as contradictory. A build-level outcome aggregates many individual checks; a build may fail overall while a large majority of its constituent checks pass. Reporting only the 94% figure would overstate pipeline health at the build level, and reporting only the 17% figure would obscure that most individual checks succeed. Both are reported here for that reason.
The distribution of failing check names is narrow. The five most frequent failing checks are all plausibly attributable to user-facing interface conditions and to the assessment layer itself. This observation is descriptive; the released extract does not contain enough information to determine whether the failure taxonomy is genuinely narrow or whether the check inventory is narrow.
5.5 The signal layer and the conversion question
The system collected 500 scored intelligence signals at a mean score of 7.6, with the largest single category being AI Tool (255 signals), followed by Business Opportunity (142) and Market Signal (103). The presence of structured scoring and categorical classification is consistent with the framing of opportunity assessment in the retrieved prioritization literature as an explicit scoring activity ("Opportunity Scoring," 2022; "Opportunity Solution Tree," 2022).
However, the present study cannot connect signal scores to build outcomes. The extract contains no threshold, no advancement decision record, and no signal-to-build linkage. The mean score of 7.6 should therefore be read as an inventory summary, not as evidence that scoring drives selection. The gap between the presence of a scoring apparatus and the absence of evidence that it determines outcomes is itself a finding about what production instrumentation currently captures.
5.6 Governance framing
Opportunity advancement in an autonomous pipeline is an automated decision with resource consequences. Turdialiev (2024) frames the integration of automated decision-making systems as presenting both challenges and opportunities; the present results give that framing a concrete magnitude in one setting, in the form of 824 generated opportunities against 46 completed builds. Whether the ratio reflects appropriate gating or unrecorded attrition is a governance question that production telemetry of the kind examined here does not answer.
---
6. Limitations
**Single organization.** All observations come from one organization operating one production system. No claim of generalizability is made. The conversion rate of 5.6%, the iteration distribution, and the QA outcome distribution are properties of this extract.
**No control group.** No comparison condition exists. There is no non-autonomous baseline pipeline, no prior-period baseline, and no alternative configuration against which the observed rates could be contrasted. All comparisons in Section 5 are to published literature, not to a matched control.
**Observational design only.** No variable was manipulated and no randomization was performed. The study cannot support causal claims. In particular, nothing in the data identifies why 778 of 824 opportunities did not become builds.
**Black-box access.** The research team was given records, not process visibility. This report deliberately contains no description of internal architecture or mechanism. As a result, observed aggregates cannot be decomposed into their contributing causes, and plausible mechanisms are stated as possibilities rather than explanations.
**Small event count on the primary outcome.** Opportunity-to-build conversion rests on 46 events. With a denominator of 824 and a numerator of 46, the estimate is sensitive to small changes in the numerator, and it should be treated as an observation of one window rather than as a stable rate.
**Data consistency issues.** As documented in Sections 4.3 and 4.5, the build QA status categories sum to 45 rather than 46 while a further 8 builds are reported as verified, and the check-level pass and fail rates sum to 99% rather than 100%. These discrepancies are reported rather than resolved. Any reader using these figures as comparators should account for them.
**Instrument-relative measures.** Iteration counts, fix attempts, and check outcomes are recorded by the observed system using its own definitions and its own category labels. The study did not independently verify these definitions, and cross-system comparability of these measures is unestablished.
**Missing temporal boundaries.** The extract did not include explicit calendar boundaries. No time-normalized rate is reported, and no trend, seasonality, or drift analysis was possible.
**No inter-rater reliability.** Failure-cause categorization was not performed; only frequency tabulation of the system's own check names was performed. No manual coding step was introduced, and therefore no inter-rater reliability statistic is available or needed.
**AI-assisted writing disclosure.** This paper was produced with AI assistance. The assistance covered drafting and structuring of the manuscript. All quantitative values were constrained to the released production extract, no values were generated or estimated by the assisting system, and citations were restricted to records retrieved in the associated literature search. Readers should weight this disclosure when assessing the manuscript's prose, while noting that the underlying counts are drawn from the released extract as described in Section 3.
**No external validation.** The findings have not been replicated in a second organization, a second observation window, or a second system.
---
7. Conclusion
This study set out to test whether fewer than 10% of generated business opportunities in a production autonomous software development pipeline result in completed builds. In the observed extract, 46 of 824 generated opportunities became completed builds, a conversion of 5.6%. The hypothesis is consistent with the data for this organization and window.
Beyond the headline ratio, the study reports three descriptive findings. Build effort was strongly right-skewed: across 500 attempts the mean was 71.3 iterations and the median 29, with 62% of attempts under 50 iterations and 12% over 200. Corrective work was the norm rather than the exception at build level: 39 of 46 builds (84%) required at least one fix attempt, averaging 2.3 where required, with a maximum of 7. And check-level and build-level quality outcomes diverged sharply, with a 94% pass rate across 1,000 checks alongside 8 verified builds out of 46.
What the study does not show is equally important. It does not show whether the low conversion reflects funnel loss or deliberate selectivity, because no reasons for non-advancement were recorded. It does not show that the system's intelligence scoring layer influences advancement decisions, because no linkage between scores and outcomes was available. It does not establish causation, and it does not generalize beyond a single organization observed in a single window without a control condition. The contribution is a set of clearly bounded production measurements at a pipeline stage where empirical data has been scarce, together with an explicit record of the data consistency problems encountered in producing them.
---