Visualization Engineering and Reproducible Workflows

Introduction

Modern data visualization is not limited to selecting a chart type and applying an attractive colour palette. In professional and research environments, a visualization is the visible product of a larger engineering system. That system includes data acquisition, storage, transformation, statistical analysis, visual encoding, software dependencies, testing, documentation, deployment, and governance.

Visualization engineering is the disciplined design and implementation of that system. Its purpose is to ensure that visual outputs are accurate, interpretable, maintainable, scalable, secure, and reproducible. Reproducibility means that another analyst—or the original analyst at a later date—can regenerate the same result from identified inputs, code, configurations, and software environments. Reproducibility is therefore stronger than merely saving an image or exporting a dashboard.

This chapter examines workflows that combine Python, R, SQL, business-intelligence platforms, and web technologies. It also considers version control, data and software pipelines, testing, documentation, deployment, ethical governance, and contemporary developments such as automated visual analytics and AI-assisted coding.

Learning Objectives

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

1. Explain visualization engineering as an end-to-end technical and analytical discipline.

2. Design a reproducible workflow from source data to published visualization.

3. Select appropriately among Python, R, SQL, BI platforms, and web technologies.

4. Apply data validation, software testing, version control, and environment management.

5. Evaluate dashboards using analytical, usability, performance, and governance criteria.

6. Design a scalable architecture for interactive and organizational reporting.

7. Critically assess ethical, privacy, accessibility, and AI-related risks.

1. From Chart Production to Visualization Engineering

A conventional chart-making process often follows this pattern: obtain a spreadsheet, manipulate it manually, create a chart, and distribute an image. This approach can be adequate for a one-time exploratory task, but it becomes unreliable when data changes regularly, multiple people collaborate, or decisions depend on the result.

Visualization engineering treats the visualization as a software product. A typical system contains the following layers:

• Source layer: operational databases, APIs, files, sensors, surveys, or event streams.
• Integration layer: extraction, loading, schema mapping, deduplication, and data-quality checks.
• Transformation layer: cleaning, joining, aggregation, feature derivation, and semantic modelling.
• Analytical layer: descriptive statistics, forecasting, segmentation, or statistical modelling.
• Visual layer: charts, maps, tables, interaction controls, and annotations.
• Delivery layer: notebooks, reports, dashboards, web applications, or embedded components.
• Governance layer: access control, provenance, documentation, retention, privacy, and auditability.

A failure at any layer can produce a misleading visualization. For example, a technically elegant dashboard may still be wrong if the SQL query duplicates transactions after a many-to-many join. Conversely, correct data may be made practically useless by poor visual hierarchy or inaccessible colour choices.

A useful engineering principle is separation of concerns. Data extraction should not be hidden inside presentation code; business definitions should not exist only in an analyst’s memory; and visual styling should not alter the underlying measure. Separating these concerns makes systems easier to test, review, and modify.

2. Reproducibility, Repeatability, and Provenance

Several related terms must be distinguished.

• Repeatability: the same team, using the same data, methods, and environment, obtains consistent results.
• Reproducibility: an independent person can regenerate the result using sufficiently documented materials.
• Replicability: an independent study or implementation obtains substantively consistent findings, possibly with new data.
• Provenance: a record of where data came from, how it changed, and which outputs depend on it.
• Traceability: the ability to follow an output backward to transformations, inputs, and decisions.

Saving a PNG file provides an output artifact but little provenance. A reproducible visualization project normally preserves:

1. source identifiers and acquisition dates;

2. code for extraction and transformation;

3. configuration files and parameters;

4. data dictionaries and metric definitions;

5. software and package versions;

6. tests and quality results;

7. documentation of assumptions and limitations;

8. a mechanism for rebuilding the output.

Reproducibility does not require publishing confidential raw data. Sensitive data may remain in a controlled environment while the project publishes synthetic data, metadata, transformation logic, and a documented access procedure.

A reproducible project structure

A practical repository may contain:

```text

project/

├── README.md

├── pyproject.toml or renv.lock

├── requirements.txt

├── data/

│ ├── raw/ # controlled or ignored where appropriate

│ └── processed/

├── sql/

├── src/

│ ├── extract.py

│ ├── transform.py

│ └── validate.py

├── notebooks/

├── dashboards/

├── tests/

├── docs/

└── .github/workflows/

```

