Use synthetic data when demonstrating AI analysis

Use original synthetic data to demonstrate an analytical workflow without exposing real customer records. Design the data to exercise the business rules and failure cases you want to teach, and label it clearly. A fictional dataset can prove how code behaves on its rows; it cannot establish real market patterns or client outcomes.

Synthetic does not automatically mean anonymous. Data generated from sensitive source records can retain identifying patterns. This tutorial uses deliberately invented teaching records rather than transforming a confidential dataset.

Design for learning, not decorative realism

The original commerce fixture contains ten orders. Eight are completed in January, one is cancelled and one is pending at the next period boundary. Two different eligible orders share the same amount, and one eligible order has no matching customer record.

Those choices are intentional. Repeated amounts expose misuse of SUM(DISTINCT amount). The unmatched customer exposes an incorrect inner join. Boundary timestamps test inclusive and exclusive period rules. Multiple refund records for one order expose denominator errors.

A larger table of uniformly clean random rows could be less useful for teaching these mistakes. The fixture's value comes from explicit expected behavior, not the number of rows.

Verify that the intended cases exist

import csv
from collections import Counter
from pathlib import Path
from calculator import calculate,SOURCE

with SOURCE.open(encoding='utf-8',newline='') as handle:
    rows = list(csv.DictReader(handle))
with Path('../commerce-sql/customers.csv').open(encoding='utf-8',newline='') as handle:
    customer_ids = {row['customer_id'] for row in csv.DictReader(handle)}
evidence = calculate()
eligible = [row for row in rows if row['order_id'] in evidence['evidence_order_ids']]
amount_counts = Counter(int(row['order_total_paise']) for row in eligible)
assert len(rows)==10 and len(eligible)==8
assert amount_counts[10000]==2 and amount_counts[12000]==2
assert [row['order_id'] for row in eligible if row['customer_id'] not in customer_ids]==['O1009']
assert any(row['ordered_at']=='2026-02-01T00:00:00' for row in rows)
assert evidence['value']==104000
print({'original_synthetic_orders':10,'eligible_orders':8,
       'repeated_amount_cases_present':True,'unmatched_eligible_order':'O1009',
       'exclusive_end_boundary_present':True})

These assertions make the fixture's teaching purpose reproducible. If someone edits a row and removes a failure case, the checks reveal the change rather than leaving an outdated article example.

Write a provenance statement

State that the records were invented for the tutorial, identify their intended use and explain that the values are not sampled from a real business. Document the schema, units, period interpretation and expected outputs.

If a generator uses randomness, preserve its seed, configuration and code version. A seed alone may not reproduce every library-dependent result across environments, so record the relevant runtime too. This small commerce fixture uses fixed authored rows, making the expected cases directly inspectable.

Keep any fictional personal fields obviously synthetic and exclude them from examples that do not require them. The analyst AI calculator needs order evidence, not a believable person's contact details.

Avoid false realism claims

The fixture's refund share, order amounts and customer mix are not industry benchmarks. Do not write “our client reduced errors” or “Indian retailers typically experience this rate” based on invented records.

Likewise, a language-model answer to this tiny dataset does not establish performance on a production warehouse. The demonstration can show a join error being detected and a corrected result being reproduced. Scale, source completeness, permissions and real task diversity require further evaluation.

Pair the fixture with a challenge set

Provide valid and invalid variants in temporary copies: duplicate an order ID, change the currency label, introduce a negative amount or add another refund to an already refunded order. State which results should change and which should remain invariant.

Keep the original dataset unchanged so readers can reproduce the published baseline. If a correction is necessary, version it and regenerate the expected results rather than silently replacing the evidence.

Exercise: design five fictional rows that distinguish a legitimate repeated amount from a duplicate transaction. Write the expected total before coding the solution and explain why removing duplicate amounts would be wrong.

NeuraPath's Data Analytics with Generative AI course uses reproducible exercises to connect concepts with working analysis. A good synthetic example is small enough to audit and rich enough to expose the mistake being taught.

Continue learning

This article is part of the Generative AI for verified analyst work sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in Detect prompt injection inside an uploaded business document.
• Continue with Create an analyst AI verification protocol with pass criteria.