How business knowledge, synthetic data, Codex, and validation turned five CSV files into a working prototype
In the previous article, we showed how five synthetic CSV files became an interactive sales dashboard.
The finished result might create the impression that we entered one carefully written prompt and waited for a complete application to appear.
That is not what happened.
The prompt was important, but it was only one part of the process. The dashboard emerged from a combination of business knowledge, an understood data structure, clearly defined objectives, AI-assisted development, testing, and human review.
Start with information the business trusts
The project began with a straightforward idea:
Could information similar to a trusted ERP sales report become the foundation for a useful business prototype?
Beginning with a trusted report gives the project a familiar reference point. Business users already understand what the report represents, how they use it, and which questions it helps them answer.
But selecting the report is only the beginning.
Before synthetic data can be created, someone needs to understand the information behind that report:
- What does each field mean?
- Which amounts are stored and which are calculated?
- What constitutes a sales transaction?
- How are customers, products, categories, salespeople, countries, and regions identified?
- Which classifications are important to the business?
- Which source tables or exports are required?
- How do the records relate to one another?
I was able to perform this role because of my experience building database, reporting, and business-intelligence applications.
Another business user might need assistance from an internal ERP administrator, report developer, data analyst, IT professional, software vendor, or outside consultant.
The business user does not necessarily need to understand database design. However, someone involved in the project must be able to explain where the trusted report gets its information and what its fields, relationships, and calculations mean.
In some cases, the ERP system may already provide a sufficiently detailed export. If that file contains the required transactions, descriptions, classifications, and calculated amounts, it may not be necessary to identify or extract the underlying database tables for the initial prototype.
Once the data is defined, AI can help
This is where AI becomes especially useful.
Once the required fields, relationships, calculations, and business definitions have been established, AI can help create synthetic data that follows the same general structure.
For this project, we used five synthetic CSV files:
- Consolidated sales transactions
- Customers
- Salespeople
- Products
- Product categories
The synthetic records were completely fictional. They did not contain actual customers, employees, products, or transactions.
The objective was not to reproduce a particular company's data. It was to create enough realistic structure to explore what an application built from that type of information might look like.
Once those files existed, AI could also help transform them into a working prototype.
This creates a practical progression:
- Select information the business understands.
- Define the required data and business rules.
- Create synthetic data that reflects that structure.
- Build a prototype using the synthetic files.
- Evaluate whether the result would provide business value.
- Consider approved production data or more sophisticated integration only after the idea has been validated.
The quality of the prototype still depends heavily on the quality of the data definitions supplied to the AI.
Explore the demonstration
The live dashboard and the synthetic source package will be available here so readers can examine both the result and what it was built from.
The downloadable package should contain only the five synthetic CSV files and a short README explaining their purpose, relationships, calculations, and fictional status. It should not contain client information, credentials, internal notes, or production data.
Codex was the tool we used
Codex was the AI development tool used for this project.
Another team might use Claude Code or a different agentic development environment. The important distinction is not the product name. It is the kind of work the tool can perform.
A conventional AI conversation can help explore an idea, define requirements, discuss useful measures, and generate sample code.
An agentic development tool can work inside the project itself. It can:
- Inspect the source files
- Understand their structures
- Create and edit multiple application files
- Run the application
- Test calculations and relationships
- Identify technical problems
- Compare results with known evidence
- Refine the implementation
The tool can change. The need for sound data definitions, business knowledge, and validation does not.
The real workflow
The project progressed through a series of deliberate steps:
- We selected a sales report that the business could understand and trust.
- We identified the fields, calculations, and business definitions behind that report.
- We determined which source files were required and how their records related.
- We defined the structure and characteristics the synthetic data needed to reproduce.
- We described the intended user and the decisions the dashboard should support.
- AI helped create the synthetic records.
- Codex inspected the CSV files and built the HTML, CSS, and JavaScript application.
- The dashboard totals and relationships were tested against the source files.
- I reviewed the result using practical business judgment and requested the refinements that mattered.
This result did not come from merely asking a chatbot to write some code.
It came from combining an understood business problem with defined source data and an AI agent capable of inspecting, building, running, testing, and refining a complete project.
A good prompt is a project brief
The original prompt is worth sharing, but its value did not come from discovering a magical combination of words.
A useful prompt for this kind of work is closer to a project brief.
It should define:
- Objective: Build a browser-based sales dashboard.
- Audience: A business owner or sales manager.
- Inputs: Five synthetic CSV files.
- Business questions: Sales trends and leading customers, salespeople, products, categories, countries, and regions.
- Output: A simple, locally runnable HTML dashboard.
- Constraints: No database, no external service, and no confidential data.
- Experience: Clear filters, readable charts, useful detail, and approachable terminology.
- Success criteria: The dashboard loads reliably, its totals reconcile with the CSV files, its filters work, and its presentation is useful to a business user.
A simplified version of the starting prompt might look like this:
Using the synthetic CSV files in this project, create a browser-based sales dashboard for a business owner or sales manager. Show total sales, sales trends, leading customers, salespeople, products, categories, countries, and regions. Include straightforward filters and access to the supporting sales detail. Keep the terminology business-friendly. The dashboard must run locally without a database or external service. Validate its totals against the source files and test the filters before considering the project complete.
That prompt established the direction.
It did not eliminate the need for review.
The initial result was remarkably strong
The first dashboard produced by Codex was already an excellent representation of the project brief.
It did not require a long series of cosmetic changes or a complete redesign. The principal business-facing refinement I requested was to organize the regions beneath their respective countries.
That may sound like a small change, but it illustrates an important point.
Codex could see the country and region fields in the source data. My business experience helped me recognize how users would naturally expect those filters to be organized.
The AI produced a strong implementation. Human judgment made sure the result reflected a sensible business structure.
What might have required intervention?
This project produced an excellent initial result, but an attractive dashboard is not automatically a correct or useful dashboard.
Several potential shortcomings could have required intervention:
- Net sales might have been calculated before discounts rather than after them.
- Transaction lines could have been mistaken for complete orders.
- Incorrect relationships could have produced missing or duplicated sales.
- Synthetic prices, quantities, discounts, or customer activity could have been unrealistic.
- A measure labelled “average sale” could have meant an order, transaction, or individual line item.
- Geographic filters could have presented regions without their country context.
- Some filter combinations might not have updated every measure, chart, and detail row consistently.
- The application could have looked convincing while its totals disagreed with the source files.
- Technical terminology might have made sense to a developer but confused the intended business user.
- Unnecessary databases, services, or dependencies could have undermined the simple local prototype.
These are not arguments against using AI.
They are reasons to keep a knowledgeable person involved.
A polished dashboard can still be wrong, misleading, or poorly aligned with how the business operates. Someone who understands the underlying information must review both the calculations and the way the results are presented.
Validation is part of the build
The dashboard was not considered complete merely because it loaded successfully and looked professional.
Its results had to be reconciled with the CSV files.
The project included 19 automated integrity checks covering areas such as:
- Unique transaction identifiers
- Valid customer, salesperson, product, and category relationships
- Transaction-level net-sales calculations
- Sales totals
- Transaction counts
- Units sold
- Dashboard-source reconciliation
- Application dependencies
That validation matters because AI can produce an interface that appears highly convincing even when an assumption, relationship, or calculation is wrong.
The definition of success must therefore include evidence—not merely appearance.
AI did not supply the business judgment
Codex supplied substantial implementation leverage, but it did not independently decide:
- Which business problem was worth solving
- Which report could be trusted
- What the source fields meant
- What the synthetic data needed to represent
- Which measures mattered
- What information could safely be used
- Whether the finished dashboard made business sense
Those decisions came from human experience.
The opportunity is not merely that AI can write code. It is that someone with practical business knowledge can translate that experience into a working prototype much more quickly.
Codex was the tool used in this project. Another practitioner might use Claude Code or a different AI development tool. The technology will continue to change.
The need for business knowledge, informed judgment, and validation will not.
The prompt mattered.
The source data mattered.
The AI development tool mattered.
But the real advantage came from combining clearly defined outcomes, understood business information, synthetic data, implementation leverage, validation, and experienced human judgment.