The brief was a review flow. An AI pass had read a few thousand columns of metadata and proposed names, types and descriptions. The export was a JSON file with 826 findings in it. Somebody had to accept or reject each one, and the first design did the obvious thing: a table, one row per column, with the proposals in extra cells.
It was unusable in a way that took a day to name. A column might have three proposals (rename it, change its type, describe it) and a reviewer might agree with two. The row had one Accept button. So people accepted everything, or nothing, and the point of review disappeared.
The reframe
One row per proposed change, not per column. The unit of review is the decision, and the decision is “this rename, yes or no”. Three proposals on one column are three rows, and each can be accepted, skipped or edited on its own.
That sentence changed the whole screen. Rows became short enough to clear with the keyboard (A to accept, S to skip, E to edit) and progress became honest: 412 of 826 reviewed means 412 decisions, not 412 columns half-done.
What the database wanted
The database wanted one row per column, because that is how it stores things. The JSON export mirrored it. The first design mirrored the export. Three layers of the same mistake, each one reasonable on its own. The rule I took from it: the database is not the information architecture. Start from who is here and what job they came to finish, and the job here was deciding, not browsing.
Where the model stops
The grid also settled what the model may not do. It proposes; it never applies. Accepted changes are queued and applied in one explicit step by a person with the right to make them. Retry resumes from the last reviewed row. Every proposal carries which model made it and when. And rejected proposals are kept with the reason, because a rejection is the most useful training signal in the whole flow.
It is a small screen. It is also the clearest example I have of design judgement living in a sentence, not a mock-up.
