Introduction
Optimisation determines routes, schedules, portfolios, production plans, power dispatch, network design, pricing, workforce allocation and many other operating decisions. These problems often contain discrete choices, interacting constraints and uncertainty. Exact classical methods can become expensive as instances grow, while heuristics can produce useful answers without proving optimality. Quantum approaches seek improvements in solution quality, runtime, scaling, energy use or the ability to explore difficult regions of a search space.
The commercial category is wider than the underlying science. A vendor may describe an offering as quantum optimisation when the delivered system combines a quantum processor, a classical optimiser, data transformation, mathematical formulation, decomposition, parameter tuning and business-rule validation. The final result can be valuable even when the quantum step contributes little. An acquirer needs to allocate value to the complete system and understand which capability remains differentiated as classical methods improve.
Benchmark design therefore becomes an M&A issue. A weak comparison can overstate technical progress, customer value and scarcity. A strong comparison defines the same task for each method, gives every solver an appropriate formulation and tuning budget, records complete elapsed and compute time, and measures results on held-out instances. It also identifies who selected the benchmark and which unsuccessful runs were excluded.
This paper converts those requirements into an acquisition process. It begins with the board's investment thesis, constructs an evidence ladder, specifies a matched-baseline protocol, connects technical results to customer contracts and develops a probability-weighted valuation. The intended readers are corporate-development teams, investors, founders, technical advisers and transaction committees evaluating quantum optimisation firms.
1 State the transaction decision
The board should define the capability it intends to own. The target may provide a solver, a modelling language, a hybrid orchestration layer, a vertical application, privileged hardware access, a team of optimisation scientists or an installed customer workflow. These assets create different benefits and require different evidence. A claim about quantum speed does not establish the value of customer integration, and customer revenue does not establish a quantum advantage.
The acquisition thesis should name the operational decision affected by the target. A logistics buyer may seek better route plans within a fixed planning window. An energy buyer may seek feasible unit-commitment schedules under more scenarios. A financial institution may seek portfolio solutions that satisfy complex limits. The committee should define the quality threshold, decision frequency, cost of delay and current classical process.
The counterfactual should include licensing, partnership, internal development, specialist recruitment, open-source adoption and continued use of classical solvers. Replacement time can support value when the target has documented models, integrations and domain knowledge. Historical research spend provides limited evidence when equivalent capability is available through a vendor or open repository.
The approval paper should separate three potential premiums. The first is a workflow premium for customer integration and operational adoption. The second is an optimisation premium for measured improvements over the customer's incumbent process. The third is a quantum premium for an improvement attributable to quantum resources under a fair comparison. This separation prevents one attractive result from supporting every part of the price.
2 Define advantage before testing it
Computational quantum advantage concerns a task that a quantum system performs beyond an identified classical comparator. Practical quantum advantage adds usefulness, complete resource accounting and a relevant operating context. Commercial advantage asks whether the result changes revenue, cost, risk, service or capital needs for a customer. These concepts require different proof.
An optimisation company can create commercial value without a demonstrated quantum advantage. Better problem formulation can improve a classical solver. A hybrid workflow can automate data preparation and constraint validation. A team can reduce planning time through domain expertise. The diligence report should credit these contributions directly and avoid attaching them to an unsupported technical label.
The comparator also matters. A basic simulated annealing implementation can be easy to beat while a tuned mixed-integer solver, decomposition method, metaheuristic or domain-specific algorithm may be much stronger. Recent research on robust benchmarking recommends application-specific formulations, hard and representative instances, holistic figures of merit and equitable hyperparameter training [4]. The buyer should use a portfolio of credible baselines when no single method clearly represents the state of the art.
Advantage can expire. Classical algorithms, hardware and solver libraries continue to improve. A result that exceeded a baseline at one date may become ordinary later. Valuation should therefore consider reproducibility, scaling and the target's ability to maintain an edge rather than capitalising one benchmark indefinitely.
3 Build the evidence ladder
The first evidence level is a defined optimisation problem. It should specify variables, objective, constraints, feasibility, data and an acceptance rule. The second level is a reproducible result on public or synthetic instances. The third level adds strong classical baselines and complete timing. The fourth uses held-out customer-relevant instances. The fifth demonstrates repeated results across problem sizes, hardware states and dates. The sixth is customer acceptance tied to a business decision.
Each level should preserve a reproducibility package. It should include code, data, instance generators, seeds, formulation choices, solver versions, parameters, hardware identifiers, calibration records, queue times, compute times, post-processing and exclusions. A buyer should be able to recreate the comparison from a clean environment without founder credentials.
The evidence ladder should also record the target's contribution. An ablation test can remove proprietary components while keeping the rest of the stack constant. If performance remains unchanged, the target's claimed asset may have limited incremental value. If the difference persists across held-out instances and strong baselines, the result supports a larger technical allocation.
Portfolio reporting should classify every product separately. One module may have accepted customer use, another may have laboratory evidence and a third may be a research proposal. A blended narrative can hide that distribution. The valuation model should allocate achieved value to controlled assets and treat later evidence levels as conditional options.
4 Design matched classical baselines
A matched baseline solves the same economic problem under comparable conditions. It receives the same data, constraints, feasibility rules and output-quality threshold. It should receive a formulation suited to its method. Forcing a classical solver into a quantum-native formulation can create an artificial disadvantage. Forcing a quantum method into an unsuitable representation can create the reverse distortion.
The baseline set should cover exact methods, commercial mathematical-programming solvers, open-source solvers, heuristics and the customer's incumbent process where relevant. The selection should be documented before final results are viewed. A technical adviser should review whether stronger or more appropriate methods were omitted.
Tuning budgets should be comparable. Variational methods can require substantial classical optimisation. Heuristics can also require parameter search. The protocol should state how many attempts, evaluations and researcher hours each method receives. Manual intervention after results are visible should be recorded. Founder-led tuning can represent valuable know-how while reducing product scalability.
The same stopping rule should govern the race. Comparisons can use best feasible solution within a time budget, time to reach a specified quality, probability of reaching a target or cost per accepted solution. QED-C optimisation benchmarks use performance profiles that connect solution quality with runtime and problem size [2]. This structure is more informative than a single best result.
5 Account for the full measurement clock
Execution time is one component of commercial time to solution. The complete clock can include data loading, problem transformation, embedding, compilation, queue delay, quantum execution, readout, repeated shots, error mitigation, decoding, classical optimisation, feasibility repair and business-rule validation. Omitting slow stages can change the transaction conclusion.
The buyer should record wall-clock time, processor time and billed cost. Cloud queues can vary across dates and account tiers. Reserved access, research credits or provider support may produce conditions that ordinary customers cannot obtain. The diligence result should therefore distinguish controlled compute time from access conditions.
Solution quality needs a pre-agreed measure. It can be an optimality gap, objective value, constraint violation, risk-adjusted return or service metric. Feasibility should be tested before economic value is assigned. A fast answer that violates operational constraints may have no customer use.
Scaling evidence should show several problem sizes and structures. A result at one small instance can reflect implementation overhead or chance. Error bars, repeated trials and a clear treatment of failed runs improve reliability. Current benchmarking research warns that poor benchmarks can misdirect scientific and engineering decisions [5]. The same risk applies to acquisition price.
6 Separate solver value from formulation skill
Real customer problems rarely arrive as ready-made binary quadratic models or circuits. Teams clean data, define variables, select objectives, encode constraints, decompose the problem and repair solutions. These activities can create much of the value. They should be documented as assets rather than absorbed into a broad quantum claim.
Formulation IP may include reusable templates, constraint libraries, decomposition rules, penalty calibration, instance generators and domain validation. A buyer should inspect version history, documentation and reuse across customers. A reusable formulation layer can support recurring product economics. A bespoke notebook maintained by one scientist supports a different risk and margin profile.
The transaction team should compare target performance with and without proprietary formulation work. It should also run the same formulation through alternative solvers. When several methods produce similar results, value may sit in modelling and integration. When the proprietary solver adds a stable improvement after formulation is held constant, the technical premium becomes more credible.
The operating model should state who maintains formulations as customer rules change. Regulatory limits, plant availability, network conditions and service requirements can make optimisation models perishable. Maintenance effort belongs in the cost and margin forecast.
7 Evaluate quantum annealing and gate based methods
Quantum annealing and gate-based optimisation differ in representation, execution and maturity. Annealing systems commonly address Ising or quadratic unconstrained binary optimisation forms. Gate-based approaches include QAOA and other variational or emerging algorithms. Hybrid services can combine both with classical preprocessing and post-processing.
QED-C's optimisation framework compares quantum annealing and QAOA using solution quality and execution performance [2]. This supports a consistent diligence language, although the buyer must still confirm that selected instances resemble valuable customer work. Public benchmarks can measure system behaviour without proving product-market fit.
A 2025 peer-reviewed benchmarking study reported high accuracy and substantially faster problem-solving time for a state-of-the-art quantum annealing solver on selected large, dense QUBO instances [6]. Its design, instance class, timing perimeter and classical comparators should be examined before applying the result to another firm. One published result cannot substitute for target-specific evidence.
For gate-based methods, the buyer should record circuit construction, depth, qubits, two-qubit operations, shots, parameter evaluations, noise mitigation and classical optimisation. Simulator results should be identified separately from hardware execution. The target's roadmap should specify which hardware improvements the commercial case requires.
8 Test held out and adversarial instances
Benchmark instances selected during development can favour the target. Held-out instances reduce that risk. The buyer should reserve a set that the target has not used for tuning and should control its release until the protocol is frozen. Customer data can be anonymised or represented through an agreed generator when confidentiality prevents direct use.
The test set should vary density, constraint structure, coefficient ranges, degeneracy and noise. It should include easy instances, hard instances and cases where the claimed method is expected to fail. Adversarial testing identifies the boundary of value and helps scope customer commitments.
The protocol should retain every attempted run. Exclusions require a stated reason and approval. Hardware interruptions, infeasible outputs and convergence failures are part of the operating record. Selective retention can materially distort success probability and expected cost.
An independent team should reproduce a sample. Independence can come from the buyer, a technical adviser or a mutually agreed laboratory. The role is to execute a frozen protocol and confirm records. It does not guarantee future performance; it reduces dependence on seller-controlled reporting.
9 Connect benchmarks to customer economics
Technical improvement creates transaction value when it changes a customer decision. A routing result may reduce kilometres, late deliveries or planner time. A production schedule may increase throughput or reduce energy use. A portfolio solution may improve return for a stated risk and constraint set. The customer metric should be defined before the benchmark.
The buyer should reconcile claims to contracts, acceptance records, invoices and cash. Research collaborations, grants, paid pilots, subscriptions and outcome-based fees have different economic meaning. A published customer logo confirms limited facts unless the underlying relationship is verified.
Customer references should identify the baseline actually used, the decision changed and the role of the quantum component. They should also identify classical alternatives considered, operating support required and whether results were repeated. Renewal and expansion provide stronger evidence when they relate to a maintained product.
Savings should be measured against a credible counterfactual. A new model may improve on a manual process while providing no advantage over available classical software. The target can still be valuable through implementation speed or domain expertise. The valuation should describe that value accurately.
10 Analyse revenue quality and cohorts
Quantum optimisation revenue can include subscriptions, solver licences, cloud usage, professional services, research awards, milestone payments and resale. The buyer should reconcile each category to signed terms, delivery, acceptance, invoicing and cash. Revenue recognition should follow the applicable accounting framework and contract facts.
Recurring product revenue should reflect a continuing obligation and renewal basis. A multi-year research contract provides visibility while funding bespoke work. Services revenue can demonstrate customer willingness to pay while depending on scarce specialists. Gross margin should include cloud, hardware access, optimisation support and customer-specific maintenance.
The cohort should show opening revenue, renewals, expansion, contraction, churn and cash. It should identify workload, solver, hardware, support hours and acceptance status. This allows the buyer to test whether stronger technical evidence predicts better retention or economics.
Pipeline should remain separate from contracted revenue. Quantum markets often involve long pilots and strategic announcements. Forecasts should use stage definitions, historical conversion and implementation capacity. Market-size estimates cannot replace a bottom-up customer model.
11 Map IP software and access dependencies
The target's stack can include proprietary code, open-source solvers, cloud APIs, hardware services, customer data and third-party models. Diligence should map ownership, licence, version, maintenance, assignment and replacement effort for every material component. Commit history and contributor agreements should support authorship.
Open-source software can reduce development time and expand distribution. It can also make a claimed algorithm widely available. The proprietary complement may sit in formulation libraries, tuning, workflow integration, data or customer relationships. Licence obligations and patent rights should be reviewed by qualified counsel.
Hardware access can be a hidden asset or dependency. Reserved capacity, favourable pricing, engineering support, early features and calibration information may support benchmark results. Contracts should be checked for change of control, termination, data use and continuity. The buyer should retest a credible alternative provider when possible.
Export controls and national-security rules can affect quantum software, technology and talent. Several jurisdictions have introduced controls on advanced quantum technologies. The transaction team should map locations, citizenship, technical thresholds, customer restrictions and required approvals with specialist advice.
12 Assess team and reproducibility risk
Optimisation capability often depends on researchers who understand both algorithms and customer domains. The buyer should identify critical roles across mathematical modelling, quantum algorithms, software engineering, hardware integration, sales and delivery. It should map each valuable product to named maintainers and documented procedures.
A clean build should run without local files, personal credentials or undocumented services. The team should reproduce benchmark outputs, deploy the workflow and resolve a controlled failure. These exercises reveal concentration and transfer risk.
Retention packages should follow dependency. Employment duration alone may not transfer tacit knowledge. Knowledge-transfer plans can include paired delivery, documented benchmark protocols, architecture records and customer handover. Consideration tied to service should be accounted for separately where required.
Hiring plans should reflect the integration model. A strategic buyer may already have classical optimisation, cloud and security teams. Overlap can reduce cost while creating retention risk. The model should include compensation, replacement time and the cost of maintaining research capability through the next evidence gate.
13 Review security and model governance
The acquisition perimeter includes source repositories, dependency registries, cloud credentials, customer data, model artefacts and execution logs. The buyer should examine access control, secrets management, software composition, vulnerability response, code review, build integrity and incident history. NIST's Secure Software Development Framework provides a useful control reference [23].
Benchmark integrity also needs governance. Results should be traceable to code, environment and data. Changes to instances, parameters and exclusions should be logged. Customer-facing claims should pass technical and legal review, especially when words such as advantage or superiority are used.
Data governance should cover provenance, permitted use, retention, transfer and deletion. Customer data used to tune a formulation may not be reusable after a change of control. Synthetic data and public benchmarks should be distinguished from proprietary datasets.
The buyer should create a remediation plan before close. Critical credentials, unsupported dependencies, missing assignments and material vulnerabilities can affect price, conditions and integration. Lower-priority improvements can enter the first one hundred days with owners and dates.
14 Build the replacement cost case
Replacement cost should estimate the resources and time required to reach equivalent customer capability. It includes research, formulation libraries, software, integrations, security, documentation, hiring, customer validation and failed experiments. Historical spend provides context while current replacement choices drive the transaction decision.
The model should deduct duplicated or obsolete work. Code tied to retired hardware, unreproducible experiments and one-off customer notebooks may have limited reusable value. Open-source substitutes and commercial solvers should reduce the cost of alternatives where appropriate.
Time can be more valuable than cost. A buyer facing a customer deadline or strategic platform race may pay to avoid two years of recruitment and validation. That premium requires a credible integration plan and evidence that acquired assets can be transferred.
Replacement cost should remain separate from income and option value. Combining methods can triangulate a range, but adding every method together double counts the same asset. The valuation committee should state how each method informs the conclusion.
15 Model income from observable drivers
The income model should start with existing contracts and cohorts. Product revenue can be forecast by customers, workloads, renewals, usage and pricing. Services should reflect utilisation, rates and specialist capacity. Research contracts should follow funded scope and renewal evidence. Cloud resale should use net economics where the target acts as an intermediary.
Gross margin should include solver licences, quantum processing, classical compute, data, support and customer-specific work. Engineering and research expense should fund maintenance and the next evidence gate. Sales cycles, security reviews and integration requirements should shape acquisition cost and working capital.
Terminal assumptions should reflect uncertainty. A company can grow through classical and hybrid optimisation before fault-tolerant hardware arrives. The model should avoid making all value depend on one hardware date. Scenario analysis can separate a durable workflow business from quantum-enabled upside.
Cash and annual cash use affect equity value and funding risk. A buyer should reconcile unrestricted cash, debt, commitments and transaction costs. The financing plan should cover the next technical and commercial milestones with a reserve for delays.
16 Construct the hypothetical valuation
Consider a wholly hypothetical target with USD 24 million of annual revenue. Recurring solver and workflow revenue is USD 10 million, services revenue is USD 8 million, research contracts are USD 4 million, and cloud resale and other income are USD 2 million. It holds USD 72 million of cash and uses USD 31 million annually. These figures are assumptions rather than observed company data.
Four scenarios frame enterprise value. A services-heavy optimisation business with limited repeatability is valued at USD 120 million. A workflow platform with reproducible classical improvement is valued at USD 300 million. A quantum-enabled product with matched-baseline evidence, customer acceptance and multi-provider operation is valued at USD 720 million. A category platform with repeatable scaling and strong recurring economics is valued at USD 1.4 billion.
Illustrative probabilities of 22 per cent, 43 per cent, 28 per cent and 7 per cent produce a weighted enterprise value of USD 467 million. The purpose is to demonstrate method. The probabilities and values require replacement with buyer-approved assumptions and target evidence.
The central allocation assigns USD 115 million to solver and formulation assets, USD 85 million to workflow software and integrations, USD 70 million to customer relationships, USD 45 million to data and benchmark assets, USD 82 million to team and know-how, and USD 70 million to quantum-advantage options. The final component should be protected through milestones because it depends on future evidence.
17 Apply an advantage adjusted scorecard
The scorecard should assess problem definition, baseline strength, timing completeness, solution quality, scaling, reproducibility, customer acceptance, rights, portability and economics. Each score requires evidence. A weighted total provides discipline while leaving the board responsible for judgement.
Baseline strength should receive a high weight because a weak comparator can contaminate every downstream claim. Customer acceptance and revenue quality should also receive significant weight because transaction value depends on adoption. Quantum attribution should remain separate from workflow value.
The scorecard should show deductions as well as uplifts. Missing data rights, founder-only operation, undisclosed exclusions, dependence on one provider and unreconciled customer claims reduce achieved value. A remediation plan can convert some deductions into contingent value.
Scores should be updated after independent testing and customer calls. The valuation range should move when evidence changes. A scorecard that remains fixed while diligence produces new facts has become presentation rather than analysis.
18 Structure consideration and integration
Upfront consideration can pay for controlled software, verified cash flow, customer relationships and team capability. Holdbacks and contingent consideration can depend on clean builds, held-out benchmarks, customer retention, recurring-revenue conversion and multi-provider execution. Milestones should be objectively measurable and within the relevant party's control.
Representations can address IP ownership, open-source compliance, benchmark records, customer contracts, data rights, security and provider agreements. Specific indemnities may be considered for identified exposures with legal advice. Conditions should cover required consents and access continuity.
The first one hundred days should preserve reproducibility. Repositories, credentials, environments, contracts and benchmark records should be transferred before systems are consolidated. Customer commitments should be reviewed against validated capability. Marketing claims should use approved definitions.
Post-close value tracking should connect technical metrics to customer outcomes and cash. A faster benchmark matters when it improves a delivery, renewal, margin or product decision. The integration ledger should show evidence, owner, cost, date and realised value for each acquisition thesis.
The purchase agreement should translate evidence quality into economic protection. Consideration paid at closing can cover controlled code, contracted revenue, transferable customer relationships and staff who have accepted retention terms. Deferred consideration can be linked to independently reproduced benchmarks, renewal of specified customer contracts, delivery of source-portable workflows and achievement of customer-level economic outcomes. Each trigger should define the data source, measurement period, permitted changes, dispute process and treatment of buyer-controlled dependencies.
A quantum-performance milestone should avoid a single headline runtime. It should require an agreed instance family, held-out cases, a named portfolio of classical comparators, equivalent tuning resources, a complete measurement clock and a stated solution-quality threshold. The milestone should also specify hardware availability, queue treatment, confidence intervals and minimum repetition counts. A result that depends on one device, one calibration window or one founder-controlled environment should receive a narrower payment than a result reproduced independently across dates and targets.
Customer milestones require equal discipline. Revenue can include consulting effort, research grants, cloud resale or unrelated classical optimisation. A commercial earn-out should identify the relevant product, contract type, gross margin, renewal definition, cash-collection rule and permitted service content. Cohort measures can distinguish expansion in repeatable software from revenue created by additional implementation labour. The buyer should retain audit rights over contracts, invoices, usage records and delivery staffing.
Integration should preserve scientific challenge. A joint steering group can include transaction leadership, optimisation specialists, product owners, finance, security and customer-success representatives. Its first decisions should approve the benchmark protocol, evidence repository, customer-value ledger and change-control process. Results that fail reproduction should enter a documented root-cause review covering data, formulation, parameter selection, compiler, device condition, classical comparator and post-processing.
The first one hundred days should produce four board outputs. The first is a controlled inventory of software, models, rights, data, access and people. The second is a reproduced benchmark pack with failed and successful runs. The third is a customer-economic reconciliation connecting accepted outputs to contracted value, gross margin and cash. The fourth is a revised valuation bridge that releases, defers or removes the quantum premium as evidence develops. These outputs convert technical uncertainty into specific transaction decisions while preserving the value of demonstrated workflow and customer capability.
Conclusion
Quantum optimisation acquisitions require a clear separation among solver science, classical engineering, modelling skill, workflow software, customer adoption and hardware access. Each component can be valuable. The price should identify its basis.
A defensible process starts with a defined customer decision and a matched set of classical baselines. It measures the complete clock, uses held-out instances, retains failed runs, tests reproducibility and connects outputs to contracts and cash. These controls reduce the risk that selective evidence supports an excessive quantum premium.
The valuation can then recognise proven workflow and optimisation capability while treating future quantum advantage as conditional. Staged consideration, holdbacks and post-close evidence gates align payment with transfer, customer retention and technical progress. This structure allows a buyer to act under uncertainty while preserving accountability for the acquisition thesis.
Appendix A Matched baseline protocol
The protocol should freeze the problem statement, data, instance generator, constraints, feasibility rules, quality threshold, solver set, formulations, tuning budgets, compute environment and stopping rule. It should identify the primary metric and secondary diagnostics. A reviewer should approve the design before the seller sees held-out instances.
Execution records should include every attempt, seed, parameter, solver version, hardware identifier, queue, compute time, post-processing, cost, output and exclusion. The reporting pack should show performance by instance and problem size with uncertainty. A clean-environment rerun should reproduce a sample.
Appendix B Customer evidence schedule
For each customer, collect the contract, statement of work, amendments, acceptance, invoices, cash, support records, benchmark claims and renewal evidence. Classify revenue as recurring product, usage, services, research or other. Record the optimisation decision, baseline, accepted metric, solver, provider and specialist effort.
Customer calls should confirm the decision improved, the operational baseline, frequency of use, switching cost, remaining manual work and renewal rationale. Any disagreement with seller records should be resolved before value is assigned.
Appendix C Valuation data room
The minimum data room should contain repositories, releases, architecture, dependency inventories, licences, assignments, patents, benchmark protocols, complete run records, customer cohorts, contracts, invoices, cash, provider agreements, security reports, workforce maps, budgets and forecasts. Every value component should link to an evidence folder and an owner.
The transaction model should include revenue by category, gross margin, support effort, research spend, cash, annual cash use, replacement cost, scenario values, probabilities, integration cost and contingent consideration. Assumptions should be dated and approved.
Appendix D Integration value ledger
The ledger should list each value initiative, baseline, target, evidence source, owner, cost, timing, dependency and realised result. Technical initiatives can include benchmark reproducibility, formulation reuse, provider diversification and workflow integration. Commercial initiatives can include renewal, product conversion, cross-selling and delivery-margin improvement.
The board should review the ledger at defined intervals. Unachieved value should trigger a product, capital or integration decision. The record preserves the link among acquisition thesis, evidence, cash and accountable execution.
Appendix E Decision figures and tables
Proposed sequence; each stage requires a reproducible record and acceptance rule.
Wholly hypothetical management assumptions; composite score combines accepted solution quality and complete time to solution.
Wholly hypothetical management assumptions; USD million.
Wholly hypothetical management assumptions; USD million.
Wholly hypothetical management assumptions; USD million.
| Level | Core question | Required evidence | Valuation use |
|---|---|---|---|
| Solver result | Does the method produce feasible, high-quality output? | Frozen problem and reproducible run | Technical capability |
| Comparative result | Does it exceed credible classical methods? | Matched formulation, tuning and complete clock | Optimisation premium |
| Scaling result | Does the difference persist as instances change? | Held-out sizes, repetitions and uncertainty | Conditional technical value |
| Practical advantage | Is the complete system useful under operating constraints? | Cost, latency, reliability and workflow evidence | Product value |
| Commercial advantage | Does a customer accept, pay and renew? | Contract, acceptance, cash and cohort | Income and relationship value |
Proposed definitions; each level requires separate evidence.
| Element | Required control | Failure mode | Review output |
|---|---|---|---|
| Problem | Same variables, objective, constraints and feasibility | Methods solve different tasks | Frozen specification |
| Formulation | Appropriate representation for each solver | One method receives an artificial handicap | Adviser sign-off |
| Tuning | Comparable budget and documented intervention | Seller tunes only the target | Complete parameter log |
| Time | End-to-end clock and billed resources | Quantum execution shown without preparation | Time and cost reconciliation |
| Instances | Public, customer-relevant and held-out sets | Development set selected for favourable results | Instance register |
| Reporting | Every run, exclusion and failure retained | Best runs presented selectively | Reproducible evidence pack |
Proposed minimum transaction benchmark.
| Contribution | Evidence | Common dependency | Valuation treatment |
|---|---|---|---|
| Problem formulation | Reusable models and constraint libraries | Domain experts | Software or know-how value |
| Classical optimisation | Baseline code and tuned performance | Third-party solvers | Controlled or licensed capability |
| Quantum component | Ablation and matched-baseline difference | Hardware access and noise | Conditional quantum premium |
| Workflow software | Integrations, monitoring and validation | Customer systems | Product and replacement value |
| Customer adoption | Acceptance, repeat use and cash | Change management | Relationship and income value |
Proposed attribution of customer outcomes.
| Value component | Illustrative amount | Evidence gate | Downside treatment |
|---|---|---|---|
| Solver and formulation assets | USD 115 million | Reproducible matched baselines and rights | Baseline-strength deduction |
| Workflow software and integrations | USD 85 million | Clean build and customer deployment | Remediation reserve |
| Customer relationships | USD 70 million | Acceptance, renewal and cash | Retention adjustment |
| Data and benchmark assets | USD 45 million | Provenance, transfer and contribution | Rights deduction |
| Team and know-how | USD 82 million | Critical-role retention and transfer | Service-based retention |
| Quantum-advantage options | USD 70 million | Held-out scaling and customer economics | Contingent consideration |
Wholly hypothetical management assumptions; not observed company or transaction data.
| Evidence | What it supports | Limitation | Valuation use |
|---|---|---|---|
| Research collaboration | Technical access and joint work | May lack production acceptance | Relationship evidence |
| Grant or award | Funded scope and policy support | Restricted use and limited recurrence | Contracted cash with conditions |
| Paid pilot | Budget and defined test | Bespoke delivery may not scale | Probability-adjusted conversion |
| Accepted deployment | Performance against agreed criteria | Renewal remains unproven | Product and contract value |
| Repeat paid use | Continuing operational relevance | May remain specialist dependent | Stronger income evidence |
Proposed classification for revenue diligence.
| Measure | Illustrative amount | Diligence question | Valuation consequence |
|---|---|---|---|
| Recurring solver and workflow revenue | USD 10 million | Renewal, margin and repeatability | Income support |
| Services revenue | USD 8 million | Specialist effort and product conversion | Services adjustment |
| Research contracts | USD 4 million | Restrictions and recurrence | Separate from product multiple |
| Cloud resale and other income | USD 2 million | Net economics and dependency | Margin adjustment |
| Unrestricted cash | USD 72 million | Availability and commitments | Equity-value reconciliation |
| Annual cash use | USD 31 million | Next evidence gate and financing lead time | Runway and dilution adjustment |
Wholly hypothetical management assumptions; USD million.
| Decision area | Green evidence | Amber condition | Red condition |
|---|---|---|---|
| Baselines | Several strong classical methods under matched rules | Limited baseline portfolio with remediation | Weak or seller-selected comparator |
| Reproducibility | Clean build and held-out rerun passed | Bounded founder intervention | Results cannot be recreated |
| Customers | Paid acceptance, repeat use and cash reconciled | Pilot or research contract with conversion plan | Logos or pipeline treated as recurring revenue |
| Rights and access | Code, data, licences and provider continuity confirmed | Costed remediation and alternative access | Critical capability unowned or non-transferable |
| Valuation | Workflow, optimisation and quantum premiums separated | Wide but explicit scenario range | Quantum label substitutes for evidence |
Proposed decision framework.
Sources
- Quantum Economic Development Consortium, Application-oriented performance benchmarks for quantum computing. Read the primary source
- Quantum Economic Development Consortium, Optimization Applications as Quantum Performance Benchmarks, 2023. Read the primary source
- Quantum Economic Development Consortium, Standards and Performance Metrics Technical Advisory Committee. Read the primary source
- L. M. Zermeño and collaborators, Towards Robust Benchmarking of Quantum Optimization Algorithms, 2024. Read the primary source
- T. Proctor and collaborators, Benchmarking quantum computers, Nature Reviews Physics, 2025. Read the primary source
- S. Kim and collaborators, Quantum annealing for combinatorial optimization: a benchmarking study, npj Quantum Information, 2025. Read the primary source
- A. Abbas and collaborators, Challenges and opportunities in quantum optimization, Nature Reviews Physics, 2024. Read the primary source
- IBM Research, Quantum Optimization. Read the primary source
- IBM Quantum Documentation, Qiskit Optimization. Read the primary source
- D-Wave Quantum, Ocean software documentation. Read the primary source
- D-Wave Quantum, Solver properties and parameters. Read the primary source
- Amazon Web Services, Amazon Braket Hybrid Jobs. Read the primary source
- Microsoft Azure Quantum, Optimisation solutions and provider documentation. Read the primary source
- Google Quantum AI, Quantum Approximate Optimization Algorithm. Read the primary source
- E. Farhi, J. Goldstone and S. Gutmann, A Quantum Approximate Optimization Algorithm, 2014. Read the primary source
- M. Sharma and H. C. Lau, A Comparative Study of Quantum Optimization Techniques for Solving Combinatorial Optimization Benchmark Problems, 2025. Read the primary source
- M. Hibat-Allah and collaborators, A framework for demonstrating practical quantum advantage, Communications Physics, 2024. Read the primary source
- Association for Computing Machinery, Transactions on Quantum Computing. Read the primary source
- National Institute of Standards and Technology, Quantum Information Science. Read the primary source
- National Science and Technology Council, National Strategic Overview for Quantum Information Science. Read the primary source
- International Organization for Standardization, ISO/IEC 4879:2024 Quantum computing vocabulary. Read the primary source
- National Institute of Standards and Technology, Cybersecurity Framework 2.0. Read the primary source
- National Institute of Standards and Technology, Secure Software Development Framework SP 800-218. Read the primary source
- IFRS Foundation, IFRS 3 Business Combinations. Read the primary source
- IFRS Foundation, IFRS 13 Fair Value Measurement. Read the primary source
- IFRS Foundation, IAS 38 Intangible Assets. Read the primary source
- International Valuation Standards Council, International Valuation Standards. Read the primary source
- United States Securities and Exchange Commission, Financial Reporting Manual. Read the primary source
- United States Securities and Exchange Commission, D-Wave acquisition of Quantum Circuits announcement, 2026. Read the primary source
- United States Securities and Exchange Commission, D-Wave business combination and fair-value disclosures, 2026. Read the primary source
- United States Securities and Exchange Commission, Terra Quantum business combination announcement, 2026. Read the primary source
- United States Securities and Exchange Commission, Horizon Quantum business combination completion announcement, 2026. Read the primary source
