Digital Products, AI and Emerging Innovation

Introduction

Digital products are products whose value is created, delivered, or enhanced through software, data, connectivity, and digital interaction. They include mobile applications, cloud platforms, application programming interfaces (APIs), connected devices, data services, workflow automation, and artificial-intelligence (AI) systems. Unlike many physical products, digital products can be updated after release, replicated at very low marginal cost, instrumented continuously, and integrated with other products through technical interfaces.

These characteristics create significant opportunities for product managers. A digital product manager must understand not only customer problems and market positioning, but also cloud architecture, data quality, cybersecurity, platform dependence, AI limitations, and responsible innovation. Product decisions increasingly involve questions such as:

• Should a capability be built internally, purchased from a vendor, or accessed through an API?
• What data is required, and is its use lawful and ethical?
• How should a product be designed for reliability, scale, security, and interoperability?
• When does generative AI improve customer or employee outcomes, and when does it introduce unacceptable risk?
• How should a team evaluate an innovation whose benefits are uncertain but whose consequences may be substantial?

This chapter develops a practical framework for answering these questions.

Learning Objectives

By the end of this chapter, you should be able to:

1. Distinguish digital products, platforms, APIs, cloud services, IoT systems, automation, and data products.
2. Evaluate digital-product architecture, economics, reliability, and cybersecurity requirements.
3. Apply build-versus-buy and platform-selection criteria.
4. Explain how data and generative AI support product discovery and development.
5. Recognise model limitations, governance requirements, and ethical risks.
6. Analyse an AI-enabled product opportunity and recommend an appropriate implementation approach.
7. Identify emerging product-management practices and innovation implications.

1. The Nature of Digital Products

A digital product is more than a screen or software feature. It is a system of value exchanges involving users, interfaces, data, algorithms, infrastructure, operational processes, and governance. A banking application, for example, depends on identity services, payment networks, databases, fraud models, customer-support processes, regulatory controls, and cloud infrastructure.

Four properties distinguish digital products from many traditional products:

Replicability. Once software exists, additional copies can often be delivered at very low marginal cost. However, infrastructure, customer support, compliance, and data-processing costs may still increase with usage.

Updatability. Digital products can be improved through releases, configuration changes, and model updates. This creates learning opportunities but also creates risks such as regressions, unstable behaviour, and customer confusion.

Measurability. Events such as activation, search, conversion, errors, and retention can be recorded. Measurement is useful only when instrumentation is accurate, lawful, and interpreted within context.

Composability. Digital capabilities can be combined through APIs, software-development kits, identity protocols, event streams, and cloud services. Composability accelerates innovation but increases dependency and integration complexity.

A product manager should therefore define the product boundary explicitly. A feature may be technically small but operationally large. For example, adding identity verification may require a vendor, personal-data processing, fraud monitoring, accessibility testing, service-level commitments, and incident-response procedures.

2. Digital Product Architecture

A useful conceptual architecture contains several interacting layers:

1. Experience layer: web interfaces, mobile applications, conversational interfaces, dashboards, and device controls.
2. Application layer: business rules, workflows, orchestration, and domain services.
3. Data and intelligence layer: databases, data warehouses, event streams, analytics, machine-learning models, and knowledge stores.
4. Integration layer: APIs, message queues, webhooks, identity services, and external providers.
5. Infrastructure layer: computing, storage, networking, monitoring, backup, and deployment systems.
6. Governance layer: security, privacy, compliance, quality, ownership, accessibility, and operational accountability.

These layers are not strictly independent. A change in one layer can affect the others. For example, introducing a generative-AI assistant changes the experience layer, requires model and retrieval services in the intelligence layer, increases data-governance requirements, and creates new security threats such as prompt injection.

Platforms

A platform enables multiple groups to create, exchange, or consume value through shared capabilities. Examples include payment platforms, cloud platforms, app stores, logistics platforms, and developer platforms. A platform may serve two or more participant groups, such as buyers and sellers, or developers and end users.

Platform evaluation should address:

• participant value and network effects;
• technical openness and integration quality;
• governance and access rules;
• data portability and ownership;
• pricing and transaction economics;
• reliability and geographic coverage;
• switching costs and concentration risk.

Network effects occur when the value to one participant changes as participation changes. Direct network effects arise among users of the same service, while indirect network effects connect different participant groups. Network effects are not automatically beneficial: poor governance, fraud, congestion, or low-quality participants can produce negative effects.

