The operational problem

Large RtU reviews can include long source lists, repeated fetches, and evidence chains that take materially longer than a normal inline request. When that entire workload is forced through one blocking response, the system becomes vulnerable to timeout failures even when the underlying review logic is correct.

That is why the problem has to be treated as an operating-pattern issue, not just a front-end error state.

The current Souma pattern

Souma is standardizing around a split model: a fast gating path that decides whether the output can continue through the workflow, and a deeper evidence path that can finish asynchronously and attach richer provenance or review material after the initial decision.

For developers, that means leaning on the current `/api/validate`, `/api/validate/result/:id`, `/api/validate/results`, and `/api/validate/stream` flow instead of assuming every review should resolve in a single request cycle.

• Batch large source lists before submission.
• Use result polling or streaming for long-running review work.
• Keep the UI responsive by separating first-decision posture from full evidence completion.

What reviewers see

The platform direction is to make this separation visible but calm. Reviewers should see whether a decision cleared, whether evidence is still being assembled, and whether the result needs escalation. They should not be forced to interpret transport-layer failures as business logic.

That is the difference between a compliance tool and a defensible compliance platform. The system has to stay understandable under load, not only when the happy path is fast.