The exact structure may differ, but the principle is stable: a new contributor should be able to understand how the project works without relying on undocumented personal knowledge.

3. The End-to-End Visualization Pipeline

A pipeline is an ordered set of transformations that converts inputs into outputs. A robust visualization pipeline is usually designed as a directed acyclic graph: each stage has defined inputs and outputs, and circular dependencies are avoided.

3.1 Data acquisition and contracts

Data acquisition may use SQL queries, REST APIs, cloud storage, message streams, or uploaded files. At this stage, record the source, timestamp, authentication method, expected schema, and extraction status. A data contract specifies expected fields, types, permitted values, nullability, units, update frequency, and ownership.

For example, a daily sales dataset might require:

• `transaction_id`: unique, non-null identifier;
• `transaction_date`: valid date in UTC or a stated business time zone;
• `store_id`: identifier existing in the store dimension;
• `net_sales`: numeric value expressed in a stated currency;
• `status`: one of an approved set of values.

Contracts turn informal expectations into testable conditions.

3.2 Transformation and semantic modelling

Transformation includes filtering invalid records, standardizing categories, joining tables, aggregating observations, and calculating measures. A semantic layer provides shared definitions such as “active customer,” “net revenue,” or “on-time delivery.” Without semantic consistency, two dashboards may display different values while using the same label.

SQL is particularly appropriate for set-based operations close to the data. Python and R are valuable for complex analytical transformations, modelling, and visualization. A common architecture uses SQL for extraction and aggregation, then passes a compact, analysis-ready table to Python or R.

Care is required with joins. If a fact table is joined to two dimensions with repeated keys, rows may multiply and totals may be overstated. Analysts should identify grain explicitly: for example, “one row per order line” or “one row per customer per month.” Every transformation should preserve or intentionally change that grain.

3.3 Analytical and visual specification

Before implementation, define the decision or question, audience, measures, dimensions, filters, time grain, and acceptable latency. A visual specification may state:

• purpose: monitor delayed deliveries;
• audience: regional operations managers;
• primary measure: percentage of orders delivered by promised date;
• comparison: current week versus target;
• required interaction: region and date filters;
• refresh: every six hours;
• security: users may view only authorized regions.

This specification prevents feature accumulation and makes acceptance testing possible.

3.4 Rendering and delivery

Rendering may occur in a notebook, scheduled report, BI server, static web page, or interactive application. Decide whether computation is performed at build time, request time, or in the browser. Build-time computation supports fast static delivery; request-time computation enables fresh, personalized results but demands stronger performance and security controls.

4. Contemporary Toolchains

Python

Python supports data ingestion, transformation, statistical analysis, testing, and application development. Common components include pandas or Polars for tabular processing, NumPy for numerical operations, Matplotlib and Seaborn for statistical graphics, Plotly and Altair for interactive or declarative graphics, and frameworks such as Streamlit, Dash, or FastAPI for delivery.

Python is effective when a project requires integration with machine learning, APIs, automated tests, and general software engineering. Its risks include uncontrolled notebook state, implicit type conversions, dependency conflicts, and inefficient processing of datasets that exceed memory.

R

R has strong support for statistical computing and visualization. The tidyverse provides a coherent grammar for data manipulation and graphics; ggplot2 separates data, aesthetic mappings, geometric marks, scales, and themes. R Markdown and Quarto support reproducible analytical documents, while Shiny supports interactive applications.

R is especially useful for statistical reporting and research workflows. Package management and project isolation remain important, particularly when old analyses must be rebuilt after packages change.

SQL

SQL is essential for querying relational and analytical databases. It is efficient for filtering, grouping, joins, window functions, and database-side aggregation. SQL views or semantic models can provide a stable interface to dashboard tools.

SQL alone does not replace visual design or statistical reasoning. Analysts must also consider query plans, indexes, partitioning, row-level permissions, null semantics, and the risk of accidentally changing grain.

Business-intelligence platforms

BI platforms provide governed data models, drag-and-drop authoring, calculated measures, row-level security, scheduled refresh, alerts, and collaboration. They are valuable for organizational adoption because business users can explore approved data without writing code.

Their limitations include vendor dependence, opaque generated queries, licensing costs, restricted customization, and the danger of allowing many inconsistent calculations. A governed semantic model and controlled promotion process are therefore more important than the visual interface alone.

Web technologies