APIs

An API is a defined mechanism through which one software system requests data or functionality from another. A good product manager considers the API as a product with users, documentation, versioning, authentication, usage limits, monitoring, and support.

Important API characteristics include:

• Contract: inputs, outputs, errors, and behaviour.
• Authentication and authorisation: who may call the API and what they may do.
• Reliability: expected availability, response time, and recovery behaviour.
• Idempotency: whether repeating a request produces the same intended result. This is particularly important for payments and order creation.
• Versioning: how changes occur without unexpectedly breaking consumers.
• Rate limits: controls that protect capacity and prevent abuse.
• Observability: logs, traces, metrics, and correlation identifiers.

An API that works in a demonstration but lacks versioning, documentation, and failure handling is not production-ready.

Cloud services

Cloud computing provides on-demand access to computing resources. Common service models include:

Cloud benefits include elasticity, rapid provisioning, managed operations, and global distribution. Risks include unexpected consumption costs, provider outages, vendor lock-in, data-residency constraints, and insufficient architectural understanding. Cloud adoption is not itself a strategy; the service must improve customer value or organisational capability.

A basic availability measure is:

Uptime and downtime must use the same unit, such as minutes, and the measurement period and exclusions must be defined. For example, 43,190 minutes of uptime and 50 minutes of downtime in a 30-day period give approximately 99.88% availability. Availability does not measure correctness, security, or usefulness: a system can be available but return inaccurate results.

3. IoT, Automation, and Data Products

Internet of Things

The Internet of Things (IoT) connects physical objects containing sensors, actuators, processors, and communication capabilities. An IoT product typically includes:

1. a physical device and power source;
2. embedded software or firmware;
3. connectivity and device identity;
4. a cloud or edge-processing service;
5. user interfaces and operational workflows;
6. security, maintenance, and lifecycle management.

IoT product design must account for intermittent connectivity, battery limits, physical tampering, firmware updates, device replacement, environmental conditions, and safety. The product manager should ask what happens when the device is offline, sends incorrect data, or cannot receive a security patch.

Automation

Automation uses software or machines to execute actions with reduced human intervention. It ranges from deterministic workflow rules to robotic process automation and AI-assisted decisions. Automation is appropriate when the process is sufficiently understood, inputs are available, exceptions can be handled, and the cost and risk of errors are acceptable.

A useful distinction is:

• Automation: the system performs the task.
• Augmentation: the system supports a human who performs the task.
• Assistance: the system provides information or recommendations without controlling the decision.

High-impact decisions often require human review, appeal mechanisms, auditability, and clear responsibility. Automating a bad process may increase speed without increasing value.

Data products

A data product delivers value primarily through data, analysis, prediction, or insight. Examples include credit-risk indicators, demand forecasts, location intelligence, benchmark reports, fraud alerts, and recommendation services.

A data product requires more than a dataset. It needs a defined user, decision context, data contract, quality controls, delivery mechanism, interpretation guidance, and feedback process. Important quality dimensions include accuracy, completeness, consistency, timeliness, uniqueness, relevance, and lineage.

For a classification model, two commonly used measures are precision and recall:

Precision measures how many positive predictions were correct. Recall measures how many actual positive cases were detected. These measures apply when the outcome categories and decision threshold are defined. They can move in opposite directions as the threshold changes, so a product team must choose a balance appropriate to the consequences of errors. For example, a safety-monitoring system may prioritise recall, whereas an expensive manual-review process may prioritise precision.

Data products also create privacy risks. Data that is technically available may not be ethically or legally appropriate to reuse. Purpose limitation, data minimisation, retention controls, access management, and transparent communication are product requirements, not merely legal paperwork.

4. Build, Buy, Partner, or Compose?

The build-versus-buy decision is usually a portfolio decision rather than a binary technical choice. Alternatives include building internally, purchasing software, consuming an API, using an open-source component, partnering with a specialist, or combining these approaches.

A structured evaluation should estimate total cost of ownership, including discovery, implementation, integration, migration, licences, usage, security review, support, training, monitoring, upgrades, and exit. A simple comparative model is:

Here, TCO is total cost of ownership over the selected period; C_initial is initial acquisition or development cost; C_integration is integration cost; C_fixed is recurring fixed cost per time unit; t is the number of time units; C_variable is variable cost per usage unit; V is usage volume; and C_exit is expected migration or termination cost. The terms must use compatible currencies and time periods. This is a planning model, not a prediction of all strategic value.

