A Plotting Tool Should Know What A Recipe Step Is

Ask an engineer which features of their analytics platform they actually use and you will get a list of about ten. Ask what the organization licensed, and it is several hundred. This is usually presented as waste — paying for capability nobody touches. That framing is too kind to the platform, because it treats the unused features as merely idle. They are not idle. They are the reason the ten you need are three menus deep.

Why Breadth Is Forced

A general-purpose analytics platform has to serve people modelling clinical trial outcomes, people forecasting revenue, and people looking at equipment logs, from one surface. That is a real engineering constraint, and breadth is the honest response to it. Nobody built those hundreds of features out of carelessness.

But it has a consequence that follows inescapably from the requirement: the platform cannot know what a recipe step is. It cannot know that a log has a column whose changing value marks the boundary between one run and the next. It cannot know that the interesting comparison is almost always a suspect run against a known-good reference, or that two executions of the same recipe take different amounts of wall-clock time and therefore will not line up on a raw time axis. To know any of that would be to stop being general.

Where The Domain Knowledge Lives

So the knowledge has to live somewhere else, and where it lives is in the engineer.

Every session, they supply it by hand. They know which column marks run boundaries, so they build the filter that splits on it. They know the two runs started at different times, so they compute an offset and shift one of them. They know the first stretch of a step is startup transient and shouldn't be averaged, so they trim it — by eye, differently each time, at a boundary they would struggle to describe precisely if asked.

Every one of those is domain expertise, correctly applied. And every one of them is re-entered from nothing at the start of the next session, because the software has no concept that could hold it. The expertise lives in the engineer's fingers, which means it is invisible, unreviewable, inconsistent between two people looking at the same file, and completely lost when they move to another group.

A tool that knows the domain encodes those facts once, as objects with names — a run, a step, a collection window, a limit profile. That is why the visible feature count goes down as the tool gets more useful. Hundreds of generic operations collapse into a handful of specific ones, because the tool is now carrying assumptions the engineer was previously carrying by hand.

Count Clicks, Not Features

If you want a test that survives a vendor conversation, do not count features. Count the clicks between the file landing on your desktop and the answer being on screen.

Not the demo path, where someone who wrote the software drives. Your file, your format, your question — the one you actually had this week. A tool with three hundred features and forty clicks loses to one with twelve features and three, and the click count is the only one of those two numbers that corresponds to how your Tuesday goes.

The comparison is uncomfortable for narrow tools too, and it should be. It is a test a specialized tool can fail — if the specialization was aimed at a workflow that isn't yours, the clicks pile up exactly the same way, and now you don't even have the general platform's escape hatch. Narrowness is not automatically a virtue. It is a bet that the builder understood the job.

Narrow Is A Commitment, Not A Shortcut

Which is the honest version of this argument. Building for one domain is not easier than building for all of them; it is a commitment to being wrong in public if the domain was misread. A general platform can never quite be wrong, because it never quite claimed anything — it hands you primitives and the responsibility for assembling them. A tool that says "here is what a run is, here is what a step is, here is how they should be compared" has made a claim that an engineer can reject in about four minutes.

That is the trade worth making. Ten features that match the work beat three hundred that are prepared for any work at all, but only if the ten were chosen by watching the work being done. The feature count was never the thing being argued about. It was always about who has to hold the knowledge — the tool, or the person using it at the end of a long shift.