Introduction
Quantum computing remains a field of competing technical paths, rapid scientific progress and limited commercial proof. Buyers can face a target with exceptional gate fidelity but no repeatable deployment model, a cloud-distributed processor with low customer concentration but uncertain differentiation, or a government contractor whose awards depend on key personnel, security controls and rights in technical data. Conventional software metrics do not describe those assets adequately. Hardware specifications alone also fail to answer the transaction question.
The practical decision is whether the acquisition changes the buyer's probability of reaching useful computation and monetising it. That probability depends on the interaction of modality, engineering system, error correction, manufacturing, software, applications, route to market, contracts, talent, capital and regulatory permissions. The interaction may create value, or it may combine two expensive roadmaps without resolving either party's bottleneck.
This paper treats modality and customer access as separate value pools that must be reconciled. It does not rank one quantum architecture as universally superior. It provides a diligence and structuring method for boards, corporate-development teams, investors and technical advisers evaluating US quantum-computing transactions.
1 Define the acquisition decision
The board should state the constraint the transaction is intended to remove. A buyer may need higher-fidelity operations, a manufacturable control architecture, an error-correction capability, a specialised team, access to a federal programme, a cloud channel, a customer application portfolio or a credible path into another geography. Each objective requires different evidence and produces a different integration plan.
The decision statement should identify the expected capability after closing and the counterfactual. Management should compare acquisition with internal development, partnership, minority investment, licensing, cloud distribution and targeted hiring. The comparison should include time, capital, execution risk, exclusivity and reversibility. An acquisition can accelerate a roadmap, yet it can also lock the buyer into an architecture before technical uncertainty has resolved.
The board should avoid using market growth projections as a substitute for transaction logic. The decision should rest on a measurable change in capability, customer access or strategic position. The transaction case should specify the evidence that would disprove the thesis before signing and the milestones that will test it after closing.
2 Separate modality value from access value
Modality value arises from the physical and engineering path by which the target creates, controls, connects and reads qubits. It includes device architecture, fidelity, connectivity, coherence, gate speed, control electronics, cryogenic or optical systems, fabrication, calibration, error correction, software integration and the ability to reproduce performance. It may also include patents and tacit know-how that are difficult to transfer.
Customer-access value arises from the target's ability to reach, qualify, contract with and support users. It includes cloud listings, direct reservations, government vehicles, security eligibility, application partnerships, workflow integration, data rights, technical-support teams, renewals and customer trust. Access should be evidenced by transferable rights and behaviour rather than by a logo list or memorandum of understanding.
The two value pools interact. A strong modality can make a route to market more valuable. A strong customer base can provide workloads and feedback that improve hardware. The buyer should still model them separately so that one attractive narrative does not conceal weakness in the other.
3 Compare modalities through transaction requirements
Superconducting systems use fabricated electrical circuits at cryogenic temperatures and can support fast gate operations and semiconductor-style process learning. They can require complex cryogenic, packaging, calibration and interconnect systems. Trapped-ion systems use atomic ions controlled through electromagnetic and optical techniques, often with high-fidelity operations and flexible connectivity, while facing engineering questions around speed, optical control and scale.
Neutral-atom systems arrange atoms with lasers and can offer large, reconfigurable arrays and application-specific analogue operation. Their path to universal fault-tolerant computation depends on control, gate, error-correction and continuous-operation progress. Photonic approaches use light and integrated optical components, with potential manufacturing and networking advantages alongside demanding source, detector, loss, switching and system-integration requirements.
The transaction comparison should connect each modality to the target's actual product and evidence. Public roadmaps and demonstrations describe direction; they do not guarantee reproducibility, scale, cost or commercial timing. The buyer should compare the acquired system against the buyer's intended workloads, manufacturing base, cloud model and capital plan.
4 Build a capability map rather than a qubit league table
A qubit count can describe system size without describing useful performance. The buyer should map physical qubits, logical qubits, gate fidelity, connectivity, circuit depth, error-detection and correction, uptime, calibration burden, job throughput, latency, software compatibility and workload results. Each measure should state test conditions, date, version and independent verification.
The map should distinguish scientific demonstration, engineering prototype, available product and contracted service. A result obtained on a selected device under laboratory conditions may be strategically important. Its transaction value depends on whether the target can reproduce it across devices, maintain it over time and expose it through an operable service.
Cross-modality comparison requires caution because native operations, compilation, analogue versus gate models and performance metrics differ. The buyer should use workload-level tests and resource estimates where possible. A conclusion should explain the trade-off rather than compress unlike systems into a single score.
5 Test the path to fault tolerance
Fault tolerance is a programme of architecture, codes, logical operations, decoding, control, fabrication and system engineering. The target should show how physical performance converts into logical capability, which error model applies, what overhead is expected and which milestones have been demonstrated. The buyer should examine the assumptions behind resource estimates and the sensitivity to fabrication yield, loss, crosstalk, control error and decoder performance.
Company roadmaps can support diligence when reconciled with published results, internal test data and engineering plans. Google's Willow announcement emphasised below-threshold error correction on increasing surface-code arrays. IBM's roadmap describes fault-tolerant modules and a longer-term system path. QuEra's roadmap emphasises neutral-atom error-correction demonstrations and continuous operation. Those statements concern different architectures and milestones.
The transaction model should value achieved evidence separately from future milestones. A large portion of modality value may depend on a fault-tolerance claim that remains unproven at the required scale. Contingent consideration can align payment with independently defined demonstrations.
6 Diligence the full hardware stack
The target's moat may sit outside the qubit device. Control electronics, lasers, cryogenics, vacuum systems, packaging, photonics, calibration software, firmware, compilers, test methods and manufacturing recipes can determine performance and cost. The diligence team should identify each critical component, its owner, supplier, replacement time and qualification status.
The buyer should request a system bill of materials and dependency graph. It should identify single-source items, export-controlled components, custom tooling, university licences, foundry agreements and long-lead equipment. Supply agreements should be reviewed for change-of-control rights, volume commitments, price resets, exclusivity and access to failure analysis.
Capital expenditure should be linked to roadmap milestones. A target may need a new fabrication line, cleanroom, cryogenic facility or optical assembly capability before it can deliver the forecast system. The purchase price and integration budget should include that requirement rather than treating it as ordinary post-close growth investment.
7 Verify reproducibility and manufacturing evidence
The buyer should distinguish one high-performing device from a repeatable process. Evidence can include yield, variation, calibration time, failure modes, component life, rework, acceptance testing and performance distribution across systems. The diligence sample should cover multiple devices and production periods where available.
Manufacturing plans should identify which steps are internal, outsourced or shared with research institutions. Intellectual property may protect device design while manufacturing know-how remains concentrated in a small team. The buyer should assess whether process records, tooling, supplier relationships and quality systems can survive staff turnover or a site disruption.
Reproducibility can be made a closing or payment condition. An independent team can build or qualify a device using controlled documentation. The test should protect sensitive technology while demonstrating that the acquired capability is organisational rather than personal.
8 Diligence intellectual property by dependency
Patent counts do not show freedom to operate, enforceability or operational importance. The buyer should map patents, applications, trade secrets, copyrights, licences and know-how to the product architecture and roadmap. It should identify inventors, assignees, prosecution status, geographic scope, government support, university rights and encumbrances.
The map should show which claims protect the current system and which address future architectures. It should also identify design-around risk and blocking rights held by others. Where the moat depends on trade secrets, the buyer should examine access controls, employee agreements, laboratory records and the extent to which knowledge is documented.
Government-funded and university-originated work may carry licence, reporting, march-in or data-rights considerations depending on the instrument. Qualified counsel should confirm the applicable rights. The transaction should not value an asset as exclusive until ownership and third-party rights are clear.
9 Assess talent as a technical system
Quantum hardware companies can depend on a small number of physicists, device engineers, control specialists and application leaders. The buyer should identify who owns each critical decision, relationship and undocumented method. An organisation chart should be supplemented by a capability and succession map.
Retention design should reflect the work required after closing. Founders may be essential for architecture, but senior engineers, technicians, programme managers and customer scientists can carry equally important knowledge. Retention instruments should use service, transfer and milestone conditions that are achievable and consistent with employment law.
The buyer should evaluate cultural and scientific governance. A large corporate process can improve quality and scale while slowing experimentation. Integration should preserve protected research paths with accountable milestones, peer review and access to shared engineering resources.
10 Define customer access precisely
Customer access can mean a signed contract, cloud listing, reservation, funded research award, pilot, application partnership, reseller arrangement or informal relationship. Each category has different economics and transferability. The buyer should classify the portfolio and avoid treating all named counterparties as revenue customers.
For each material relationship, diligence should cover legal counterparty, product, term, committed and optional value, cancellation, acceptance, pricing, renewal, data rights, intellectual property, exclusivity, security, change of control and required personnel. Usage data should show jobs, reservations, support demand and movement from experimentation toward recurring workloads.
Customer access is valuable when it shortens the buyer's path to paid, repeatable use. A relationship that depends on the target's independent status, founder or modality may weaken after acquisition. The buyer should validate transfer through contract language and customer conversations conducted under an approved process.
11 Separate cloud distribution from customer ownership
Cloud platforms broaden access and reduce the need for customers to procure each provider directly. Amazon Braket documents access to trapped-ion, superconducting and neutral-atom systems, with task, shot and reservation economics. Azure Quantum has also provided access to multiple hardware providers. These channels can create discoverability, workflow integration and billing infrastructure.
A listing does not by itself create a defensible customer asset. The platform may control the billing relationship, usage data, placement and commercial terms. Customers can compare or switch providers. The target's value depends on contractual rights, differentiated performance, support relationships and the ability to convert platform usage into durable demand.
The buyer should map who owns customer identity, workload metadata, application code, results and support records. It should test whether the acquisition creates a conflict with a platform or other hardware participants. Channel continuity and equal-treatment provisions can matter to valuation.
12 Evaluate government and national-laboratory access
United States quantum programmes involve the Department of Energy, National Science Foundation, Department of Defense, NIST, intelligence organisations and national laboratories. A target may hold research awards, prototype agreements, subcontracts, cooperative agreements or facility access. Each instrument creates distinct rights and obligations.
Government contracts can include termination rights, funding contingencies, security requirements, cost rules, audit, domestic sourcing and rights in data or software. Federal Acquisition Regulation Part 35 addresses research and development contracting, while Part 27 addresses patents, data and copyrights. The contract schedule should state the instrument, funding status, deliverables, data rights, intellectual-property provisions and change-of-control requirements.
Eligibility can depend on personnel, facilities, cybersecurity and ownership. The buyer should confirm whether the combined entity can continue performance, access sites and protect controlled information. Revenue should be valued with the relevant option, cancellation and appropriation risks.
13 Map federal data and software rights
Government-funded work can create value and restrictions simultaneously. Technical data, software, reports, interfaces and test results may be delivered with unlimited, limited, restricted or negotiated rights depending on contract terms and funding. The target may own intellectual property while the Government holds broad use rights.
The diligence team should trace each deliverable to its funding source and clause. It should examine markings, repositories, subcontractor flow-downs and whether the company has preserved restrictions correctly. Missing markings or inconsistent records can weaken the assumed exclusivity of an asset.
The buyer should also identify data needed for future competition, maintenance or reprocurement. A government customer's rights may facilitate alternative suppliers. This does not eliminate value; it changes the durability and pricing of customer access.
14 Analyse revenue quality and concentration
Quantum revenue can include hardware sales, cloud usage, reservations, consulting, development contracts, grants and milestone awards. The buyer should separate each stream by margin, cash conversion, recurrence, cancellation and technical dependency. Reported growth can be driven by a small number of awards or acquisitions.
IonQ's 2025 annual filing describes customer concentration, long sales cycles and government-contract risks. It also records significant continuing losses and acquisition activity. Those disclosures illustrate the need to value revenue with its cost and risk rather than applying a mature software multiple.
The buyer should build customer cohorts and contract waterfalls. It should identify how much revenue depends on one agency, platform, research partner or application team. Concentration can be acceptable when the relationship creates technical learning and renewal evidence; it should still be reflected in scenario analysis and liquidity planning.
15 Test application evidence and willingness to pay
The transaction thesis should name the workloads that the combined system is expected to serve. Chemistry, materials, optimisation, machine learning and security are broad categories. The buyer should identify the problem instance, classical baseline, quantum resource requirement, accuracy, total workflow cost and decision value.
Scientific advantage, computational advantage and commercial value are separate tests. A benchmark can show performance beyond a classical method under defined conditions without establishing a paid workflow. An application pilot can show customer interest without establishing scalability or renewal.
Customer diligence should ask what decision changed, what classical method was displaced or complemented, which budget funded the work and what evidence would support expansion. Willingness to pay should be based on contracts and observed behaviour where available. Future application value should remain a scenario until supported.
16 Build the regulatory perimeter
US quantum-computing transactions can involve antitrust, export control, sanctions, foreign-investment review, government contracting, data security and sector-specific obligations. The perimeter depends on parties, technology, ownership, customers, locations and information access. Counsel should confirm current requirements for the specific transaction.
The Bureau of Industry and Security introduced controls in 2024 covering specified quantum computers and related equipment, components, materials, software and technology. Classification affects diligence access, integration teams, cross-border collaboration, cloud environments and future sales. The transaction timetable should include classification and licensing work rather than treating export control as a post-signing detail.
Foreign investors and cross-border buyers should assess CFIUS implications, including whether the business involves critical technologies and whether a mandatory declaration or voluntary filing is appropriate. The structure should protect sensitive technology without preventing the combined organisation from operating.
17 Evaluate antitrust and route-to-market foreclosure
The DOJ and FTC Merger Guidelines address transactions that may limit rivals' access to products, services or routes to market and transactions involving multi-sided platforms. A quantum acquisition may combine a hardware provider with a cloud, software, application or customer-access platform. The relevant question can extend beyond direct hardware competition.
The buyer should map competitors, customers, suppliers, platforms and complementors. It should identify whether the combined firm could restrict access to a scarce control technology, fabrication capability, cloud channel, benchmark data or customer programme. It should also consider access to rivals' competitively sensitive information.
Remedies and operating commitments should be considered early when the deal depends on an open ecosystem. Interoperability, information barriers, non-discrimination and supply commitments can preserve route-to-market value while addressing risk. The board should understand how any remedy affects the acquisition thesis.
18 Design technical diligence around falsifiable tests
Technical diligence should begin with management's most consequential claims. Each claim should have a test, dataset, version, owner, acceptance threshold and failure implication. Examples include a reproducible fidelity level, logical-error trend, calibration time, job throughput, manufacturing yield or workload result.
The buyer should use independent experts who can evaluate the modality without disclosing restricted information improperly. Clean-room or staged access may be necessary. The diligence report should state what was observed, what was reproduced, what was reviewed only as documentation and what could not be verified.
Claims that cannot be tested before signing can move into transaction mechanics. Holdbacks, milestones, access rights and termination provisions can allocate the uncertainty. A generic warranty that all technology works as intended provides limited protection against roadmap risk.
19 Construct a modality-adjusted valuation
Valuation should separate achieved assets from roadmap options. Achieved value can include functioning systems, patents, software, contracts, qualified facilities and reproducible know-how. Option value can include future fault-tolerance milestones, manufacturing scale, application breakthroughs and new markets. The discount rate or probability should reflect technical and commercial dependencies.
The model can use cost, income and market evidence selectively. Replacement cost may support specialised facilities and documented development, although it does not measure the probability of success. Income analysis can support contracts and customer relationships when cash flows are identifiable. Market transactions require careful normalisation because consideration, stage, modality and strategic context differ.
The board should see a value bridge by capability. A single enterprise value can conceal whether management is paying for technology, talent, channel, contracts, strategic defence or market signalling. Each component should have evidence and a post-close owner.
20 Use milestone-based consideration
Quantum roadmaps create a strong case for contingent consideration when milestones are objective, material and controllable. Technical milestones can include independently reproduced performance, a logical-qubit demonstration, manufacturing yield, continuous operation, system delivery or acceptance. Commercial milestones can include funded awards, customer conversion, renewals or gross-margin thresholds.
The agreement should define the test environment, responsible evaluator, permitted changes, data access, timing, dispute process and treatment after integration. A milestone should not depend entirely on the buyer's discretionary resource allocation. Sellers should have visibility into the work needed to achieve it.
Consideration can combine closing payment, milestone shares, retention instruments and customer-conversion payments. The allocation should distinguish purchase price from compensation and consider accounting and tax consequences. Qualified advisers should confirm the treatment.
21 Protect the roadmap through integration governance
The combined company needs one accountable roadmap. Modality teams may retain distinct research programmes, but shared capital, customers and engineering dependencies require explicit governance. The integration plan should identify which architecture remains primary, which capabilities are experimental and which decisions require board review.
A technical integration council can reconcile hardware, control, software, error correction, manufacturing and application priorities. It should own interfaces, resource conflicts and milestone evidence. Commercial teams should not promise capabilities outside the approved roadmap.
Integration should preserve useful scientific independence while removing duplicated corporate functions deliberately. Early consolidation of laboratories, toolchains or supplier relationships can destroy evidence and slow development. Sequencing should follow technical dependencies.
22 Retain customers during the change of control
The buyer should communicate the combined product, support model and data treatment before uncertainty drives customers to alternatives. Material customers may require consent, security review or revised ordering arrangements. Government counterparties may require notification or novation depending on the instrument.
The retention plan should identify customer owner, workload, contract status, technical dependency, change-of-control requirement, next decision and risk. It should protect continuity of cloud access, reservations, support and application teams. Pricing changes should follow evidence of improved capability rather than the announcement alone.
Customer conversion payments can align deal value with retained and expanded business. The metric should use collected or contractually committed value, defined margin and a clear attribution period. Pilots and non-binding collaborations should not receive the same treatment as recurring paid workloads.
23 Govern security and controlled information
Quantum companies can hold controlled technology, government information, customer data, source code, fabrication records and sensitive research. The integration perimeter should classify repositories, identities, laboratories, devices and collaboration tools before broad access is granted.
The buyer should preserve least privilege, export-control restrictions, contractual access limits and incident evidence. Employees and contractors should be mapped by nationality, location, role and authorisation where legally relevant. Sensitive diligence material should not migrate automatically into ordinary integration systems.
The Day One plan should define security authority, incident escalation, key custody, logging and continuity. A transaction can create risk if two strong control environments are connected without a common design. Security integration should follow a documented architecture and regulatory advice.
24 Build the capital and liquidity plan
Purchase price is one part of the capital requirement. The buyer may need to fund facilities, equipment, foundry commitments, component inventory, research programmes, retention, customer support and operating losses. The integrated model should show liquidity under technical delay and customer-conversion scenarios.
Equity can absorb roadmap risk. Debt may suit predictable assets or contracted cash flows when covenants recognise development volatility. Government awards and customer prepayments can support milestones, subject to restrictions and performance obligations. The financing mix should not force a premature technical claim to satisfy a near-term covenant.
The board should approve an acquisition reserve for technical and commercial remediation. It should identify conditions that trigger capital reallocation, partnership or programme closure. Strategic importance does not remove the need for portfolio discipline.
25 Define the first 100 days
The first 100 days should protect evidence, people, customers and roadmap accountability. Day One priorities include security, permissions, payroll, customer continuity, laboratory safety, supplier access and decision rights. The integration team should freeze destructive system changes until baselines are captured.
By Day 30, the company should reconcile the capability map, contracts, intellectual property, controlled information and capital plan. By Day 60, it should approve the combined roadmap, customer ownership and supplier actions. By Day 100, it should publish an internal milestone baseline with accountable owners and board reporting.
The plan should include explicit non-actions. Facilities, code repositories, brands and research programmes may remain separate until evidence supports consolidation. Delay can be a controlled decision when it preserves technical value.
26 Monitor value through a deal dashboard
The board dashboard should connect technical, commercial and financial evidence. Measures can include independently verified performance, system availability, job throughput, manufacturing yield, roadmap spend, critical retention, contract value, customer conversion, gross margin, government eligibility and integration risk.
Each measure should state baseline, target, owner, source and decision threshold. Metrics should remain comparable across periods and system versions. A technical improvement that increases cost or reduces availability should be visible as a trade-off.
The dashboard should separate observed results from management forecasts. It should also show milestone consideration and liquidity exposure. The purpose is to support capital allocation and intervention rather than to present a favourable narrative.
27 Prepare downside and exit paths
The buyer should plan for technical delay, modality reprioritisation, customer loss, regulatory restrictions and key-person departure. The downside plan can include licence structures, asset sales, team carve-outs, partnerships, research discontinuation and preservation of transferable intellectual property.
Transaction documents should secure access to records, source, tooling, suppliers and personnel needed to maintain acquired assets. Contingent consideration should adjust when milestones fail for defined reasons. Retention packages should avoid trapping capital in a programme that the board has rationally discontinued.
Exit value depends on clean ownership and separability. The integration design should record which assets and contracts belong to each programme. Excessive technical entanglement can make a future sale or partnership difficult.
28 Set the board decision agenda
The board should ask whether the deal removes a defined constraint, whether the target's capability has been reproduced, whether customer access transfers, whether regulatory paths are viable and whether the combined roadmap can be funded. It should understand the portion of value attributable to achieved evidence and the portion dependent on future milestones.
Approval conditions should include technical tests, intellectual-property confirmation, material contract consents, regulatory analysis, retention, security controls and a funded integration plan. The decision record should identify unresolved matters and the mechanism that prices or controls each one.
The final question is accountability. One executive should own the combined technical roadmap, one executive should own customer conversion and one board process should reconcile capital with evidence. Without that alignment, the acquisition can increase optionality while reducing the probability of execution.
Conclusion
A US quantum-computing acquisition should be valued as a system of evidenced capabilities. Hardware modality matters when it changes the buyer's path to useful, reproducible and scalable computation. Customer access matters when contracts, channels, security eligibility, data rights and support relationships survive closing and convert into paid work.
The transaction should separate those value pools, test their dependencies and connect consideration to milestones. Technical diligence should be falsifiable. Customer diligence should distinguish access from ownership. Regulatory diligence should shape information access, structure and timetable. Integration should preserve scientific value while establishing one roadmap and one capital-allocation process.
Boards can then make a disciplined choice among acquisition, partnership and internal development. The goal is a combined company with a higher probability of technical and commercial success, supported by evidence that can be reviewed after the announcement.
Appendix A Modality acquisition test
The modality test asks whether the target changes the buyer's fault-tolerance path, system performance, manufacturability, control architecture, application reach or time to an independently verified milestone. Each claimed change should identify evidence, dependency, capital requirement and responsible team.
The test should compare the target with an internal or partnered alternative. It should state which assets are transferable and which depend on individuals, suppliers, universities or government permissions. A result that cannot be reproduced should remain contingent value.
The test should be repeated after material changes in roadmap, regulation, supply chain or technical evidence.
Appendix B Customer-access test
The access test asks whether the target holds a transferable contract, platform right, security eligibility, application workflow or trusted support relationship. It should identify who controls customer identity, data, billing, renewal and technical support.
Each relationship should be classified as paid recurring work, committed project, funded research, pilot, platform usage, partnership or prospect. Value should reflect cancellation, concentration, change-of-control and key-person risk.
The test should use customer confirmation and observed usage where available. Future demand should remain a scenario until supported by commitment or collected revenue.
Appendix C Quantum M&A data room
The data room can contain architecture, performance evidence, test protocols, device history, error-correction plans, manufacturing records, bills of materials, supplier agreements, software repositories, patent schedules, invention records, university and government rights, employee agreements, customer contracts, cloud arrangements, security documentation and financial models.
Restricted technical material should use a controlled review process. The diligence report should record information that could not be reviewed and the resulting decision limitation. Missing evidence should become a condition, holdback or milestone.
The final data room should support integration and future financing. Records required to reproduce claims, operate systems and evidence rights should move into controlled repositories with named owners.
Appendix D Decision figures and tables

