Summary
An operational UI earns its keep when it shortens the distance between uncertainty and a safe decision. It should show what needs attention, what evidence supports the current state, what has already happened, and what a person is allowed to do next.
Problem
A table can show what the database stores. It usually cannot explain why an item is blocked, which artifact conflicts with another, whether someone already made a decision, or how work can resume. When the interface exposes records without that context, the operator becomes the orchestration layer: searching across screens, reconstructing history, and carrying the next step in memory.
Principle
Build UI around work that must be understood and acted on, not around database table ownership. Organize the surface around queues, cases, evidence, artifacts, timelines, decisions, and repair actions.
Platform Shape
The web app contains route groups for jobs, DAGs, geo analysis, marketing, payroll, POA, and precon. The intended boundary is clear: those surfaces read service-built projections and use API routes to adapt user intent into owned capabilities. The UI remains a view and action boundary; it does not become an alternate persistence or provider layer.
This shape matters most when automation reaches its limit. A review surface can assemble the relevant state, evidence, history, and permitted action in one place. The person contributes judgment. The system carries the context before and after that decision.
Tradeoffs
Task-oriented interfaces require more modeling than generic CRUD screens, and a poor read model can hide freshness or omit important context. The answer is not to push raw tables onto operators. It is to make provenance, state, and limits visible enough that the surface supports accountable action.