The decision should also consider capability criticality. A generic email service is often suitable for purchase. A core pricing algorithm or distinctive customer experience may justify internal development. A hybrid approach is common: purchase commodity infrastructure while building differentiated workflows, domain data, and customer experience.

5. AI in Product Discovery and Development

AI can support nearly every stage of the product lifecycle, but it does not remove the need for product judgement.

Discovery

AI tools can summarise interviews, cluster feedback, identify recurring themes, translate research materials, generate interview prompts, and analyse support tickets. These uses can increase researcher capacity, but automated summaries may omit minority perspectives, misinterpret tone, or reproduce bias in the source material. Original evidence should remain accessible, and important interpretations should be checked by a researcher.

AI-generated research participants or synthetic data may help test early concepts, but they are not substitutes for real customers. Synthetic outputs can make an idea appear more validated than it is.

Definition and prioritisation

AI can help compare opportunities, draft problem statements, map dependencies, and estimate likely outcomes from historical data. However, prioritisation involves strategic choices and values. Historical data may reflect previous bias, unavailable opportunities, or a different market context. A model should inform prioritisation, not silently determine it.

Design and development

Generative AI can produce interface alternatives, user-story drafts, test cases, code suggestions, documentation, and prototypes. Its value is greatest when a qualified professional reviews the output. Generated code may contain security weaknesses, licensing uncertainty, inefficient design, or incorrect assumptions about the existing system.

Operations and learning

AI can detect anomalies, forecast demand, support agents, personalise content, and identify likely causes of failures. Production use requires monitoring for data drift, performance decline, cost changes, unfair outcomes, and unexpected behaviour.

6. Generative AI: Capabilities and Limitations

Generative AI systems produce text, images, audio, code, or other content in response to inputs. Large language models generate sequences based on learned statistical patterns. They can produce fluent answers without possessing human-like understanding, verified knowledge, intentions, or reliable reasoning.

Common limitations include:

• Hallucination: confident but unsupported or false content.
• Knowledge limitations: incomplete, outdated, or inaccessible information.
• Prompt sensitivity: different wording can produce materially different results.
• Bias: patterns in training and feedback data can reproduce stereotypes or unequal treatment.
• Context limitations: long or complex inputs may be overlooked or misinterpreted.
• Confidentiality risk: sensitive information may be exposed through inappropriate input, logging, or supplier practices.
• Security risk: prompt injection, data exfiltration, malicious content, and unsafe tool use.
• Non-determinism: repeated requests may produce different outputs.
• Attribution and intellectual-property uncertainty: outputs may raise questions about sources, rights, and originality.

A product team should define the model's role. It may be a drafting assistant, retrieval interface, classifier, recommendation engine, or autonomous tool user. The greater the system's authority to act, the stronger the controls required.

A practical AI quality framework evaluates five dimensions:

1. Task performance: Is the output useful for the intended task?
2. Factuality: Can important claims be checked against reliable sources?
3. Safety and fairness: Could outputs cause harm or discriminate?
4. Privacy and security: Are data and tools protected?
5. Operational viability: Are latency, cost, reliability, and monitoring acceptable?

Retrieval-augmented generation can improve factual grounding by retrieving approved documents and providing them as context to a generative model. It does not guarantee correctness: retrieval may be incomplete, documents may be wrong, and the model may still misinterpret them. Citations, source controls, access permissions, and human escalation remain important.

7. Cybersecurity and Trustworthy Digital Products

Security is a product quality attribute. It affects customer trust, legal exposure, operational continuity, and brand value. Product teams should adopt security by design rather than treating security as a final inspection.

Core practices include:

• threat modelling during discovery and design;
• least-privilege access;
• strong identity and secrets management;
• encryption in transit and at rest where appropriate;
• secure coding and dependency management;
• input validation and output encoding;
• logging, monitoring, and alerting;
• vulnerability testing and patch management;
• backups and recovery exercises;
• incident-response planning;
• supplier and API risk assessment;
• privacy impact assessment for sensitive data.

The principle of least privilege means that a person or service receives only the access necessary for its legitimate task. This limits damage if an account or component is compromised.

AI systems require additional controls. Prompts and retrieved documents should be treated as untrusted inputs. Tools should have narrowly defined permissions, confirmation should be required before high-impact actions, and outputs should be filtered or reviewed where appropriate. Evaluation should include adversarial testing, not only normal user testing.

