The Technology Expert's Role in Competition Proceedings: Counterfactuals, Feasibility, and Technical Evidence

Introduction

Competition proceedings involving technology markets present a distinctive combination of economic and technical questions. The economic analysis, typically provided by a specialist economist, addresses market definition, competitive effects, and quantification of harm. But the economic analysis often rests on technical assumptions about what the technology can do, what alternatives existed, and whether a particular market outcome was technically feasible. These are questions that an economist is not equipped to answer, and they are where the technology expert’s evidence becomes relevant.

The types of technical questions that arise in competition cases differ from those in other areas of technology litigation. The expert is not usually asked to identify a defect, trace a breach, or assess fitness for purpose. Instead, the questions tend to concern what was technically achievable at a particular point in time, whether a claimed barrier to competition has a genuine technical basis, and how the design of a platform or system affected the competitive dynamics of the market in which it operates.

Drawing on instructions in competition matters involving technology markets, I set out below the areas in which technology expert evidence is most commonly sought and what solicitors should be aware of when managing these cases.

Counterfactual feasibility assessments

A counterfactual analysis asks what would have happened in the absence of the conduct complained of. In competition proceedings, this is central to both liability and quantum. The claimant may argue that, but for the respondent’s anti-competitive conduct, a particular market outcome would have been achieved: competitors would have entered the market, interoperable products would have been developed, or consumers would have had access to alternative services.

The technology expert’s role in this context is to assess whether the counterfactual scenario is technically feasible. This requires an analysis grounded in the state of the technology at the material time, not at the date of the report. A counterfactual that depends on technology that did not exist, or that was not practically deployable at the relevant date, is technically infeasible regardless of its economic logic.

In practice, feasibility assessments involve examining the engineering constraints that applied at the material time, including the maturity of the relevant technology, the availability of development tools and infrastructure, the skill sets required, and the typical timelines for development and deployment of comparable systems. The expert draws on published standards, contemporaneous technical documentation, and their own experience of comparable engineering projects to assess whether the counterfactual could have been achieved within the timeframe and resource constraints that the economic model assumes.

It is important that the feasibility assessment is honest about uncertainty. In many cases, the question is not whether the counterfactual was certainly achievable or certainly impossible, but whether it was within the range of outcomes that a competent technology team could reasonably have been expected to deliver. The expert should frame the assessment in those terms, indicating the degree of confidence the evidence supports rather than presenting a binary conclusion.

Interoperability and platform competition

A significant category of technology competition dispute concerns the interoperability of software platforms and the extent to which platform design decisions affect competition. These disputes may arise in the context of abuse of dominance claims, where a platform operator is alleged to have restricted interoperability to foreclose competitors, or in merger assessments, where the question is whether a proposed combination would reduce competitive pressure by integrating previously interoperable systems.

The technical questions in these cases concern how interoperability works at a practical level. This includes the design and availability of application programming interfaces (APIs), the data formats and protocols used for communication between systems, and whether technical restrictions on interoperability serve a genuine engineering purpose (such as security, stability, or data integrity) or are primarily commercial in motivation.

Assessing this distinction requires an understanding of how the system was designed and how the relevant restrictions operate at a technical level. An API restriction that prevents third-party access to a particular dataset, for example, may be justified on data protection grounds, or it may be technically unnecessary and commercially motivated. The technology expert examines the system architecture, the documentation, and the design history to assess whether the restriction has a credible technical rationale.

Data portability is a related area. Where a platform holds user data, the ease with which that data can be exported and used in a competing service affects switching costs and, by extension, competitive dynamics. The technology expert may be asked to assess whether the platform’s data export tools produce output in formats that are usable by competitors, whether the data is complete, and whether the export process introduces practical barriers that reduce the effectiveness of portability rights.

In my experience, interoperability disputes benefit from precise technical evidence about what the system actually does, as opposed to what the platform operator says it does. The documentation may describe an open architecture, but the implementation may impose restrictions that are not apparent from the documentation alone. Examination of the code, configuration, and operational behaviour of the system is often necessary to provide a complete picture.

Best-practice benchmarking

In some competition matters, the expert is asked to compare the respondent’s technical practices against what would be expected of a reasonably competent participant in the relevant market. This benchmarking exercise serves a different function from the feasibility assessment. It does not ask what was possible in the counterfactual; it asks whether the respondent’s actual conduct was consistent with normal industry practice.

The methodology for best-practice benchmarking involves identifying the relevant comparator group (other participants in the same market or adjacent markets that face similar technical challenges), establishing the range of practices adopted by that group, and assessing where the respondent sits within that range. The evidence base for this analysis may include published standards, industry guidelines, academic literature, and the expert’s own knowledge of how comparable systems are designed and operated.

