Intelligence on the Device: Pricing Privacy, Latency and Hardware Reach in AI M&A

1. Define the on-device transaction thesis

An on-device AI acquisition should solve a specific strategic problem. The buyer may need lower cloud exposure, faster interaction, offline resilience, local data processing, access to a device ecosystem, differentiated hardware utilisation or a distribution channel that places intelligence close to the user. Each thesis produces a different diligence burden and valuation logic.

The seller's claim should be expressed as a measurable chain: compatible device, installed software, activated feature, eligible task, accepted outcome, customer value, realised price and retained cash contribution. A break in the chain limits value. A model can run on a device without users activating it. An activated feature can fail quality or consume excessive battery. A valuable outcome can remain trapped inside a fixed price.

Apple's Core ML documentation states that on-device execution can remove the need for a network connection, support privacy and responsiveness, and use CPU, GPU and Neural Engine resources.^[1] Google's AI Edge materials position on-device models around low latency and local data.^[2] These are platform capabilities. A transaction team still needs company-specific evidence across the supported estate.

2. Classify the workload before selecting the route

The relevant question is not whether the product is on-device. It is which tasks belong on which route. A bounded classification, local transcription or sensor-detection task can fit a device envelope. A large multi-source investigation can require cloud models, search and extended context. A consequential action can require central controls or authorised review.

Task classification should record input type, model requirement, memory, energy, latency, connectivity, data sensitivity, tool access, consequence and quality threshold. The product can then define an approved route and fallback. The same application may use all four locations in Figure 1.

Company-specific evaluation determines which route meets the approved outcome standard.

The taxonomy should be versioned. A route that works on a current flagship processor may fail on an older device or after an operating-system change. A seller should state the supported minimum hardware and software for every material feature.

3. Build the hardware-reach denominator

Installed base is frequently presented as strategic reach. The economic denominator is narrower. It begins with devices technically compatible with the model and runtime. It then removes unsupported operating systems, insufficient memory or storage, unavailable accelerators, excluded regions, uninstalled applications, disabled permissions, inactive accounts and users who do not activate the feature.

The remaining active supported estate should be measured by cohort. Devices age, batteries deteriorate, operating systems fragment and vendors change access. A buyer should understand the replacement cycle and the seller's ability to maintain performance without abandoning customers.

The buyer should reconcile each layer to a system of record and a stated measurement date.

4. Turn privacy into an evidenced product claim

Local processing can reduce transmission of eligible raw inputs. It does not prove that all data stays on device. Telemetry, crash logs, retrieval, model updates, cloud fallback, support, advertising, analytics and account systems can still move data. The buyer should map the actual path for every material task and fallback.

The privacy claim should specify which inputs remain local, which derived data leaves the device, how long data is retained, whether a provider can use it for model improvement, where processing occurs and how deletion works. User controls and contract language should match implementation.

Apple's Private Cloud Compute materials describe a security architecture for cloud processing used when a request needs larger models, including verifiable software and privacy protections.^[8] The existence of a privacy-oriented cloud design reinforces the need to examine hybrid paths rather than assume a binary device or cloud architecture.

Claims enter valuation only when technical, contractual and customer evidence agree.

5. Price latency and offline resilience

Latency is an end-to-end service measure. Model execution time is only one component. Model loading, prompt construction, retrieval, tool use, thermal throttling, memory pressure, operating-system scheduling and user-interface rendering can influence the result. The product should measure median and tail latency by device class and task.

MLCommons defines mobile inference scenarios and reports percentile latency, throughput and quality targets.^[3] Standardised results can inform hardware comparison, while product diligence requires the actual application, model and device estate. A benchmark result on an available flagship system does not establish performance on the seller's full installed base.

Offline resilience can carry value in travel, field work, industrial operations and constrained networks. The product should state which functions work offline, how long they remain available, how updates and credentials behave, and how state synchronises when connectivity returns. Customer evidence should show that resilience influences adoption, retention or price.

6. Reconstruct complete device economics

On-device execution can reduce metered cloud inference for eligible tasks. It introduces another cost stack: model conversion and compression, device-specific optimisation, application size, download bandwidth, storage, evaluation, operating-system certification, telemetry, support, cyber-security, model update, rollback and a wider compatibility matrix.

Energy and battery use affect the customer experience and can create support or adoption cost. Memory pressure can limit concurrent functions. Thermal throttling can change sustained performance. Hardware vendors may include accelerators in the device price, while application companies still incur engineering and distribution cost.