Governance should assign named owners for data, models, security, customer harm, and operational response. Applicable privacy, consumer-protection, intellectual-property, accessibility, sectoral, and AI regulations must be assessed in the relevant jurisdiction. Compliance requirements vary by location and use case; legal review should therefore be integrated early rather than added after launch.

8. Product Metrics and Experimentation

Digital products permit continuous measurement, but more data does not automatically produce better decisions. A metric should be connected to a user or business outcome and interpreted with qualitative evidence.

Useful categories include:

• acquisition and activation;
• engagement and task success;
• retention and churn;
• conversion and revenue;
• reliability and latency;
• cost to serve;
• customer satisfaction and complaint rates;
• safety, fairness, privacy, and security indicators.

Teams should distinguish input metrics, such as the number of experiments, from outcome metrics, such as successful task completion or retained customers. They should also monitor guardrail metrics. An AI support assistant might increase speed while reducing resolution quality or increasing unfair refusals.

Experiments need a clear hypothesis, target population, treatment, comparison, success metric, duration, and stopping rule. Product managers must consider interference between users, novelty effects, seasonality, ethical constraints, and whether randomisation is appropriate. A statistically detectable difference may still be too small to matter economically or practically.

9. Applied Case: CareLink Remote Monitoring

The following is a fictional illustrative case.

Background

CareLink is a mid-sized healthcare provider considering a connected-home monitoring service for patients with chronic respiratory conditions. A device records selected measurements and transmits them to a clinical dashboard. The proposed product includes an AI system that flags patients who may need follow-up.

Problem

The provider currently relies on scheduled appointments and manual review of incoming information. It wants earlier identification of deterioration, but it has limited engineering capacity and cannot tolerate unsafe recommendations or disclosure of health information.

Analysis

The product manager maps the system into device, connectivity, cloud storage, clinical workflow, patient application, and AI-alert components. Key risks include inaccurate sensors, lost connectivity, false alarms, missed deterioration, unauthorised access, unclear clinical responsibility, and alert fatigue.

The team compares three options:

1. build all components internally;
2. buy a regulated monitoring platform and build the clinical workflow;
3. purchase devices and cloud services while developing the alert model internally.

Option 2 offers the fastest route and transfers some infrastructure responsibility, but it creates supplier dependence and may limit workflow differentiation. Option 3 gives more control over the model but increases validation and maintenance requirements. The team recommends a staged hybrid approach.

Approach and solution

The first release uses commercially supported devices and a managed secure data service. The AI component initially assists trained clinicians by ranking alerts rather than contacting patients autonomously. Each alert displays the relevant measurements, timestamp, data quality indicators, and an explanation of why it was prioritised. Clinicians can accept, dismiss, or escalate an alert, and these decisions are recorded for evaluation.

The pilot includes:

• informed patient consent and clear data-use communication;
• role-based access and audit logs;
• offline-device warnings;
• manual escalation procedures;
• human review of all alerts;
• monitoring of precision, recall, response time, and patient outcomes;
• a rollback plan if performance or safety deteriorates.

The model is evaluated separately for relevant patient groups to identify unequal performance. Product success is not defined merely as the number of alerts. It includes clinically appropriate interventions, reduced avoidable admissions, manageable workload, patient trust, and absence of preventable harm.

Outcome

The pilot demonstrates that the technology can prioritise cases, but also reveals that missing data is common among patients with poor connectivity. The provider delays autonomous recommendations and improves device-support processes. The product proceeds to a larger controlled evaluation only after clinical governance approval.

Learning points

The case illustrates that AI value depends on workflow integration, data quality, human responsibility, and measurable outcomes. A technically impressive model is not sufficient. The safest first release may be an assistive system with constrained authority, transparent evidence, and a deliberate learning process.

10. Emerging Product Practices

Several practices are becoming increasingly important:

Product-led growth. Products use onboarding, self-service value, collaboration, and usage data to support adoption. This approach must not encourage manipulative design or obscure pricing.

Composable product development. Teams assemble capabilities from APIs, cloud services, open-source components, and internal platforms. Architecture governance and dependency mapping become essential.

Continuous discovery and delivery. Teams combine frequent customer learning with incremental development and controlled release. Speed must be balanced with accessibility, reliability, security, and compliance.

