A column is not a question

The operations manager wants one chart for Monday’s meeting: which of her storemen is writing off the most gear. She exports the activity log, opens a pivot, drags “Action” into the rows and “Count” into the values. The chart that comes out has three hundred and forty bars. Each is a slightly different sentence — “Wrote off 2 × Radio”, “Wrote off 1 × Radio (damaged)”, “Written off: Torch” — and not one of them is the answer.

She did nothing wrong. She used the tool the way it offers itself: pick a column, group by it. The tool did nothing wrong either; it grouped by the column. The problem is upstream of both. A column is storage. A question is meaning. The log stored what happened in the words it happened in. Nobody ever told it what “a loss” was.

You can see the same failure in a dozen shapes. Group by holder and you get user IDs, not names. Group by location and you get “Store 2”, “store 2” and “Store-2” as three places. Filter the log for “returned” and you match one wording out of five. The picker looks generous because it offers every column. It is generous the way a dictionary is generous with a person who asked for directions.

A column stores. A question means.

A question worth putting on a dashboard passes three tests. First, its answers come from a finite vocabulary that a human could read aloud: eleven kinds of event, the locations already on your gear, the departments people already belong to — never “whatever text is in the rows”. Second, each answer has a label people already use: the department’s name, not its key; the badge the log page shows, not the sentence behind it. Third, and this is the one that quietly breaks most dashboards, the question means the same thing in the filter and in the chart. If “write-offs” in the filter matches two wordings and “write-offs” in the group-by matches three, the widget is confidently wrong and nobody can tell.

The fix is not a smarter picker. It is deciding, once, what the questions are, and where their answers come from. A source — the log, the items, the people — declares the questions a person actually asks of it. Each question says where its vocabulary lives: a fixed list, a lookup to a name, or the distinct values already in the data, cleaned. And each question has exactly one rule for turning a row into an answer, used by the filter and by the chart alike, so the two can never disagree. The raw column stays where it belongs, underneath, for the rare day someone needs it.

Doing this by hand is possible. A careful analyst keeps a sheet of “canonical categories” and a lookup table for IDs, and re-applies them every export. It lasts until the second analyst, or the first busy month. The rule that matters is the one the system holds for you, because a question that must be re-asked correctly every Monday will eventually be asked wrong. The same goes for the lookup: a name the system resolves for you every time is a name nobody has to remember to paste.

This is how GearLogs builds a widget. You do not pick a column; you answer a few plain questions: which source — the items, the people or the log — what to keep and what to split by, how it should look, and what to call it. The splits are the ones people actually ask about — a location, a group, a department, a kind of event — and the activity “type” is the same eleven badges the activity log shows, not the sentences behind them. A widget’s filter and its chart read the same rule, so they cannot drift apart. Ready-made widgets take a couple of clicks; building your own takes a handful of plain answers; and the chart that comes out has as many bars as there are real answers, which is usually fewer than ten.

The operations manager still wants her chart for Monday. She asks the dashboard the question in its own words — the log, write-offs only, split by who recorded them, over the last ninety days — and gets four bars. The tallest one is the conversation.