The economic ledger should compare routes at the accepted-outcome level. A cloud route may cost more per request and support a wider capability. A device route may have low variable provider cost and high fixed engineering cost. The breakeven depends on eligible volume, reach, quality, lifecycle and customer price.

7. Govern model size, compression and quality

Device deployment often uses smaller models, quantisation, pruning, distillation or specialised architectures. These techniques can reduce memory, energy and latency. They can also change quality, robustness and behaviour. Every material variant requires evaluation on representative tasks and devices.

Apple publishes example model information with device-specific inference times and model variants.^[4] Google documents mobile deployment paths for Gemma through its edge tooling.^[5] These sources show that performance depends on model, precision, device and software stack. The target company's measured results remain the transaction source of truth.

The model register should record source, licence, training and fine-tuning rights, architecture, precision, supported devices, runtime, quality threshold, release date, rollback and end-of-support. A transaction should identify whether a critical optimisation depends on a founder, a non-transferable tool or confidential platform access.

8. Use hybrid routing as the control plane

Hybrid routing decides whether to execute locally, at site edge, in private cloud or in public cloud. It can preserve local processing for sensitive or interactive tasks and escalate complex work to stronger models. The router should evaluate device capability, task class, consequence, connectivity, data policy, quality, latency, cost and service availability.

Fallback economics belong in the ledger. A device route can fail because the model is unavailable, the hardware is unsupported, resources are constrained or quality falls below threshold. The cloud fallback may protect the outcome while increasing cost and changing the data path. The product should disclose that path to the customer where required.

9. Underwrite distribution and platform control

On-device value often depends on a platform owner, semiconductor vendor, operating system, app store, original-equipment manufacturer or enterprise device manager. The target may have contractual access, a technical integration, a preferred distribution position or merely the ability to publish an application. These positions have different durability.

The buyer should examine approval rights, APIs, entitlements, store rules, revenue share, ranking, pre-installation, default status, update controls, security requirements and termination. A distribution agreement can expire. An operating-system owner can replicate a feature. A hardware roadmap can deprecate the target's optimisation.

Strategic reach also depends on enterprise deployment. Mobile-device management, security review, procurement, model update and data policy can determine adoption. Consumer download counts should not be treated as enterprise distribution evidence.

10. Secure model, software and data rights

The transaction needs transferable rights to every material model, weight, dataset, runtime, compiler, library and optimisation. Open-source labels do not remove licence obligations. Model licences can restrict use, redistribution, hosted service, branding or scale. Third-party code can impose notice, source or patent conditions.

Training and evaluation data require provenance, permission and retention records. Device telemetry can contain personal or commercially sensitive information. The buyer should understand whether customer contracts permit the intended integration, model improvement and cross-product use.

Employee and contractor assignments should cover inventions, code, models, data pipelines and documentation. Joint development and university arrangements can create background and foreground rights. A critical model optimisation that cannot transfer can weaken the acquisition thesis.

11. Treat cyber-security as part of edge economics

Distributing a model to devices changes the attack surface. Adversaries can inspect application packages, extract weights, manipulate inputs, tamper with runtime state or exploit update channels. The company should assess model confidentiality, code signing, secure boot, hardware-backed keys, attestation, sandboxing, update integrity and rollback.

Device compromise can produce false outputs or unsafe actions. Consequential workflows need validation, permissions, rate limits and confirmation. Telemetry should detect abnormal behaviour without undermining the privacy proposition.

Security cost belongs in the product model. A larger estate requires vulnerability response, supported-version management and incident communication. Unsupported devices can become both a security risk and a customer-retention problem. NIST's Secure Software Development Framework provides relevant development guidance, while its AI Risk Management Framework and Generative AI Profile support broader governance.^[31][32][33]

12. Map regulatory and export constraints

Privacy, AI, consumer, cyber-security, product-safety, employment and sector rules can apply according to use and jurisdiction. Local processing can reduce some transfers. It does not remove transparency, lawful-basis, security, accuracy, discrimination, human-oversight or record obligations.

The European Union AI Act uses risk-based obligations and includes rules relevant to providers, deployers and general-purpose AI under the applicable timetable.^[34] The General Data Protection Regulation and supervisory guidance remain relevant to personal-data processing.^[35] Transaction teams should obtain current advice for the actual product and geography.