Responsible and sustainable innovation. Product decisions increasingly consider energy use, electronic waste, model-computation costs, inclusion, labour effects, and long-term social consequences.

Human-in-the-loop operations. People review, approve, correct, or appeal automated outputs. The human role must be meaningful; merely placing a person beside an automation does not guarantee oversight.

Digital twins and edge intelligence. Physical systems can be represented digitally for monitoring, simulation, and optimisation. Processing at the edge can reduce latency and connectivity dependence, but it increases device-management complexity.

Outcome-oriented product operating models. Organisations are moving from project completion measures toward durable outcomes such as customer success, adoption, retention, safety, and financial sustainability. This requires stable teams, clear accountability, and learning across product, engineering, design, data, security, and operations.

Best-Practice Checklist

Before launching a digital or AI-enabled capability, the product team should be able to answer:

1. What customer or organisational problem is being solved?
2. What evidence supports the problem and proposed outcome?
3. Which parts are strategically differentiating?
4. What should be built, bought, partnered, or composed?
5. What data is needed, who owns it, and is its use justified?
6. What happens when the service, device, API, or model fails?
7. How are security, privacy, accessibility, and regulatory duties addressed?
8. What errors are possible, and who bears their consequences?
9. Which human decisions remain necessary?
10. What metrics, guardrails, experiments, and rollback mechanisms will be used?
11. How will supplier dependence and exit be managed?
12. What evidence would justify scaling, changing, or stopping the product?

Challenges and Limitations

Digital innovation can create concentration around large cloud and AI providers, making switching difficult and reducing organisational resilience. Rapid releases may outpace governance. Data-driven systems can reproduce historical discrimination while appearing objective. Personalisation can become surveillance, automation can displace or deskill workers, and persuasive interfaces can undermine user autonomy.

Measurement is also imperfect. Engagement may reward excessive use rather than meaningful value; model accuracy may not equal clinical or commercial usefulness; and short-term conversion may damage long-term trust. Finally, technical possibility does not establish social desirability. Product managers must combine experimentation with professional ethics, stakeholder participation, legal advice, and accountable leadership.

Chapter Summary

Digital products combine software, data, infrastructure, interfaces, integrations, and governance. Platforms create shared value among participant groups, APIs enable composability, cloud services provide scalable capabilities, IoT links physical devices to digital systems, automation changes the allocation of human work, and data products convert information into decisions or insight.

Build-versus-buy choices should consider strategic differentiation, speed, total cost of ownership, control, expertise, security, supplier dependence, and exit options. AI can strengthen discovery, design, development, and operations, but generative AI remains vulnerable to hallucination, bias, prompt sensitivity, privacy failures, security attacks, and operational instability. Human judgement and governance remain essential.

Trustworthy digital products incorporate security, privacy, accessibility, reliability, monitoring, explainability where appropriate, and mechanisms for correction and appeal. Product teams should evaluate outcomes and guardrails rather than relying on activity metrics alone. Emerging practice favours composable architectures, continuous discovery, human-in-the-loop systems, responsible innovation, and outcome-oriented product management.

Key Terms

Digital product: A product whose value is created or delivered substantially through software, data, connectivity, or digital interaction.

Platform: A system that enables multiple participant groups to create, exchange, or consume value.

API: A defined interface through which software systems request data or functionality.

Cloud computing: On-demand access to computing, storage, networking, or managed digital services.

IoT: A network of connected physical objects with sensing, processing, communication, or actuation capabilities.

Automation: Execution of a task or process with reduced human intervention.

Augmentation: Technology support that improves human performance while leaving decision authority with a person.

Data product: A product that delivers value through data, analysis, prediction, or insight.

Generative AI: AI that produces new content such as text, images, audio, or code.

Hallucination: An AI output that is presented as credible but is unsupported or false.

Retrieval-augmented generation: A method that supplies retrieved information to a generative model to improve grounding.

Model drift: Decline in model performance because data, behaviour, or conditions change over time.

Precision: The proportion of positive predictions that are true positives.

Recall: The proportion of actual positive cases that are detected.

Least privilege: Providing only the access required for a legitimate task.

Threat modelling: Structured identification and evaluation of potential security threats.

Total cost of ownership: The full cost of acquiring, operating, maintaining, and exiting a capability over a defined period.

Human-in-the-loop: A design in which people review, control, correct, or approve automated outputs.

Guardrail metric: A measure used to detect harmful or unacceptable effects while pursuing a primary outcome.

