How Do I Connect an AI-Generated Visualization to Real Data?

The visualization works. The data does not.

A common AI workflow now ends in an awkward place. You ask an AI to build a custom chart, map, dashboard, or interactive explanation. It produces something you genuinely like. The interaction works. The layout works. The code may even be better than what you expected.

But the visualization is running on an array of sample records embedded in JavaScript, a pasted CSV, a synthetic object the AI invented, or a snapshot of data that will be wrong next week.

The next question is not how do I rebuild this? It is: how do I keep the thing I like and connect it to the data I actually use?

That is a different problem from generating a visualization. It is the point where a prototype becomes a maintained data product.

Keep the visual. Move the data.

Do not ask the AI to start over unless the visualization itself is wrong.

Instead, separate two jobs that are often mixed together in an AI-generated artifact:

• presentation and interaction: the HTML, CSS, SVG, Canvas, D3, or JavaScript that determines what people see and how they interact with it;
• data: the records, measures, categories, dates, geography, and metadata that are expected to change independently of the design.

In Rhubarb, the visualization code can stay focused on the first job while a data source handles the second. The practical change is often small: the visualization stops reading from something like const data = [...] and starts reading the records supplied by its attached Rhubarb data source.

The goal is not to make the AI-generated code look more conventional. The goal is to keep the useful custom behavior while giving the changing information a real home.

Find the data boundary before you touch the code

Before importing anything, identify where the AI-generated visualization gets its records.

Look for patterns such as:

• a large JavaScript array of objects;
• JSON embedded inside the HTML;
• a CSV string parsed in the browser;
• an external fetch() request;
• example records generated inside a function;
• hard-coded values repeated throughout drawing code.

The cleanest case is a single array of records. That can usually be replaced with project data while leaving the rendering logic nearly untouched.

The harder case is when the AI mixed data values directly into drawing instructions. Before connecting a source, ask the Assistant to isolate those values into a simple record structure without changing the appearance or interaction. Once there is a clear data boundary, moving to a real source becomes much less risky.

Choose the data source based on how the data changes

"Real data" does not have to mean a database.

If the source is a CSV, JSON, Excel, or Stata file, bring the file into the data layer and use its supported update path when a new version arrives. If the source lives in Google Sheets or PostgreSQL, use the corresponding connected data source. If the final visualization needs fields from multiple Rhubarb sources, prepare them in a Data Blend first.

One visualization currently links to one prepared Rhubarb data source. That is useful discipline: give the browser the specific result the visualization needs rather than making the visual itself responsible for coordinating several unrelated sources.

For example, a map might need one prepared result containing the geographic identifier, current value, comparison value, label, and a compact metadata field. The browser does not need the entire analytical warehouse just because the source system contains it.

Ask the AI to adapt, not redesign

Once the real data is attached, make the instruction narrow.

A useful request is:

Preserve the current layout, styling, interactions, labels, and chart type. Replace only the hard-coded sample data with the attached data source. Map the existing fields to the new source and tell me if any required field is missing.

That wording matters. AI tools are very willing to "improve" a visualization while solving an unrelated engineering problem. Here you want a data migration, not a creative rewrite.

After the change, compare the result against the original version. Check the first and last record, null values, the smallest and largest categories, long labels, empty filters, and any calculated values. A visualization that looks the same can still be wrong if a field was mapped incorrectly.

Decide what "updates" means before you publish

Connecting real data is only half the job. You also need a simple answer to: what happens when the data changes?

In Rhubarb, PostgreSQL, RhubarbGeoDB, Data Blend, and Google Sheets sources can refresh automatically. File-backed data follows its supported replacement/update workflow. The important thing is to make the path explicit and test it before the visualization matters to somebody else.

A connected or refreshable source does not mean that every public page view runs a new database query or that every source is streaming in real time. Rhubarb's data-source layer prepares and stores the result the visualization uses according to the source and refresh workflow. That separation is useful for performance, review, and publication safety.

If true sub-second streaming is part of the requirement, treat that as a separate architecture question rather than assuming a normal published visualization should behave like a trading terminal.

Do one deliberately boring update test

Before publishing, change the source in a way you can recognize immediately.

For example:

1. add one valid new category or record;
2. change one existing value;
3. introduce one null or missing value;
4. extend the date range;
5. refresh or replace the source using the intended production workflow.

Then confirm that the visualization incorporates the valid changes, handles the null safely, preserves the intended interaction, and does not require the code to be regenerated.

That test is more important than another round of visual polish. It proves that you now have a visualization plus an update path, rather than a prettier static artifact.

Do not move secrets into the browser just to make the demo work

An AI-generated visualization may solve "live data" by putting an API key, database credential, or bearer token directly into JavaScript and calling the source from the browser. That can look convenient in a local prototype and still be the wrong production design.

Anything delivered to visualization JavaScript should be treated as visible to the viewer. Keep private credentials in the data-source layer. Narrow the data before it reaches the visualization. Do not send hidden columns to the browser and rely on the interface not to display them.

The visualization should receive the information it needs to render—not the credentials required to go discover that information itself.

Hard-coded data is not always wrong

There are legitimate self-contained artifacts. A historical timeline with a fixed set of facts, a teaching demonstration, or a small visual toy may be easier to preserve when its data remains inside the code.

The distinction is whether the data has an independent lifecycle.

If a number will change, if a new row will arrive, if somebody will upload next month's file, or if a database already owns the authoritative record, move the data out of the visualization. If the dataset is intentionally frozen as part of the artifact, leaving it embedded may be the simpler and more durable choice.

From AI prototype to something that keeps working

AI has made it easy to get to a compelling first visualization. The next layer of work is less glamorous but more valuable: connect the output to the authoritative data, make updates predictable, keep credentials out of the browser, and preserve the custom interaction that made the artifact worth keeping in the first place.

That is the shift from AI generated this to this is now a working visualization we can maintain.

Frequently asked questions

Can I connect a ChatGPT or Claude visualization to my real data without rebuilding it?

Usually, yes. Keep the HTML, CSS, and interaction you already like, move the real records into a Rhubarb data source, and change the visualization code so it reads the attached project data instead of an array or sample object embedded in JavaScript.

Can the data update automatically after I publish the visualization?

It depends on the source. PostgreSQL, RhubarbGeoDB, Data Blend, and Google Sheets sources can refresh automatically in Rhubarb. File-backed sources can be updated through their supported replacement workflow. Choose the refresh path before publication and test it with changed data.

Can one Rhubarb visualization use several data sources?

A visualization currently links to one prepared Rhubarb data source. If the visual needs information from several sources, combine or narrow them into a Data Blend first, then attach that resulting data source to the visualization.

Should my AI-generated visualization call a database or private API directly from JavaScript?

Not when that would expose credentials or private data in the browser. Treat visualization JavaScript as visible to the viewer. Put private connection details in the data-source layer and send the visualization only the records and fields it actually needs.

When is it fine to leave the data hard-coded in the visualization?

When the data is intentionally static and part of the artifact itself—for example, a small historical explainer or a fixed demonstration. If the records are expected to change, separating data from presentation makes future updates much safer.