Proposed sequence for separating modality, access and integration value.

Wholly hypothetical management assumptions; USD million.

Proposed scoring framework; scores are management assumptions, not comparative performance claims.

Wholly hypothetical transaction structure; USD million.

Sequencing should preserve technical evidence and customer continuity.
| Area | Superconducting | Trapped ion | Neutral atom | Photonic |
|---|---|---|---|---|
| Core engineering | Cryogenics, fabrication, packaging and calibration | Traps, lasers, optics and control | Atom arrays, lasers, control and continuous operation | Sources, detectors, loss, switching and integration |
| Scale question | Yield, wiring, interconnect and error correction | Optical control, speed, modularity and manufacture | Gate quality, universal operation and correction | Component loss, fusion, feed-forward and manufacture |
| Deal evidence | Multi-device performance and process control | Reproducible fidelity and scalable control | Repeated arrays, gates and logical evidence | Manufacturable components and end-to-end loss budget |
| Integration risk | Facility and stack duplication | Specialist-team and optical-system dependency | Roadmap and application-model transition | Supply chain and system-assembly dependency |
Proposed transaction questions; no modality is universally preferred.
| Thesis | Required evidence | Principal dependency | Transaction treatment |
|---|---|---|---|
| Acquire modality | Reproduced performance and manufacturable roadmap | Technical team, suppliers and facilities | Milestone consideration and retention |
| Acquire customer access | Transferable contracts, usage and renewal evidence | Channel control and key relationships | Consent conditions and conversion payments |
| Acquire government position | Eligible entity, funded instruments and data-rights map | Security, appropriations and personnel | Regulatory condition and contract-by-contract review |
| Acquire strategic option | Defensible IP and funded experiment plan | Future technical and market evidence | Limited upfront value and staged capital |
Proposed minimum evidence by thesis.
| Access type | Evidence | Value support | Main risk |
|---|---|---|---|
| Recurring paid workload | Contract, usage, invoices and renewal | Cohort cash flow and margin | Concentration and switching |
| Committed project | Executed scope, funding and acceptance | Contracted backlog | Cancellation and delivery |
| Funded research | Award, milestones and data rights | Funded learning and option value | Rights, budget and non-recurrence |
| Cloud-platform usage | Platform records and support activity | Observed demand and discoverability | Platform control and low switching cost |
| Pilot or collaboration | Defined work and decision gate | Evidence of interest | No commitment or budget |
Proposed classification for valuation and integration.
| Value component | Illustrative amount | Evidence gate | Downside treatment |
|---|---|---|---|
| Modality technology and patents | USD 260 million | Reproduced system tests and rights confirmation | Milestone shares and holdback |
| Talent and know-how | USD 150 million | Critical-team retention and transfer plan | Service-based retention instruments |
| Customer and channel access | USD 110 million | Consent, usage and conversion evidence | Customer-conversion payments |
| Government-program eligibility | USD 60 million | Eligibility and contract continuity confirmed | Closing condition and specific indemnity |
| Other net assets and option value | USD 40 million | Asset verification and board-approved roadmap | Capped upfront allocation |
Wholly hypothetical management assumptions; not observed transaction terms.
| Gate | Diligence question | Evidence | Decision consequence |
|---|---|---|---|
| Export control | What technology and access are controlled? | Classification, licences and access map | Information perimeter and closing timetable |
| Foreign investment | Does ownership or access create a filing issue? | Ownership, technology and customer analysis | Filing, mitigation or structure |
| Antitrust | Can the deal restrict a route to market or platform? | Market, channel and information map | Remedy risk and thesis adjustment |
| Government contracts | Do awards and rights survive change of control? | Instrument, clauses, consents and eligibility | Novation, consent and valuation |
| Data security | Can systems and repositories be combined lawfully? | Classification, architecture and controls | Staged integration and information barriers |
Qualified counsel should confirm the current transaction-specific requirements.
| Measure | Day 10 | Day 30 | Day 60 | Day 100 |
|---|---|---|---|---|
| Technical evidence | Baselines secured | Capability map reconciled | Roadmap approved | Milestone tests scheduled |
| Customers | Continuity owners assigned | Consents and risks mapped | Conversion plan active | Retention evidence reported |
| People | Critical roles confirmed | Retention executed | Succession gaps funded | Capability transfer measured |
| Regulation | Access controls preserved | Filing and licence map current | Mitigation actions funded | Compliance dashboard active |
| Capital | Liquidity protected | Integration budget reconciled | Scenario triggers approved | Portfolio allocation reviewed |
Proposed evidence schedule.
| Decision area | Green evidence | Amber condition | Red condition |
|---|---|---|---|
| Modality | Reproduced capability changes roadmap probability | Material milestone remains testable and priced | Core claim cannot be reproduced or transferred |
| Customer access | Contracts, usage and consents support conversion | Access depends on manageable channel or key-person risk | Relationship is non-binding or non-transferable |
| Regulation | Viable classification, filing and operating path | Defined approval risk with protected timetable | Required access or ownership is unlikely to be permitted |
| Integration | One roadmap, owners and funded sequence | Temporary duplication with decision date | Conflicting architectures and no accountable owner |
| Economics | Value bridge and downside funding are explicit | Option value is capped and milestone-linked | Price depends on unsupported market projection |
Proposed decision framework.
Sources
- National Quantum Initiative, National Quantum Initiative overview. Read the primary source
- National Quantum Initiative, Supplement to the President's Fiscal Year 2025 Budget. Read the primary source
- National Quantum Initiative, Strategy Documents. Read the primary source
- National Quantum Initiative Advisory Committee, Renewing the National Quantum Initiative and related reports. Read the primary source
- United States Bureau of Industry and Security, Department of Commerce Implements Controls on Quantum Computing and Other Advanced Technologies, 2024. Read the primary source
- United States Bureau of Industry and Security, Export Administration Regulations Part 734 Scope of the EAR. Read the primary source
- United States Bureau of Industry and Security, Export Administration Regulations Part 742 Control Policy. Read the primary source
- United States Department of Justice and Federal Trade Commission, 2023 Merger Guidelines. Read the primary source
- United States Department of Justice, Merger Guideline 5 concerning access to products, services and routes to market. Read the primary source
- United States Department of Justice, Merger Guideline 9 concerning multi-sided platforms. Read the primary source
- United States Department of the Treasury, CFIUS Fact Sheet on Mandatory Critical Technology Declarations. Read the primary source
- Federal Acquisition Regulation, Part 35 Research and Development Contracting. Read the primary source
- Federal Acquisition Regulation, Part 27 Patents Data and Copyrights. Read the primary source
- Federal Acquisition Regulation, Subpart 27.4 Rights in Data and Copyrights. Read the primary source
- IonQ, Agreement to Acquire Oxford Ionics, 9 June 2025. Read the primary source
- IonQ, Completion of Oxford Ionics Acquisition, 17 September 2025. Read the primary source
- IonQ, Annual Report on Form 10-K for the year ended 31 December 2025. Read the primary source
- IonQ, Quarterly Report on Form 10-Q for the quarter ended 30 June 2026. Read the primary source
- IonQ, IonQ Federal announcement, 10 September 2025. Read the primary source
- Google Quantum AI, Meet Willow, 9 December 2024, updated 12 June 2025. Read the primary source
- IBM Quantum, Quantum Development and Innovation Roadmap, updated 2025. Read the primary source
- QuEra Computing, Quantum Roadmap. Read the primary source
- PsiQuantum, Company and technology milestones. Read the primary source
- Quantinuum, Quantum Systems Reference. Read the primary source
- Quantinuum, H2 Product Data Sheet, 2025. Read the primary source
- Amazon Web Services, Amazon Braket Quantum Processing Units. Read the primary source
- Amazon Web Services, Amazon Braket Pricing. Read the primary source
- Amazon Web Services, Braket Overview and Quantum Hardware Technologies. Read the primary source
- Amazon Web Services, Expanded Collaboration with QuEra, 15 June 2026. Read the primary source
- Microsoft Azure Quantum, Quantum Hardware Providers and Implementation Levels. Read the primary source