Review Questions

Short Answer Questions

1. What characteristics distinguish digital products from many traditional products?
2. What is the purpose of API versioning?
3. Define a data product and give one example.
4. State two limitations of generative AI.
5. What does the principle of least privilege mean?

Long Answer Questions

1. Explain how platforms, APIs, and cloud services contribute to digital-product development. Include the principal risks of dependence on external providers.
2. Discuss the build-versus-buy decision using strategic differentiation, total cost of ownership, speed, control, and exit risk.
3. Explain how AI can support product discovery and development while preserving the role of professional judgement.
4. Describe a security-by-design approach for an AI-enabled digital product.
5. Evaluate the importance of data quality, workflow integration, and governance in the success of an IoT data product.

Analytical / Application Questions

1. A retailer wants to use a generative-AI assistant to answer customer questions and issue refunds. Recommend an initial operating model, identifying suitable automation boundaries, human controls, metrics, and major risks.
2. A start-up can build a recommendation engine for $180,000 initially and $25,000 per month, or use an API costing $0.04 per recommendation. It expects 1,000,000 recommendations per month for 24 months. Ignoring strategic benefits and taxes, compare the direct costs and explain what other factors should affect the decision.
3. An IoT manufacturer discovers that its predictive-maintenance model has high precision but low recall. Analyse the business implications and recommend how the team should evaluate thresholds, costs of errors, data quality, and human escalation before launch.

Multiple Choice Questions with Answers

Question 1

Which statement best describes an API?

A. A physical sensor that measures environmental conditions

B. A defined interface through which software systems request data or functionality

C. A legal contract that transfers ownership of a cloud provider

D. A statistical measure of customer retention

Correct Answer: B. A defined interface through which software systems request data or functionality

Question 2

Which factor most directly supports a build decision for a product capability?

A. The capability is strategically distinctive and requires strong control

B. The capability is a common commodity available from many reliable suppliers

C. The organisation has no relevant technical expertise

D. The supplier offers a documented and reversible exit plan

Correct Answer: A. The capability is strategically distinctive and requires strong control

Question 3

A classifier identifies 80 true positives and 20 false positives. What is its precision?

A. 20%

B. 50%

C. 80%

D. 100%

Correct Answer: C. 80%

Question 4

Which is a recognised limitation of generative AI?

A. It always produces identical results for the same prompt

B. It cannot produce text or code

C. It may generate fluent but unsupported information

D. It eliminates the need for data governance

Correct Answer: C. It may generate fluent but unsupported information

Question 5

What is the primary purpose of a guardrail metric?

A. To replace all outcome metrics

B. To detect harmful or unacceptable effects while pursuing a main outcome

C. To measure the number of software developers on a team

D. To calculate cloud storage capacity only

Correct Answer: B. To detect harmful or unacceptable effects while pursuing a main outcome

Question 6

Which practice best reflects least privilege?

A. Giving every service administrator access to all production data

B. Allowing a service only the permissions required for its defined task

C. Sharing one administrative account across a team

D. Disabling audit logs to improve performance

Correct Answer: B. Allowing a service only the permissions required for its defined task

Question 7

Why is human review especially important when an AI system makes high-impact recommendations?

A. AI systems never process data quickly

B. Human review can support accountability, correction, and escalation

C. Human review guarantees that every prediction is correct

D. AI systems cannot be integrated into workflows

Correct Answer: B. Human review can support accountability, correction, and escalation

Question 8

Which issue is particularly relevant to IoT products?

A. Device connectivity, firmware updates, and physical tampering

B. Only the colour of a web-page button

C. The impossibility of collecting any operational data

D. The absence of lifecycle considerations

Correct Answer: A. Device connectivity, firmware updates, and physical tampering

Question 9

A system has 43,190 minutes of uptime and 50 minutes of downtime. Which formula should be used to calculate availability?

A. Downtime ÷ Uptime

B. Uptime ÷ (Uptime + Downtime)

C. Uptime × Downtime

D. (Uptime − Downtime) ÷ Downtime

Correct Answer: B. Uptime ÷ (Uptime + Downtime)

Question 10

What is a central purpose of retrieval-augmented generation?

A. To provide a generative model with retrieved information for better grounding

B. To remove the need for source permissions

C. To guarantee that every generated statement is true

D. To prevent all changes in model output

Correct Answer: A. To provide a generative model with retrieved information for better grounding