# Telemetry Density Asymmetry Between Verification and Market Sensing in Autonomous Product Pipelines: A Production Observational Study
**Publisher:** Vokrix Research (vokrix.co) **Study type:** Retrospective observational analysis of anonymized production records **Study subject:** A production autonomous software development system operated by a single organization
---
1. Introduction
Autonomous software development pipelines generate at least two qualitatively distinct classes of telemetry. The first is *verification telemetry*: discrete records produced when the pipeline asserts something about its own output — a check executed, a status assigned, a failure logged, an escalation raised. The second is *market-sensing telemetry*: discrete records produced when the pipeline ingests and scores information originating outside the organization — competitive signals, tool releases, commercial opportunities. Both streams are machine-generated, both accumulate continuously, and both are stored as structured records. Yet they are produced by different processes, on different cadences, in service of different downstream decisions.
The research literature has treated these streams largely in isolation. Work on observability for autonomous and agentic systems has concentrated on internal system state: reliability monitoring, distributed tracing, and the reasoning traces of LLM-powered agents (Boosa, 2024; Rombaut & Masoumzadeh, 2024; Punniyamoorthy & Saksena, 2026). Work on verification has concentrated on the design and economics of quality assurance — testing frameworks, requirements quality, and process models for quality (Patel & Patil, 2026; *Towards CRISP-ML(Q)*, 2020; *Requirements Quality Assurance in Industry*, 2023; *Integrating a Model of Analytical Quality Assurance into the V-Modell XT*, 2016). Work on market-facing signals has concentrated on how external information is generated and interpreted, for example in post-market quality-signal assessment (*From consumer complaints to post-market quality signals*, 2027) and in the analysis of quality uncertainty as a market-side construct (Zhang, 2010). Architectural work has examined multi-agent LLM systems as a new class of distributed system (Savajiyani, 2026; Zhong & Zhu, 2026; Jakkireddy, 2026), but has not, to the authors' reading, reported the relative volume of the two telemetry classes within a single operating pipeline.
The consequence is a specific empirical gap. No canonical public benchmark relating verification-record volume to market-sensing-record volume appears to exist: the two streams are measured in different units, produced on different cadences, and reported through different tool categories. The gap is therefore not one of contested findings but of *limited empirical production-scale data*. Whether autonomous pipelines record their own verification activity at a density comparable to, or substantially different from, their external sensing activity is an open descriptive question that can be answered with counts.
This paper asks that question directly and narrowly. The hypothesis under test is: **in the production corpus, verification telemetry volume exceeds market-sensing telemetry volume by at least 1.5x.** The test is a ratio of two record counts, and it is a yes/no test at a pre-specified threshold. Contextual build-execution and deployment records are reported alongside to convey the scale and operating characteristics of the studied system, but they are not required for the primary test.
The contributions of this report are fourfold. First, it provides an explicit operational definition of telemetry density for two heterogeneous record streams and reports a direct test of the resulting ratio in a production corpus. Second, it reports contextual production counts — 500 build attempts, 46 builds, 1,000 verification checks, 500 intelligence signals — that allow other researchers to assess whether the corpus is comparable to their own. Third, it reports the asymmetry with an extended unit-comparability caveat, rather than treating the ratio as a like-for-like efficiency metric. Fourth, it documents several sub-observations that qualify the headline result, including heterogeneity within the market-sensing stream, strong right skew in build iteration counts, and internal inconsistencies in the released status records. These qualifications are reported in the Results and Limitations sections rather than deferred.
The remainder of the paper is organized as follows. Section 2 reviews the literature that informs the study. Section 3 defines the measures and describes data collection. Section 4 reports results. Section 5 interprets them within the limits of what was measured. Section 6 states limitations, and Section 7 concludes.
---
2. Related Work
2.1 Observability for autonomous and agentic systems
Boosa (2024) argues that site reliability engineering has shifted from monitoring infrastructure health and reacting to events toward AI-driven observability platforms that provide real-time visibility into complex distributed environments. The framing is instructive here because it locates observability's centre of gravity in *internal* system state. The same inward orientation appears in Rombaut and Masoumzadeh (2024), who identify the emergence of "Agentware" — systems in which LLM-powered agents perform complex, open-ended tasks — and propose a cognitive observability framework directed at the *reasoning* of such agents. Punniyamoorthy and Saksena (2026) similarly observe that conventional DevOps instrumentation, including observability tooling, struggles to keep pace with the scale and dynamism of cloud operations, and argue for cognitive platform engineering for autonomous operations.
Taken together, this body of work establishes that the instrumentation of autonomous systems is predominantly inward-facing. It does not, however, quantify how inward-facing it is relative to externally oriented sensing, which is the question addressed here.
2.2 Architecture and reliability of multi-agent LLM systems
Savajiyani (2026) characterizes the proliferation of LLM-based autonomous agents as having created a new class of distributed system — the multi-agent LLM network — and notes that research attention has concentrated on agent intelligence while software-engineering concerns remain less settled. Zhong and Zhu (2026) observe that although foundation models have transformed automated code generation, autonomous software-engineering agents remain unreliable in realistic development settings, and propose a runtime substrate to address this. Jakkireddy (2026) situates such systems within a broader move toward intelligent cloud-native enterprise platforms combining AI-driven software engineering, serverless architectures, and workflow automation.
This literature motivates the present study in two ways. First, if instrumentation norms for multi-agent LLM systems are not yet settled, then the observed density of any particular telemetry class is unlikely to reflect deliberate calibration. Second, unreliability in realistic settings implies that verification records will be produced in quantity — a point directly relevant to the asymmetry examined here. Neither paper reports a ratio of internal to external record volume.
2.3 Verification and quality assurance telemetry
A substantial body of work addresses the production and interpretation of verification records. Patel and Patil (2026) propose a scalable hybrid testing framework that integrates observability-driven automation with AI-augmented proactive quality engineering, an approach in which verification is continuous and record-generating by design. *Towards CRISP-ML(Q)* (2020) argues that machine learning is an established industrial technique but lacks a standard process model, and proposes one with an accompanying quality-assurance methodology. *Requirements Quality Assurance in Industry* (2023) notes that natural language is the most common industrial form of requirements specification and that specification quality depends on the writer's capability — a reminder that verification records are themselves downstream of a quality-sensitive upstream process.
Other work addresses verification tooling empirically: *An Empirical Study in Software Verification Tools* (2020), and *Leveraging LLMs for Automated Requirements Quality Verification in Automotive Software* (2026), an empirical industrial study. *Integrating a Model of Analytical Quality Assurance into the V-Modell XT* (2016) contends that economic models of quality assurance allow quality-assurance planning to be grounded in economic factors rather than conventions. On the recordkeeping side, *Completing quality assurance records* (2021) addresses the completeness of QA records as a concern in its own right — directly relevant to the present study, in which record completeness is a material limitation.
This literature establishes that verification is extensively theorized and heavily instrumented. It does not, however, compare verification record volume against externally oriented sensing record volume within the same pipeline.
2.4 Mining logs and telemetry
Methodological precedent for treating production records as an object of empirical study is well established. *Mining system logs to learn error predictors: a case study of a telemetry system* (2014) demonstrates that system logs from a telemetry system can be mined to learn predictors of error. *Software Behavior and Failure Clustering: An Empirical Study of Fault Causality* (2012) examines the clustering of failures by causal structure. *An empirical study of patch uplift in rapid release development pipelines* (2018) examines patch behaviour in pipelines characterized by rapid release cadence.
These studies establish that production telemetry is a legitimate unit of analysis and that record-level counts can support empirical claims. They do not address the relative density of distinct telemetry classes.
2.5 Market-facing signal streams
On the external side, Zhang (2010) examines perpetual versus subscription licensing under conditions of quality uncertainty and network externality effects, treating quality uncertainty as a market-side variable that shapes commercial outcomes. *From consumer complaints to post-market quality signals* (2027) presents a production-adjusted assessment of quality-assurance governance in a multi-factory food supply chain, in which post-market signals are used to evaluate quality governance.
The latter paper is methodologically analogous rather than directly comparable: it demonstrates that organizations maintain both in-process quality records and post-market quality signals, and that these are governed differently. The present study asks whether they are also recorded at different densities in an autonomous software pipeline. Direct evidence on that question was not located in the reviewed set.
2.6 GUI-level verification
Because the observed corpus included dashboard and document-object-model verification checks, work on GUI agents is relevant. Yu and Ling (2026) observe that GUI agents have advanced rapidly, producing a growing body of frameworks, benchmarks, and applications, but that this growth has outpaced the maturity of the field, and that GUI agents remain technically brittle. This brittleness is consistent with the presence of repeated GUI-level failure labels in the observed corpus, discussed in Section 4.
2.7 Gap addressed by this study
Across these literatures, verification activity is heavily instrumented and market sensing is separately studied, but the *relative* volume of the two record streams within a single production pipeline has not, to the authors' knowledge, been reported with explicit counts and a pre-specified threshold. This study addresses that narrow gap. It does not claim that the literature is wrong; it claims that limited empirical production-scale data exists on this specific descriptive question.
---
3. Study Design and Data Collection
3.1 Design
The study is a retrospective observational analysis of anonymized production records. No intervention was applied to the observed system. Records were released to the researchers as a read-only extract by the study organization, and all analyses reported here are descriptive. No inferential statistical testing was performed and no control or comparison corpus was available.
3.2 Definitions and units
The following units were used, as defined by the record structure of the released extract:
- **Build attempt.** One execution of the observed system's build process toward a product increment. A build may involve multiple attempts.
- **Build.** A distinct product increment tracked to completion within the observed system.
- **Iteration.** One internal generate-and-evaluate cycle within a build attempt.
- **Verification record (QA check result).** One discrete verification assertion executed by the system and recorded with a status outcome.
- **Intelligence signal.** One discrete externally sourced item ingested by the system, recorded with a numeric relevance score and a category label.
- **QA status.** The terminal or current disposition of a build with respect to verification: failed, escalated, pending, or verified.
3.3 Measures
The primary measure is **telemetry density ratio**, defined as:
> R = (number of verification records) / (number of market-sensing records)
computed over the released corpus. Density here is operationalized strictly as *count of discrete records per stream within the observation corpus*. It is not normalized by time, cost, information content, or decision value, and it is not a measure of quality or sufficiency.
The pre-specified decision rule was: if R ≥ 1.5, the hypothesis is supported; if R < 1.5, the hypothesis is not supported. This threshold was fixed before the ratio was computed.
Contextual measures recorded alongside the primary measure were: number of build attempts; iterations per attempt (mean, median, range, and distributional bands); number of builds; QA status counts; verified build count; count and frequency of fix attempts; number of QA checks run and pass/fail rates; labels of the most frequently failing checks; number of distinct products with recorded failures; count, mean score, and category distribution of intelligence signals; and count of deployed production capabilities by category.
3.4 Observation window
The released extract covered a single contiguous production period. The calendar bounds of that period were not included in the data release and are therefore not reported. This omission is a property of the extract, not a deliberate withholding of an available measure, and it precludes any time-normalized interpretation of the counts.
3.5 Data quality checks
Three consistency checks were performed on the released records.
First, the intelligence signal category counts were summed and compared against the reported total. The three reported categories summed exactly to the reported total of 500, indicating internal consistency for that field.
Second, the reported QA status categories were examined. Recorded failures (27), escalations (12), and pending outcomes (6) sum to 45; adding the 8 verified builds yields 53, against a separately reported total of 46 builds in the system. The status categories as released therefore do not reconcile arithmetically to the build total. Possible explanations include non-exclusive status recording, status transitions counted more than once, or differing denominators between fields. The records are reported here exactly as released, without adjustment or reconciliation.
Third, the reported QA pass rate (94%) and fail rate (5%) sum to 99%, leaving approximately one percent of checks without a reported terminal classification in the released summary.
Fourth, the most frequently failing check labels were summed. The five released labels account for 33 recorded observations. Because the release identified these labels as the *most common* failing checks rather than an exhaustive enumeration, this sum cannot be assumed to equal the total number of failing checks, and no such equality is asserted.
3.6 Ethics and anonymization
The extract contained no personally identifying information. No human subjects were involved. Organizational identity, internal component names, and any implementation detail of the observed system were withheld by design; this report describes only inputs, outputs, and recorded measurements.
---
4. Results
4.1 Primary hypothesis test
The released corpus contained **1,000 verification (QA) check results** and **500 intelligence signals**.
The telemetry density ratio is therefore:
> R = 1,000 / 500 = **2.0**
The pre-specified threshold was 1.5. The observed ratio of 2.0 exceeds that threshold. **The hypothesis that verification telemetry volume exceeds market-sensing telemetry volume by at least 1.5x is supported for this corpus.**
In absolute terms, the observed ratio exceeds the threshold by 0.5 records of verification per record of market sensing, or approximately one-third above the threshold value. The margin is not large: holding one stream fixed, a change of roughly 170 additional intelligence signals (with verification held at 1,000) or roughly 250 fewer verification records (with signals held at 500) would move the ratio to the threshold. This sensitivity is noted here rather than deferred, because it bears directly on how much weight the result can bear.
**Table 1. Primary telemetry streams and ratio.**
| Stream | Record type | Records | |---|---|---| | Verification | QA check results | 1,000 | | Market sensing | Intelligence signals | 500 | | Derived ratio | Verification per market-sensing record | 2.0 | | Pre-specified threshold | — | 1.5 | | Decision | Hypothesis supported | Yes |
4.2 Composition of the verification stream
Of the 1,000 QA checks run, the reported **pass rate was 94%** and the reported **fail rate was 5%**, leaving approximately 1% without a reported terminal classification in the summary.
At the build level, of the **46 builds in the system**, recorded QA statuses were: **27 failed**, **12 escalated**, and **6 pending**. **8 builds were verified**, corresponding to **17%** of the build total. As noted in Section 3.5, these status counts do not sum to the reported build total and are reported as released.
**39 of 46 builds (84%) required at least one fix attempt.** Among builds that required fix attempts, the mean number of attempts was **2.3**, and the maximum recorded on a single build was **7**.
The most frequently recorded failing verification checks were:
**Table 2. Most frequently recorded failing verification checks (as released).**
| Failing check label | Recorded occurrences | |---|---| | Dashboard screenshot present | 10 | | AI assistant responds | 10 | | AI assistant button found | 7 | | QA reasoning | 4 | | DOM checks (dashboard) | 2 | | **Sum of the five released labels** | **33** |
These five labels account for 33 recorded observations. As stated in Section 3.5, the release identified them as the most common failing checks, not as an exhaustive set; the sum is therefore reported as a property of the released label list and not as the total failure count.
Failures were not concentrated in a single product: **17 unique products** had recorded QA failures.
Two features of this label distribution are worth recording as observations rather than inferences. First, four of the five most frequent labels describe externally observable interface behaviour (dashboard screenshot presence, assistant responsiveness, button presence, DOM state), while one — "QA reasoning" — describes an internal reasoning check. Second, the two most frequent labels occur at identical counts (10 each).
4.3 Composition of the market-sensing stream
The corpus contained **500 intelligence signals** with an **average signal score of 7.6**.
**Table 3. Intelligence signal categories.**
| Category | Signals | |---|---| | AI Tool | 250 | | Business Opportunity | 140 | | Market Signal | 110 | | **Total** | **500** |
As arithmetic proportions of the stated total, these correspond to 50%, 28%, and 22% respectively. The distribution is reported here as record counts; the derived proportions are included only to make the heterogeneity legible.
This composition matters for the interpretation of the primary result. The stream labelled "market sensing" is internally heterogeneous: exactly half of its records were categorized as AI Tool, with 140 characterized as Business Opportunity and 110 as Market Signal. Only the last category carries the label most directly associated with market observation.
4.4 Build execution telemetry (contextual)
The corpus contained **500 build attempts** distributed across **46 builds in the system**. Iterations per build attempt were:
**Table 4. Iteration counts per build attempt.**
| Statistic | Value | |---|---| | Mean iterations | 71.3 | | Median iterations | 29 | | Range | 4–300 | | Builds under 50 iterations | 314 (62%) | | Builds under 100 iterations | 386 (77%) | | Builds over 200 iterations | 62 (12%) |
The mean (71.3) is more than twice the median (29), and the maximum (300) is more than ten times the median. The distribution is strongly right-skewed: a majority of attempts complete in under 50 iterations, a small minority extend beyond 200, and that minority exerts substantial leverage on the mean.
4.5 Deployed capability surface (contextual)
The observed system recorded **82 production capabilities deployed across 17 categories** during the corpus period. This measure is reported for scale only; no analysis of it is offered.
4.6 Summary of what was and was not found
The primary result is a ratio of 2.0, above the 1.5 threshold. Contextually, the corpus shows a verification stream in which 84% of builds required correction, a maximum of 7 fix attempts on a single build, and 17% of builds reaching verified status, alongside a strongly right-skewed iteration distribution and a market-sensing stream that is majority-composed of AI Tool records rather than Market Signal records.
No measure of the downstream consequences of either telemetry stream — decisions taken, products shipped, revenue realized, or sensing accuracy — was present in the released corpus. No temporal alignment between the two streams was available. No per-build breakdown of verification records was released. These absences constrain the Discussion that follows.
---
5. Discussion
5.1 The asymmetry and its immediate reading
The corpus records verification at twice the density of market sensing. Read narrowly, this is a descriptive fact about one system's record production: for every external signal stored, two verification assertions were stored. The hypothesis anticipated an asymmetry of at least 1.5x and the corpus shows one of 2.0x. The direct question the study set out to answer has been answered in the affirmative.
Read more broadly, the result invites over-interpretation, and several features of the data argue against it. The two streams are not commensurable: a QA check result and an intelligence signal differ in production cost, information content, and decision relevance. The ratio is a count ratio, not an attention ratio. Section 5.4 returns to this point.
5.2 What the verification stream's internal structure suggests
Three features of the verification stream are relevant to interpreting the headline ratio.
First, verification in the observed system is not purely passive recording. Thirty-nine of 46 builds required at least one fix attempt, with a mean of 2.3 attempts where required and a maximum of 7 on a single build. Verification records therefore appear to be bound to a corrective loop: checks produce failures, failures produce further attempts, and attempts produce further records. A stream with this structure will accumulate volume at a rate tied to iteration count rather than to calendar time.
Second, the iteration distribution is strongly right-skewed. With a mean of 71.3 against a median of 29, and with 12% of attempts exceeding 200 iterations, the aggregate verification count is disproportionately influenced by a small minority of long-running attempts. This is the single most important structural observation for anyone attempting to compare record counts across systems: two pipelines with identical median behaviour but different tail behaviour will produce materially different verification totals. The ratio reported in Section 4.1 should be understood as reflecting this tail as well as the median case.
Third, the failure-label distribution is dominated by interface-level checks. Four of the five most frequently recorded failing labels concern externally observable interface state — whether a dashboard screenshot was present, whether an assistant responded, whether an assistant button was found, and DOM checks on the dashboard. Only "QA reasoning" (4 occurrences) is a reasoning-level label. Yu and Ling (2026) observe that GUI agents remain technically brittle, and the observed concentration of failures at the interface layer is consistent with that characterization, though the observed corpus is far too small to test it. Rombaut and Masoumzadeh (2024) argue for observability directed at agent *reasoning*; in this corpus, reasoning-level verification records exist but are the least frequent of the released labels. This is a correspondence worth noting, not a confirmation.
5.3 What the market-sensing stream's internal structure suggests
The market-sensing stream is not homogeneous. Half of its 500 records were categorized as AI Tool, with Business Opportunity and Market Signal accounting for 140 and 110 respectively. This composition complicates the way the ratio should be read.
If the analytical interest is in *market observation* specifically, then the relevant denominator is not 500 but the 110 records carrying the Market Signal label — against which the verification-to-sensing ratio would be far higher than 2.0. If, alternatively, the interest is in *any externally sourced information* used to inform product direction, then 500 is the appropriate denominator, and AI Tool records legitimately count. Both readings are defensible, and the choice between them is a definitional decision rather than an empirical one. This report adopted the inclusive definition and states the ratio accordingly, but flags that the composition of the denominator materially affects the result.
A second observation concerns scoring. The average signal score was 7.6, indicating that signals were recorded with a graded relevance attribute rather than as undifferentiated items. This matters because it means the market-sensing stream is at least partially quality-annotated, whereas the released verification summary reports a binary pass/fail structure with additional status dispositions. The two streams differ in how much interpretive metadata accompanies each record, and that difference is not captured by a count ratio.
A third observation is an absence. The released corpus contained no recorded linkage between intelligence signals and downstream action comparable to the linkage observed between failures and fix attempts. This absence should not be read as demonstrating that no such linkage exists in the system; it means only that no such linkage appeared in the data extract. Given the difference in how the two streams are bound to corrective or productive action, the density asymmetry of Section 4.1 may reasonably be read as an asymmetry in *tightness of coupling to action* as well as in record volume — but that reading extends beyond what was measured and is offered as a hypothesis for future work, not a finding.
5.4 Relation to prior work
The inward orientation of autonomous-system observability described by Boosa (2024) and Rombaut and Masoumzadeh (2024) provides a plausible, though untested, explanation for the observed asymmetry. If observability practice is organized around internal system state, then instrumentation effort will accumulate on the verification side by default. The present result is consistent with that expectation without demonstrating it: the corpus shows the asymmetry, not its cause.
Savajiyani (2026) characterizes multi-agent LLM networks as a new class of distributed system whose software-engineering conventions remain unsettled. The observed asymmetry is legible in that light: an unsettled instrumentation regime is unlikely to have produced deliberate balance between two heterogeneous telemetry classes. Zhong and Zhu (2026) identify persistent unreliability of autonomous software-engineering agents in realistic settings, which is consistent with the observation that 84% of builds required fix attempts, and with a verification stream that generates volume through correction rather than through routine confirmation.
Patel and Patil (2026) describe observability-driven, AI-augmented proactive quality engineering as a design goal. High verification density is an expected consequence of such a design, and the observed corpus is consistent with it. *Integrating a Model of Analytical Quality Assurance into the V-Modell XT* (2016) argues that quality-assurance planning should be grounded in economic factors; the present study offers no economic data, and therefore cannot say whether the observed density of verification is economically appropriate — only that it was observed.
*From consumer complaints to post-market quality signals* (2027) demonstrates, in a different domain, that organizations maintain in-process quality records and post-market quality signals under distinct governance regimes. The present finding — that the two are also recorded at materially different densities in an autonomous software pipeline — is a descriptive parallel. The domains differ sufficiently that no transfer of conclusions is warranted.
Zhang (2010) treats quality uncertainty as a market-side variable affecting commercial outcomes. If quality-relevant market information is decision-relevant, and if the sensing stream that captures it is half the density of the verification stream, one plausible reading is that market-side evidence is thinner than the internal evidence on which the pipeline acts. This study cannot support that reading empirically, because it contains no measure of decision quality or outcome.
5.5 Implications
The result has one clear practical implication and several unclear ones. The clear implication is that a raw comparison of telemetry volumes across these two categories is feasible and informative about the operating character of a pipeline: the observed system records internal verification at twice the density of external sensing, and its verification volume is dominated by a right tail of long-running attempts and by interface-level checks.
The unclear implications concern whether the asymmetry is a problem. It may be entirely appropriate: a system that must ship verified increments before sensing anything should verify more often than it senses, particularly if verification is cheap and sensing is expensive. Alternatively, it may reflect a sensing regime that is under-resourced or under-instrumented relative to the decisions it is meant to inform. The present data cannot distinguish these, because it contains no measure of the marginal value of a record in either stream, no measure of decision outcomes, and no comparison organization.
5.6 What this study does not establish
This study does not establish that verification telemetry is more valuable than market-sensing telemetry, nor the reverse. It does not establish that the observed ratio is optimal, excessive, or deficient. It does not establish that the asymmetry is caused by instrumentation culture rather than by the differing production economics of the two streams. It does not establish that the ratio is stable over time or characteristic of autonomous pipelines generally. It establishes one descriptive fact about one corpus: 1,000 verification records against 500 intelligence signals, a ratio of 2.0, tested against a pre-specified threshold of 1.5.
---
6. Limitations
**Single organization, single system.** The corpus derives from one production autonomous software development system operated by one organization. There is no second organization, no second system, and no external comparison corpus. No claim of generalizability is warranted, and none is made.
**No control condition.** The study is purely observational. There is no untreated condition, no counterfactual pipeline, and no manipulation. The primary result is a ratio of counts, and it carries no causal interpretation.
**Unit non-commensurability.** The primary measure compares QA check results against intelligence signals. These are produced by different processes, at different costs, on different cadences, and with different information content. The ratio of 2.0 is a record-count ratio. It should not be read as a ratio of effort, cost, informational value, or decision weight. This limitation is the principal constraint on the interpretation of the headline result.
**Extraction boundaries unknown to the authors.** Calendar bounds of the observation window were not included in the data release. Consequently no time-normalized density (records per unit time) can be computed, and no comparison of cadence between the streams is possible.
**Incomplete record release.** Only the most common failing verification check labels were released; these five labels account for 33 recorded observations and cannot be assumed to enumerate all failures. Per-build verification counts were not released. No downstream outcome measures — decisions, shipments, revenue, or sensing accuracy — were present. Absences in the extract are absences in the extract, not evidence of absence in the system.
**Internal inconsistencies in the released records.** The QA status categories (27 failed, 12 escalated, 6 pending) together with 8 verified builds sum to 53 against a separately reported total of 46 builds. The reported pass rate (94%) and fail rate (5%) sum to 99%. These inconsistencies were not resolved, and the affected counts are reported as released. They reduce confidence in the precision of the build-level status breakdown and are the reason that breakdown is treated as contextual rather than primary throughout this report.
**Sensitivity of the primary result.** The observed ratio of 2.0 sits one-third above the 1.5 threshold. Holding one stream fixed, a change of roughly 170 records in the sensing stream or roughly 250 records in the verification stream would bring the ratio to the threshold. The conclusion is therefore sensitive to the extraction boundary, which is not known to the authors.
**Definitional dependence of the denominator.** The reported ratio uses the inclusive definition of market-sensing telemetry, counting all 500 intelligence signals. Under a narrower definition restricted to the 110 records labelled Market Signal, the ratio would be far higher. The reported result is therefore conditional on a definitional choice that is stated explicitly rather than presented as the only reasonable one.
**No inferential statistics.** No confidence intervals, hypothesis tests beyond the pre-specified threshold comparison, or effect-size estimates were computed. The counts are reported as counts.
**Single-coder categorization.** Intelligence signal category labels and verification check labels were released as recorded by the study organization. No inter-rater reliability assessment of label assignment was possible, and label semantics were not independently audited.
**AI-assisted writing.** This manuscript was produced with AI assistance. The assistive tools were used in drafting and structuring prose. The quantitative claims were constrained to the released data block and verified against it, and all citations were drawn from a fixed reference list supplied to the drafting process. Readers should nevertheless weigh the possibility of drafting-stage error when assessing the prose, independently of the underlying data.
**Publisher interest.** This report is published by an organization with a stated interest in autonomous product pipelines. The study organization and the publisher are distinct entities for the purposes of this disclosure, and the study organization was anonymized throughout. Readers should apply the ordinary discount warranted by industry-published observational research.
---
7. Conclusion
This report tested a single, pre-specified descriptive hypothesis: that in a production corpus from an autonomous software development system, verification telemetry would exceed market-sensing telemetry by at least 1.5x. Against 1,000 recorded QA check results and 500 recorded intelligence signals, the observed ratio was 2.0. The hypothesis is supported for this corpus.
Contextual records characterize the system in which the asymmetry was observed: 500 build attempts across 46 builds, with a mean of 71.3 iterations per attempt against a median of 29 and a range of 4 to 300; 39 of 46 builds (84%) requiring at least one fix attempt, with a mean of 2.3 attempts where required and a maximum of 7; 8 verified builds (17%); 27 recorded failures, 12 escalations, and 6 pending outcomes; and 82 production capabilities deployed across 17 categories. The verification stream's most frequent failing labels were dominated by interface-level checks, while the market-sensing stream was half-composed of records categorized as AI Tool.
Two findings qualify the headline result and are part of it rather than incidental to it. First, the market-sensing stream is internally heterogeneous, and the reported ratio depends on the decision to count all externally sourced records as sensing; under a narrower definition the asymmetry would be substantially larger. Second, the released status records are internally inconsistent — status categories summing to 53 against a stated total of 46 builds, and pass and fail rates summing to 99% — and these inconsistencies constrain confidence in the build-level breakdown.
What this study shows is narrow and what it does not show is broad. It shows that one production autonomous pipeline recorded verification assertions at twice the density of external intelligence signals over one observation window. It does not show that this ratio is typical, that it is stable, that it is optimal, that it reflects deliberate design, or that it carries any consequence for product outcomes. Establishing any of those would require multiple organizations, a preregistered definition of the denominator, calendar-bounded extraction, and outcome measures that were not present in the corpus examined here. Until such data exist, the appropriate characterization of verification–sensing telemetry density in autonomous pipelines is that it appears asymmetric in the one production corpus available for inspection, and that the asymmetry awaits replication.
---