Benchmarking must be approached with care. Technology markets are diverse, and what constitutes best practice in one context may not be applicable in another. The expert should explain the basis for the comparator selection, acknowledge limitations in the available data, and avoid presenting a narrow comparison as representative of the entire market. The objective is to provide the tribunal with context for evaluating the respondent’s conduct, not to impose a single standard of practice across the industry.

The interaction between technology and economic experts

Competition proceedings typically involve both economic and technology expert evidence, and the two disciplines interact in ways that require coordination. The economic model may assume that a particular technical outcome was achievable, that switching costs were of a particular magnitude, or that a platform’s technical design had a specific effect on competitive conditions. Each of these assumptions has a technical dimension that the technology expert may be asked to validate, qualify, or challenge.

In my experience, the most effective approach is for the technology and economic experts to engage with each other’s evidence at an early stage, even where they are instructed by the same party. The technology expert should understand what the economic model assumes about the technology, and the economist should understand the constraints and uncertainties in the technology expert’s analysis. Where the experts are instructed by opposing parties, the joint statement process under CPR 35.12 provides a mechanism for identifying and narrowing the areas of disagreement between the technology experts, which in turn clarifies the factual foundation on which the economic analysis rests.

The division of responsibility should be clear. The technology expert should not stray into economic conclusions, and the economist should not make unsupported technical assumptions. In practice, the boundary can be difficult to maintain, particularly on questions such as switching costs (which have both a technical and an economic dimension) or the effect of interoperability restrictions on market entry (which requires both technical analysis of the restriction and economic analysis of its competitive effect). Where the boundary is unclear, the experts should identify the overlap in their reports and explain how their respective analyses interact.

Presenting technical evidence in competition proceedings

The Competition Appeal Tribunal and the Competition and Markets Authority are accustomed to receiving expert evidence, but the technical evidence in technology competition cases presents particular challenges. The tribunal may be well-versed in economic evidence but less familiar with the engineering concepts that underpin the technology expert’s analysis.

The expert report should be structured to build the tribunal’s understanding progressively, explaining the relevant technical concepts before applying them to the facts. Where the analysis involves system architecture, API design, data formats, or software engineering methodology, the explanation should be accessible to a reader with no technical background while remaining precise enough to withstand cross-examination from a technically instructed opposing expert.

Visual aids can be particularly useful in competition cases. System architecture diagrams, data flow charts, and comparative tables can convey technical information more effectively than narrative description alone. These should be included in the report and available for use during oral evidence.

The expert should also be prepared for the possibility that the opposing expert takes a different view on a technical question that has no single correct answer. Technology is not in every case deterministic in the sense that a mathematical proof is deterministic. Engineering judgments involve assessments of feasibility, reasonableness, and comparative practice that are inherently evaluative. The expert should be comfortable explaining the basis for their assessment, acknowledging where reasonable engineers might disagree, and maintaining their position where the evidence supports it.

Practical guidance for solicitors

Technology competition disputes are complex and document-intensive, and the following considerations may assist solicitors managing these matters.

Identify the need for technology expert evidence early. Where the competition claim involves allegations about platform design, interoperability restrictions, technical barriers to entry, or the feasibility of a counterfactual scenario, technology expert evidence is likely to be relevant alongside the economic evidence. The sooner the technology expert is engaged, the more effectively they can inform the case strategy and the framing of the economic model.

Ensure the letter of instruction addresses the technical questions specifically. A letter of instruction that asks the technology expert to “comment on the technical aspects of the case” is too broad to produce focused evidence. The instruction should identify the specific technical questions in dispute, the counterfactual scenarios to be assessed, and the interaction with the economic expert’s analysis. Where the technical questions are not yet fully defined, a scoping instruction is a practical first step.

Preserve technical evidence proactively. In technology competition cases, the relevant evidence may include source code, system configuration, API documentation, platform architecture records, and internal communications about design decisions. These materials may not be captured by standard document preservation processes, and specific instructions to the client’s technology team may be needed to ensure they are retained.

Plan for expert interaction. Where both technology and economic expert evidence is being adduced, the solicitors should facilitate communication between the experts at an appropriate stage. This does not mean the experts should coordinate their conclusions, but they should be aware of each other’s analysis and any assumptions that depend on the other discipline.

Consider the tribunal’s technical familiarity. The level of technical explanation required in the expert report depends in part on the tribunal. The CAT and the CMA have experience with technology cases, but the level of technical sophistication varies. The expert should be briefed on any previous decisions or rulings that indicate the tribunal’s approach to technical evidence, and should plan the presentation of their evidence accordingly.

Technology competition disputes sit at the intersection of engineering and economics, and the quality of the technical evidence can have a material bearing on the outcome. In my experience, the cases that proceed most effectively are those in which the technology expert is instructed with clear questions, given access to the relevant technical materials, and able to engage constructively with the economic analysis on which the case depends.