Export controls and sanctions can affect advanced hardware, software, encryption and technical support. Hardware reach should exclude jurisdictions or customers that cannot be served lawfully. A buyer should not value theoretical reach that is contractually or legally unavailable.

13. Define the M&A rationale and counterfactual

The acquisition case should identify what the buyer gains faster or more reliably than through partnership or internal development. Possible assets include edge-optimised models, compilers, runtime software, device telemetry, distribution rights, an active installed base, enterprise contracts, specialist engineers or hardware relationships.

The counterfactual should estimate build cost, time, platform access, opportunity cost and failure risk. A buyer with a large installed base may value the target's model and runtime. A model company may value the buyer's distribution. A semiconductor company may value workloads that increase accelerator utilisation. The synergy model should follow the relevant party's assets rather than assume every buyer can realise the same value.

Competition review can examine market definition, foreclosure, data, ecosystems, interoperability and innovation. The United States Department of Justice and Federal Trade Commission publish Merger Guidelines; the European Commission and United Kingdom Competition and Markets Authority publish merger-review guidance.^[36][37][38] Current legal advice is required for the actual transaction.

14. Build the acquisition operating model

The buyer should decide which components remain independent and which integrate. Model development, device optimisation, application experience, distribution, cloud fallback, customer contracts and governance can have different owners. Integration that centralises every decision can slow a product whose advantage is rapid device-specific iteration.

Architecture and commercial governance should meet. A product team can select the route. Finance should reconcile cost and customer price. Security and privacy teams should approve the data path. Sales should avoid promising unsupported devices or unlimited expensive fallback. The board should see one reach and contribution ledger.

Retention of specialist engineering talent can be important. The diligence team should map critical knowledge, documentation, succession, incentives and work authorisation. A transaction should avoid attributing technology value to an individual whose knowledge has not been institutionalised.

15. Hypothetical acquisition case

Consider a hypothetical acquirer evaluating an enterprise productivity application with on-device and hybrid AI. Every number in this section is a management assumption created solely to demonstrate the method. It does not describe a named company or market forecast.

The seller cites 80 million addressable devices. Technical and support review identifies 52 million compatible devices and 41 million supported devices. The application is active on 14 million supported devices. Four million users activate the AI feature, and 2.8 million produce at least one accepted outcome in the month. Of those users, 1.2 million are linked to paying enterprise or premium accounts.

The product processes 48 million eligible tasks. Fifty-eight per cent execute on device, 12 per cent at local or private edge, and 30 per cent in public cloud or cloud fallback. Monthly recognised revenue allocated to the AI-enabled offer is AED 8.4 million. Complete direct cost is AED 3.36 million, producing AED 5.04 million of contribution, or 60.0 per cent.

Every value is an illustrative management assumption and requires company-specific evidence.

The year-two case assumes wider supported reach, higher activation, more paying users, improved device execution and a lower fallback rate. It also funds model updates, security and support. Each change requires operating evidence. A buyer should keep unsupported reach and untested routing savings outside the base case.

16. Stress reach, routing and customer price

The downside should begin with reach. A compatibility problem can reduce eligible devices. An operating-system change can increase support cost. A quality gap can increase cloud fallback. Privacy concerns can reduce activation. A platform change can weaken distribution. These effects can occur together.

Every value is an illustrative management assumption for method demonstration.

Sensitivity should flow into cash, integration funding and transaction structure. A buyer should model update and support cost through the hardware lifecycle rather than use one steady-state percentage. Device replacement can expand capability while leaving a tail of customers on older hardware.

17. Value supported reach and retained contribution

An on-device AI valuation should begin with the supported economic estate rather than the installed-base headline. The opening denominator is the number of devices that satisfy the required processor, memory, storage, operating-system, security and application conditions. The next gates are active use, feature activation, accepted outcomes, paying accounts and retained contribution. Each gate should have a reproducible source and a period definition.

The income approach can model cash flows from paying use, renewal, expansion and verified cost avoidance. Revenue should reflect the contract and revenue-recognition policy. Direct cost should include device testing, model optimisation, software updates, cloud fallback, telemetry, evaluation, security, support and platform fees. Working capital, capital expenditure, tax and integration spending then convert operating contribution into cash. IFRS 13 and the International Valuation Standards provide relevant fair-value and valuation principles; IFRS 3, IAS 36 and IAS 38 govern important accounting questions after a business combination.^{[40][41][42][43][45]}