Web visualization commonly uses HTML, CSS, JavaScript, SVG, Canvas, and libraries such as D3. SVG is convenient for inspectable vector elements and moderate numbers of marks; Canvas is often more suitable for very large numbers of marks, though it provides less direct element-level accessibility. Frameworks such as React or Vue can organize complex interfaces, while server-side technologies provide data access and authentication.

Web systems require attention to responsive layout, browser performance, accessibility, security, caching, and cross-origin policies. Interactive freedom should not be confused with analytical quality.

5. Designing for Scale and Performance

Scalability has several meanings:

• Data scalability: handling larger tables or higher event volumes.
• User scalability: serving more simultaneous users.
• Authoring scalability: allowing teams to maintain many reports consistently.
• Organizational scalability: preserving definitions, security, and governance across departments.

Important strategies include:

1. Reduce data early. Filter columns and rows before transfer where possible.

2. Aggregate to the visual grain. A monthly trend does not usually require sending every transaction to the browser.

3. Use incremental processing. Process only new or changed records when the source supports reliable change detection.

4. Cache stable results. Cache keys must include relevant filters, user permissions, and data version.

5. Use appropriate storage. Columnar formats and analytical engines are often efficient for scan-heavy workloads.

6. Measure performance. Record query time, data-transfer size, rendering time, and interaction latency.

7. Use progressive disclosure. Show summaries first and details on demand.

A useful approximation for a browser visualization is:

\[

T_{total} \approx T_{query}+T_{transfer}+T_{parse}+T_{render}

\]

where the terms represent query execution, network transfer, client parsing, and rendering time. This is an engineering model rather than an exact physical law; it assumes these stages can be treated as approximately sequential. If operations overlap, the actual total may be lower than the sum. The equation is useful because it identifies different optimization targets: indexes can reduce query time, compression can reduce transfer time, efficient formats can reduce parsing time, and aggregation can reduce rendering time.

6. Version Control and Environment Management

Git records changes to code, configuration, documentation, and selected metadata. Good practice includes small logical commits, descriptive messages, code review, protected main branches, and tagged releases. Large raw data files should not ordinarily be committed directly to a repository; use controlled storage or data-versioning systems where appropriate.

A visualization release should identify:

• code commit or release tag;
• data snapshot or extraction timestamp;
• package and runtime versions;
• configuration parameters;
• model or metric version;
• publication date and owner.

Environment management prevents “works on my machine” failures. Python projects may use virtual environments, lock files, and tools such as Poetry or uv; R projects may use renv; containers can package system libraries and runtime dependencies. Containers improve consistency but do not automatically make data reproducible: credentials, external APIs, time-dependent data, and undocumented configuration remain potential sources of variation.

Randomized analysis requires explicit random seeds when deterministic regeneration is needed. However, a seed does not guarantee identical results across software versions, hardware, parallel execution, or algorithms. Such limitations should be documented.

7. Testing and Quality Assurance

Testing should be layered rather than postponed until publication.

Data tests

Examples include uniqueness, non-null constraints, accepted categories, valid ranges, referential integrity, freshness, and row-count thresholds. A test that `transaction_id` is unique is meaningful only when the table’s declared grain requires uniqueness.

Transformation tests

Use small controlled fixtures whose expected outputs are known. Test edge cases such as empty inputs, missing categories, time-zone boundaries, duplicate records, negative amounts, and late-arriving data.

Visual tests

Visual regression testing compares rendered outputs against approved reference images or structural properties. Pixel-perfect comparison can be sensitive to fonts and rendering environments, so tolerance thresholds and meaningful review procedures are necessary. Structural tests may verify that a title exists, a required series is present, or a scale domain is correct.

Application and accessibility tests

Test filters, navigation, authentication, error states, keyboard operation, screen-reader labels, contrast, responsive layout, and export functions. A dashboard that calculates correctly but fails under unauthorized access is not a quality product.

Continuous integration and deployment

A continuous-integration pipeline can run formatting checks, unit tests, data-contract tests, security scans, and build steps whenever code changes. Deployment should separate development, testing, and production environments. Approval gates are appropriate for high-impact reports.

8. Documentation and Communication

Documentation should exist at three levels.

Technical documentation explains architecture, dependencies, configuration, APIs, and deployment. Analytical documentation defines measures, assumptions, exclusions, statistical methods, and known limitations. User documentation explains interpretation, filters, refresh timing, data coverage, and appropriate use.

