That’s an architectural model, not a claim about ChartPetal’s exact internal implementation.
The stack matters less than the contract
I’m keeping this post library-agnostic rather than publishing an unverified framework or model list.
The important stack boundaries are the web interface, tabular-data handling, AI interpretation, and visualization layer. Whatever libraries sit underneath, each boundary needs an explicit contract.
For example, a proposed chart specification should reference columns that actually exist. Numeric operations should require numeric inputs. An aggregation shouldn’t appear merely because the renderer needs one value per category.
That suggests a useful rule: let the model propose; let deterministic checks decide what is valid.
CSVs are deceptively complicated
A column containing 00123 might be an identifier, not a measurement. A date such as 04/05/2026 isn’t unambiguous. Empty cells and zeroes aren’t interchangeable.
These aren’t exotic cases. They’re ordinary business data.
The engineering challenge is deciding when inference is safe and when the interface should ask the user. Too many questions make the tool tedious. Too few make it unreliable.
What I’d like feedback on
I’m especially interested in how other developers would expose uncertainty without overwhelming the UI.
Would you show an inferred schema before generating anything? Ask only when confidence is low? Require confirmation for aggregation?
Try ChartPetal with a non-sensitive table and tell me which assumptions you’d want a chart generator to make explicit.
Top comments (0)