The market approach requires careful normalisation. A revenue multiple from a cloud-software company can misstate value when the target bears device-qualification cost, hardware fragmentation and long support tails. A semiconductor multiple can misstate value when the target controls neither chip economics nor distribution. Comparable transactions should be adjusted for supported reach, paying penetration, route mix, margin policy, customer concentration, recurring revenue, intellectual-property control and the maturity of the operating evidence.

A cost approach can help test the replacement cost of models, runtimes, compilers, data, integrations and specialist teams. It rarely captures distribution, customer contracts or time-to-market on its own. The analysis should also recognise obsolescence. A technically impressive model can lose economic value if a platform owner supplies a substitute, if hardware generations change, or if the target lacks the rights to maintain and commercialise the stack.

The bridge is a diligence structure. Company-specific values require verified records and an approved valuation method.

18. Separate buyer synergies from target stand-alone value

Synergy analysis should name the resource, owner, action, timing, cost and dependency. A handset manufacturer may contribute distribution and hardware integration. A software platform may contribute accounts, developer access and a billing rail. A model provider may contribute research capacity. A semiconductor company may contribute optimisation tools and accelerator access. The target should receive stand-alone value for resources it controls. Buyer-owned distribution or procurement power belongs in a separate synergy case.

Revenue synergies require a route to customer. The model should identify eligible accounts, sales motion, activation, realised price, renewal and cannibalisation. Cost synergies require a complete baseline and a credible implementation plan. Cloud-cost reduction should deduct the added cost of device engineering, estate testing, observability and support. Headcount savings should account for retention, severance, knowledge transfer and the need to maintain the acquired capability.

Double-counting is a recurring risk. Higher revenue, higher margin and a higher multiple may all reflect the same improvement. The valuation committee should show the causal bridge and use one treatment. It should also separate synergies available to several plausible buyers from synergies unique to the selected acquirer. Competitive tension can affect price, while the investment case still needs an executable cash-flow basis.

19. Build a reproducible diligence room

The diligence room should connect product claims to records. A buyer should be able to select a device cohort, reproduce eligibility, trace a task through routing and quality controls, link the accepted outcome to the account, reconcile the invoice, and identify the direct cost. Sampling should cover important device families, operating-system versions, geographies, customer segments, workloads and failure states.

Technical evidence includes model cards, evaluation sets, release histories, runtime dependencies, device matrices, power and thermal tests, fallback logs, update mechanisms, security architecture and incident records. Commercial evidence includes contracts, price schedules, entitlements, usage cohorts, renewals, support tickets, channel terms and platform dependencies. Financial evidence includes revenue policy, cloud invoices, device-lab spend, engineering allocation, warranty or support provisions, capitalised development and cash collection.

Legal diligence should cover ownership, open-source obligations, model and data licences, employee and contractor assignments, privacy notices, consent, processor terms, export controls, customer restrictions and change-of-control clauses. Security diligence should test the update chain, key management, local data protection, model extraction, malicious input handling and fleet response. NIST's AI Risk Management Framework, Cybersecurity Framework and Secure Software Development Framework can support a structured review.^{[29][30][31][33]}

The checklist requires tailoring to the product, transaction and jurisdictions.

20. Allocate risk through transaction terms

Price structure can reflect evidence quality. Consideration may combine cash at close, deferred payments, escrow, holdbacks, earn-outs or contingent value tied to measurable outcomes. Metrics should be within the operating team's influence, consistently defined and auditable. Installed-base or inference-volume metrics can reward uneconomic activity. Paying accepted use, retained contribution, renewal and supported estate quality are usually closer to durable value, subject to the actual deal.

Representations and warranties can address intellectual-property ownership, licences, privacy, security, compliance, contracts and financial information. Covenants can require maintenance of documentation, access, security response or regulatory cooperation between signing and closing. Specific indemnities may address identified issues. Warranty and indemnity insurance can alter recourse but does not replace diligence. Legal advisers should design the package for the transaction and jurisdictions.

Integration funding should sit beside purchase price. The buyer may need device laboratories, model optimisation, security remediation, contract migration, platform certification, retention and cloud capacity. A lower purchase price does not create value if the implementation budget is absent. The board should approve acquisition consideration, required investment and downside liquidity as one capital decision.

21. Run a 180-day evidence-led integration

The first thirty days should preserve service, people and evidence. The buyer confirms ownership, protects critical staff, freezes unsupported product promises, establishes the reach and contribution baselines, and names accountable leaders for product, finance, privacy, security and platform relationships. Material incidents and contractual deadlines receive immediate attention.

