The unit of work grows with the model

Tags: scale, corpus, batch

Every product is shaped around what was affordable when it was designed. One document at a time, because each one cost a model call somebody had to justify. Then the cost falls, and the shape stays — so the product keeps asking about one thing while the user does the aggregating by hand.

The tell is people batching

If users are running the same operation over forty items one at a time, the product's unit is wrong. That is not a workflow preference, it is a workaround, and it is the cheapest signal available that the interface is a generation behind its own model.

The reason it goes unnoticed is that nothing breaks. Every individual interaction works exactly as designed. The loss is invisible because it is distributed across a hundred small sessions, and because the thing that was lost was never built — the user simply never got to ask the question that only makes sense across a set.

A bigger unit makes different questions available

This is the part that matters, and it is not about speed.

At one document: what does this say?

At the corpus: which of these disagree? Which are missing the clause we always require? Which three have renewal terms that contradict the master agreement? What changed between the 2023 set and the 2024 set?

None of those are faster versions of the single-document question. They are different questions, unavailable at the old grain, and they are usually worth more than the one the product was built to answer. A team that moves its unit up does not get the same product accelerated; it gets a different product, and the single-item view becomes a detail pane inside it.

What actually has to change

The review branch is the one that bites. Growing the unit of work grows the unit of consequence at the same time, and an approval flow designed for one item will happily be clicked once over four hundred. That is a governance regression delivered as a feature, and it arrives without anyone deciding it.

The other requirement is a path back. An aggregate view that cannot return you to a specific instance has replaced one incomplete interface with another — users need to see the three that disagree and then read one of them.

Grounded in

DocRobot's rebuild moves the unit from one document to the whole corpus, and the reason is specific: with inference on the device there is no upload decision and no per-document exposure, so the constraint that kept the unit down to a single file has gone. The library is indexed locally and the questions change shape.

The original could summarise a contract. It could not tell you which of forty disagreed — not because nobody wanted that, but because asking would have meant forty uploads through a trust boundary that existed to prevent exactly that. The unit was not a design choice, it was the constraint wearing a design choice's clothes, which is what makes it so easy to keep after the constraint lifts.

Anti-patterns

• Keeping the per-item unit after cost stopped being the reason for it. The default, and invisible because nothing is broken.
• Batch as a bolt-on. A "select all" that loops the single-item flow. Faster, and it still cannot answer a set-level question.
• Aggregate views with no route to the instance. The user can see that three disagree and cannot read them.
• Growing the unit without growing the review model. One click, four hundred items, same approval UI.
• Treating the larger unit as the only unit. Sometimes the user really was asked about one specific thing.
• Assuming comparability. A corpus of unrelated documents has no aggregate question, and forcing one produces confident nonsense about an arbitrary pile.

The smallest version worth building

Pick the one question your users currently answer by opening things one at a time and writing in a spreadsheet. Build that question at the set level.

Then check what it does to your approval flow before shipping it, because the answer is usually "quietly removes it".

Related patterns

• Work without being asked — the same cost collapse, spent on initiative rather than on scope.
• Redaction moves to the export — the other thing that changes when the boundary moves, from the same rebuild.
• Evaluation loops — a set-level operation is considerably harder to spot-check, which raises the value of a fixed case set.