A metric catalogue is particularly valuable. For each measure, document its name, business definition, formula or query logic, unit, grain, source, owner, refresh frequency, and exceptions. For a rate, identify the numerator and denominator and specify whether zero denominators produce a null, zero, or an excluded result. Such details prevent apparently minor implementation differences from becoming organizational disagreements.

9. Visual and Interaction Design within an Engineering Workflow

Engineering quality does not replace visual reasoning. Select encodings according to the analytical task. Position along a common scale generally supports more accurate comparison than area or colour intensity. Use line charts for temporal continuity, bars for category comparison, maps only when geographic location is analytically relevant, and tables when exact lookup is central.

Interaction should answer a purpose. Filtering reduces scope; brushing supports linked exploration; drill-down reveals detail; annotation supplies context; and tooltips provide supplementary values. Excessive interaction increases cognitive and technical complexity.

Accessibility is a design and engineering requirement. Do not rely on colour alone; provide labels, patterns, symbols, or direct annotation. Ensure adequate contrast, keyboard access, meaningful focus order, descriptive titles, and text alternatives. Colour palettes should remain interpretable for users with colour-vision deficiencies. Accessibility requirements may be imposed by institutional policy or law, and they improve usability for everyone.

10. Security, Ethics, and Governance

Visualization can expose sensitive information even when names are removed. Small cells, rare combinations, geographic precision, timestamps, and interactive filtering may enable re-identification. Governance should address data minimization, purpose limitation, retention, access control, row-level security, audit logs, and secure handling of credentials.

Analysts must distinguish missing, zero, suppressed, and not-applicable values. Suppressing uncertainty or denominators can make a dashboard appear more precise than the evidence supports. Aggregation choices may disadvantage minority groups, while rankings can encourage harmful competition or stigmatization.

Responsible practice includes documenting data limitations, communicating uncertainty, involving domain stakeholders, and testing outputs for disparate impact where relevant. Regulatory obligations vary by jurisdiction and sector, but privacy, accessibility, records management, and information-security requirements should be treated as design inputs rather than post-publication repairs.

11. AI-Assisted Visualization Engineering

AI tools can accelerate code generation, query drafting, chart recommendation, anomaly detection, natural-language interaction, and documentation. They can also introduce fabricated APIs, insecure queries, silent changes in metric definitions, biased summaries, or leakage of confidential data.

A responsible workflow treats AI output as untrusted draft material. Engineers should:

1. inspect generated code and dependencies;

2. test queries against known fixtures;

3. verify calculations independently;

4. review visual recommendations against the analytical question;

5. avoid entering protected data into unauthorized services;

6. retain human accountability for publication.

Natural-language interfaces should expose the generated query or explanation where feasible. Users need to know whether a response is based on a governed semantic model, an approximate interpretation, or an unverified generated calculation.

12. Illustrative Case: Regional Delivery Performance Dashboard

Background

The fictional company Northstar Logistics operates 60 distribution centres. Regional managers need to monitor whether customer orders are delivered by the promised date. Existing reports are manually assembled from spreadsheets and often disagree.

Problem

The organization has three major problems: definitions of “on-time” differ between reports, data arrives from multiple operational systems, and the monthly report is too slow for operational intervention. Managers also need to see only their authorized regions.

Analysis

The engineering team identifies the fact grain as one row per order. Source systems provide order creation, promised delivery, actual delivery, cancellation status, centre, and region. The team defines an on-time order as one that is delivered on or before its promised timestamp, excluding cancelled orders. Orders without a promised timestamp are reported separately rather than silently treated as late.

The governed measure is:

\[

\text{On-time rate} = \frac{N_{on-time}}{N_{eligible}}

\]

where \(N_{on-time}\) is the number of eligible orders delivered on or before the promised time, and \(N_{eligible}\) is the number of non-cancelled orders with the required timestamps. The rate is defined only when \(N_{eligible}>0\); otherwise the result is reported as not available rather than assigned an arbitrary zero.

Approach and solution

SQL extracts daily changes and creates an order-level analytical table. Data tests check unique order identifiers, valid timestamps, known centres, and freshness. A semantic model defines the measure once. A BI dashboard provides a regional summary, weekly trend, target comparison, and drill-through to operational orders. Row-level security maps each manager to permitted regions.

The dashboard is supplemented by a Python validation job that compares selected totals with independently calculated control totals. Git stores SQL, documentation, tests, and dashboard deployment metadata. A deployment pipeline promotes changes from development to testing and then production after review.