Days 31 to 90 establish common measurement and controls. The team reconciles the device matrix, route telemetry, evaluation method, complete-cost policy and customer entitlements. It remediates critical security or privacy gaps, aligns release governance and tests the investment case on selected cohorts. Commercial teams receive an approved claims and pricing framework.

Days 91 to 180 scale only verified improvements. The team expands supported hardware where quality and contribution pass the gate, renegotiates material platform or supplier terms where feasible, and launches cross-sell or premium offers with controlled measurement. The investment committee receives the stand-alone case, realised synergies, remediation spend and revised downside.

22. Make the transaction decision explicit

The final decision memorandum should state the transaction thesis in one sentence, identify the evidence that supports it, and show the conditions that can invalidate it. It should present stand-alone value, buyer-specific synergies, integration cost, downside liquidity and the proposed risk allocation. Open findings need an owner, deadline and treatment in price, terms or closing conditions.

A proceed decision may be appropriate when the target controls important technology or distribution, supported paying reach is reproducible, accepted outcomes are strong, complete contribution is durable, rights are clear, and integration is executable. A conditional decision may require remediation, a staged investment, commercial partnership, licence, asset purchase or contingent consideration. A decline decision can be rational when reach depends on unsupported devices, quality requires persistent expensive fallback, rights are uncertain, platform concentration is uncontrolled, or the seller's valuation relies on buyer-owned synergies.

Governance continues after approval. Monthly operating review should follow supported reach, activation, accepted outcomes, route mix, fallback, complete cost, revenue, retention, incidents and integration spend. Quarterly investment review should reconcile realised cash and synergies to the approved case. Changes in hardware, operating systems, models, regulation or platform terms should trigger a refreshed view.

The board pack should preserve the relationship among technical, customer and financial evidence. A hardware-reach schedule should reconcile the opening and closing supported estate, additions, removals, software changes and inactive devices. The product schedule should reconcile activated users, task attempts, accepted outcomes, failures, fallbacks and customer support. The commercial schedule should reconcile entitlements, realised price, recognised revenue, invoicing and cash. The cost schedule should reconcile device execution, cloud execution, engineering, testing, security, platform, support and incident costs. This common data model prevents separate teams from presenting incompatible success measures.

Thresholds require explicit approval. Management can define minimum quality, maximum latency, privacy restrictions, energy or battery limits, support cost, fallback rate and contribution for each task class. The router applies those policies in production. Exceptions should identify the approving owner and the period of validity. A high-value regulated workflow can justify a different cost and control envelope from a low-value consumer feature. The investment case should reflect the actual mix rather than one portfolio average.

Evidence quality should affect confidence and capital release. Directly reproduced contract-to-cash and device-to-outcome records support the base case. Samples, management estimates and incomplete cohorts belong in a probability-weighted or downside case. A signed customer contract does not establish economic reach when the customer's deployed hardware cannot run the product. A successful laboratory demonstration does not establish retained contribution when production support and fallback are unknown. The decision memorandum should state these boundaries plainly.

The financing plan should match the risk. Stable recurring contracts with verified contribution may support acquisition debt or recurring-revenue facilities, subject to lender requirements. Volatile usage, concentrated platforms, rapid hardware change or material remediation can require more equity, delayed consideration or milestone funding. Debt capacity should use downside cash after integration and support costs. Covenants can monitor liquidity, customer concentration, supported estate, contribution or other agreed measures where definitions are auditable.

Exit planning begins at entry. A future strategic buyer may value the same technology differently because its distribution, hardware, data and platform position differ. A financial buyer will require an executable stand-alone case and management depth. Public-market investors may focus on recurring revenue, margin policy, concentration, security and capitalised development. The current acquisition model should therefore preserve separable evidence for stand-alone performance and each realised synergy. That record reduces dependence on a narrative at exit.

The board should also specify conditions for changing course. A platform restriction, critical vulnerability, unexpected regulation, adverse customer response or persistent quality regression can require route redesign, pricing change, narrower hardware support, additional capital or product withdrawal. Pre-agreed triggers accelerate action. They also prevent sunk acquisition cost from overriding current evidence.

An independent review can test whether the model remains reproducible. The reviewer selects cohorts, repeats reach and outcome calculations, traces costs and challenges synergy ownership. Findings feed the risk register and valuation. The review is especially useful before a major deferred payment, refinancing, impairment test or expansion into a new hardware family or regulated market.

