The chart is not the hard part

Every charting library can draw a line. Point it at two columns and it will happily plot them, whether or not the result means anything. The hard part was never the drawing. It is deciding what to draw, and that decision lives in the messiest part of the problem: understanding an arbitrary file a person made by hand.

The part no rule can do

Consider a column called Signed with values like 3/2/24 and Mar 2024, a column called MRR with a dollar sign in some rows and not others, and a column called Region with eight repeated values. A person reads that in a second: a date, some money, a category. A fixed rule reads it as three columns of text.

• Which columns are dates, and in which of five formats.
• Which numbers are money, counts, rates or ids.
• Which category is worth breaking the numbers down by.
• Which two of forty columns actually tell a story together.

That is language work. It is reasoning about meaning from sparse, inconsistent evidence, and it is exactly what modern language models are good at and what regular code is not. So the model sits at the centre of Plotwell, doing the understanding.

And the part the model must not do

Here is the line. The model decides which columns to chart and how to aggregate them. It never computes the result. Plotwell aggregates your real rows for every chart, in code, and checks every figure in a takeaway against the numbers it computed. Anything it cannot trace to your data is dropped.

The result is a product where the smartest part, the understanding, is a model, and the trustworthy part, the numbers, is plain arithmetic on your data. That split is the whole design.