The visual design uses a line chart for weekly performance, a bullet-style comparison with the target, and a table for exception lookup. The interface includes a visible refresh timestamp, definitions, missing-data notes, accessible labels, and a warning when the denominator is small.

Outcome

The organization obtains a single governed definition, refreshes the dashboard six times per day, and reduces manual report preparation. More importantly, managers can distinguish genuine performance deterioration from missing or incomplete data. The dashboard does not claim that every late delivery is caused by a particular department; causal analysis remains a separate analytical task.

Learning points

The case demonstrates that visualization quality depends on grain, metric definitions, tests, security, and documentation as much as on chart selection. It also shows why a dashboard should expose its data coverage and limitations rather than presenting a number without context.

13. Implementation and Project Best Practices

A professional workflow can be summarized as follows:

1. Begin with a decision and audience, not a chart library.

2. Define data grain, metric semantics, units, and time zones.

3. Establish a data contract and automated quality checks.

4. Keep extraction, transformation, analysis, and presentation separable.

5. Prefer governed semantic definitions for shared measures.

6. Version code, configuration, documentation, and release metadata.

7. Pin or lock environments and record external dependencies.

8. Test both data and user-facing behavior.

9. Optimize based on measured bottlenecks rather than intuition.

10. Design for accessibility, privacy, security, and responsible interpretation.

11. Make refresh status, provenance, and limitations visible.

12. Use code review and staged deployment for consequential outputs.

13. Treat AI-generated code and explanations as drafts requiring verification.

14. Retire unused dashboards and monitor whether published products remain useful.

Challenges and Limitations

No workflow eliminates uncertainty. Source data may be incomplete, definitions may be contested, and historical extracts may be unavailable. Reproducibility can be limited by proprietary software, changing APIs, nondeterministic algorithms, or legally restricted data. Performance improvements may increase infrastructure cost or reduce interactivity. Strong governance can slow experimentation, while weak governance creates conflicting reports and security exposure.

There is also a tension between standardization and local analytical needs. Central semantic models improve consistency, but overly rigid models can prevent legitimate specialized analysis. The appropriate response is controlled extensibility: shared definitions for common measures, transparent exceptions for specialized work, and clear ownership of both.

Chapter Summary

Visualization engineering treats visual analytics as an end-to-end software and data system. Reliable outputs require controlled acquisition, explicit grain and metric definitions, tested transformations, appropriate tool selection, scalable architecture, versioned code, managed environments, documentation, and staged deployment. Python and R support analytical programming; SQL supports governed data operations; BI platforms support organizational distribution; and web technologies support customized interaction.

Reproducibility depends on provenance, environment information, configuration, tests, and rebuildable workflows—not merely on exported images. Performance should be analyzed across query, transfer, parsing, and rendering stages. Quality assurance must include data, transformations, visuals, accessibility, security, and user behavior. Ethical practice requires privacy protection, transparent limitations, accessible design, and responsible communication of uncertainty. AI can increase productivity, but generated code and explanations require independent validation. The central professional responsibility is to ensure that a visualization is not only attractive, but also correct, explainable, maintainable, secure, and fit for the decision it supports.

Key Terms

Visualization engineering: The systematic design, implementation, testing, and maintenance of visualization systems.

Reproducibility: The ability to regenerate a result from identified data, code, configuration, and environment.

Provenance: A record of the origin and transformation history of data and outputs.

Data contract: A formal specification of expected data structure, types, constraints, and ownership.

Data grain: The real-world level represented by one row in a dataset.

Semantic layer: A governed layer containing shared business entities, measures, and definitions.

Pipeline: An ordered sequence of data or computational transformations.

Idempotence: The property that repeating an operation produces the same intended result without unwanted duplication.

Version control: A system for recording and managing changes to project artifacts.

Environment management: The control and documentation of runtimes, libraries, and system dependencies.

Unit test: A test of a small, isolated function or transformation.

Data-quality test: An automated check of properties such as validity, uniqueness, freshness, or completeness.

Visual regression test: A comparison of a rendered visualization with an approved reference or expected structure.

Row-level security: Access control that restricts records according to the authenticated user.

Progressive disclosure: Presenting high-level information first and revealing detail when requested.

Data contract: A formal agreement describing the expected structure and quality of exchanged data.