Conclusion

On-device AI can create transaction value through privacy, responsiveness, offline resilience, distribution and reduced dependence on public-cloud inference. Those benefits become investable when the buyer can demonstrate supported hardware reach, accepted customer outcomes, clear rights and retained contribution after complete device and control costs.

The decisive unit is the paying accepted outcome delivered across a supported estate. Installed devices, model parameters and inference counts are supporting measures. A disciplined transaction process classifies workloads, verifies the route, reconstructs complete economics, tests rights and platform dependencies, separates stand-alone value from buyer synergies, and funds the operating plan.

Hybrid architecture is often a portfolio of routes rather than a binary design. The buyer therefore underwrites a control system: which tasks run where, under what privacy and quality constraints, at what complete cost, and with what fallback. That system should remain measurable as hardware, models and customer expectations change.

Sources

1. Apple, Core ML, Read the primary source
2. Google, Google AI Edge, Read the primary source
3. MLCommons, Mobile Working Group, Read the primary source
4. Apple, Core ML Models, Read the primary source
5. Google, Gemma on Mobile and Web, Read the primary source
6. Apple, Core AI, Read the primary source
7. Apple, Foundation Models Framework, Read the primary source
8. Apple, Private Cloud Compute Security Guide, Read the primary source
9. Apple, Privacy, Read the primary source
10. Google, LiteRT, Read the primary source
11. Google, Google AI Edge Gallery, Read the primary source
12. Google, Gemini Nano, Read the primary source
13. Google, Built-in AI APIs in Chrome, Read the primary source
14. Qualcomm, The On-Device AI Opportunity, Read the primary source
15. Qualcomm, The Future of AI Is Hybrid, Read the primary source
16. Qualcomm, Enabling On-Device Generative AI, Read the primary source
17. Qualcomm, AI Hub, Read the primary source
18. Qualcomm, Annual Reports, Read the primary source
19. Arm Holdings, Annual Reports, Read the primary source
20. Arm, Artificial Intelligence, Read the primary source
21. Intel, OpenVINO Toolkit, Read the primary source
22. Microsoft, ONNX Runtime Mobile, Read the primary source
23. NVIDIA, Jetson Documentation, Read the primary source
24. MLCommons, MLPerf Inference, Read the primary source
25. MLCommons, MLPerf Inference Policies and Results, Read the primary source
26. International Energy Agency, Energy and AI, Read the primary source
27. Organisation for Economic Co-operation and Development, Measuring the Environmental Impacts of AI Compute and Applications, Read the primary source
28. National Institute of Standards and Technology, Privacy Framework, Read the primary source
29. National Institute of Standards and Technology, Cybersecurity Framework 2.0, Read the primary source
30. National Institute of Standards and Technology, AI Risk Management Framework, Read the primary source
31. National Institute of Standards and Technology, Generative AI Profile, Read the primary source
32. National Institute of Standards and Technology, Adversarial Machine Learning Taxonomy and Terminology, Read the primary source
33. National Institute of Standards and Technology, Secure Software Development Framework, Read the primary source
34. European Commission, AI Act, Read the primary source
35. European Union, General Data Protection Regulation, Read the primary source
36. United States Department of Justice and Federal Trade Commission, Merger Guidelines, Read the primary source
37. European Commission, Merger Control, Read the primary source
38. United Kingdom Competition and Markets Authority, Merger Assessment Guidelines, Read the primary source
39. United States Federal Trade Commission, Premerger Notification Program, Read the primary source
40. IFRS Foundation, IFRS 3 Business Combinations, Read the primary source
41. IFRS Foundation, IFRS 13 Fair Value Measurement, Read the primary source
42. IFRS Foundation, IAS 36 Impairment of Assets, Read the primary source
43. IFRS Foundation, IAS 38 Intangible Assets, Read the primary source
44. IFRS Foundation, IFRS 15 Revenue from Contracts with Customers, Read the primary source
45. International Valuation Standards Council, International Valuation Standards, Read the primary source
46. Apple, Annual Reports, Read the primary source
47. Alphabet, Annual Reports, Read the primary source
48. Qualcomm, SEC Filings, Read the primary source
49. Arm Holdings, SEC Filings, Read the primary source
50. International Organization for Standardization, ISO/IEC 27001 Information Security Management Systems, Read the primary source