Metric definition: The documented meaning, calculation, unit, grain, and limitations of a measure.

Continuous integration: Automated validation performed when project changes are submitted.

Accessibility: Designing technology so that people with diverse abilities can use and interpret it.

Data lineage: The traceable path from source data through transformations to a published output.

Review Questions

Short Answer Questions

1. Distinguish reproducibility from provenance.

2. Why must the grain of a dataset be identified before joining tables?

3. Name two responsibilities of a semantic layer.

4. What is the purpose of a data contract?

5. Why should AI-generated visualization code be independently tested?

Long Answer Questions

1. Explain the layers of an end-to-end visualization engineering system and describe how failure in one layer can affect the final visualization.

2. Compare Python, R, SQL, BI platforms, and web technologies in terms of their strengths and limitations in a professional visualization workflow.

3. Describe a comprehensive testing strategy for a production dashboard.

4. Explain how version control, environment management, documentation, and provenance work together to support reproducibility.

5. Discuss the ethical, privacy, accessibility, and governance responsibilities involved in publishing organizational dashboards.

Analytical / Application Questions

1. A dashboard’s total revenue is 18% higher than the finance system’s total after a new customer table is added. Diagnose the likely data-engineering causes and propose tests and corrective actions.

2. Design a reproducible architecture for a university student-success dashboard using SQL, Python or R, a BI platform, Git, and automated deployment. State the grain, key measures, tests, security controls, and documentation required.

3. A web dashboard loads in 11 seconds. Query execution takes 4 seconds, data transfer takes 3 seconds, parsing takes 2 seconds, and rendering takes 2 seconds. Using the engineering approximation presented in this chapter, identify two optimization strategies and explain their likely trade-offs.

Multiple Choice Questions with Answers

Question 1

Which artifact most directly supports rebuilding a visualization rather than merely viewing it?

A. A PNG export of the dashboard

B. A screenshot embedded in a presentation

C. Versioned code, data specifications, and environment information

D. A colour palette document

Correct Answer: C. Versioned code, data specifications, and environment information

Question 2

What does identifying dataset grain primarily help prevent?

A. Colour-contrast problems

B. Unintended row multiplication and incorrect aggregation

C. Browser authentication failures

D. Package installation errors

Correct Answer: B. Unintended row multiplication and incorrect aggregation

Question 3

Which tool is generally most appropriate for set-based joins and aggregation close to a relational data store?

A. SQL

B. CSS

C. SVG

D. Markdown

Correct Answer: A. SQL

Question 4

In the approximation T_total ≈ T_query + T_transfer + T_parse + T_render, what does T_transfer represent?

A. Time spent calculating a database query

B. Time spent moving data across the network

C. Time spent drawing marks in the browser

D. Time spent writing documentation

Correct Answer: B. Time spent moving data across the network

Question 5

Which is an example of a data-quality test?

A. Checking that transaction identifiers are unique

B. Changing a chart from bars to lines

C. Adding a dashboard logo

D. Selecting a darker theme

Correct Answer: A. Checking that transaction identifiers are unique

Question 6

What is the main purpose of a semantic layer?

A. To provide shared and governed definitions of business measures

B. To replace all user authentication

C. To increase monitor brightness

D. To store only image files

Correct Answer: A. To provide shared and governed definitions of business measures

Question 7

When is an on-time rate undefined in the case study’s specification?

A. When the numerator is smaller than the denominator

B. When the eligible-order denominator is zero

C. When a line chart is used

D. When data is refreshed six times per day

Correct Answer: B. When the eligible-order denominator is zero

Question 8

Which practice best supports accessibility in a visualization?

A. Using colour as the only indicator of category

B. Removing labels to reduce visual clutter

C. Providing keyboard access and text alternatives

D. Using as many interactive controls as possible

Correct Answer: C. Providing keyboard access and text alternatives

Question 9

What does row-level security control?

A. Which records an authenticated user may view

B. Which font is used in a chart

C. How many colours a palette contains

D. Whether a query uses a line chart

Correct Answer: A. Which records an authenticated user may view

Question 10

What is the appropriate professional response to AI-generated dashboard code?

A. Publish it immediately if it runs without an error

B. Assume its metric definitions are correct

C. Treat it as draft material and verify it with tests and review

D. Avoid documenting it because the tool generated it

Correct Answer: C. Treat it as draft material and verify it with tests and review