Review-screen anatomy
Three patterns show a record for review — record detail, object page, and approval — and they were built independently, for different reasons, in different slices. Compared afterward, they had already converged on the same four regions. That convergence is the contract on this page: not a new pattern, and not a new component — the decision a screen author no longer has to make twice.
The four regions
| Region | What it answers | Built from |
|---|---|---|
| Identity | What is this, and what state is it in right now? | Badge for status, a title |
| Facts | The small fixed set the reader needs before doing anything else. | Kv |
| History | How did it get here — what happened, in order? | Timeline or audit trail |
| Action | What can the reader do about it, and where does that live on screen? | Form actions, wizard controls, or nothing (read-only) |
All four are shipped primitives. This page names an order and a set of slots — it adds no CSS and no component.
History answers THAT something
happened; it does not by default answer WHAT changed. For a
single-field edit the audit entry's own text usually says enough
("J. Kim approved"). For a multi-field change, nest a small
.bo-data-table (Field / Old / New / a badge reading
Added/Removed/Modified) inside the entry's detail slot — see
record detail's third audit
entry for the worked composition. Scored, not shipped as a component: the
NEED/COST rubric put it below the bar for new surface (roadmap 53.3).
Which of the three patterns — decided by two questions, not by taste
The content that actually removes a decision from a screen author isn't the four regions above — every ERP detail screen already has some version of them. It's knowing which pattern to reach for, before writing any markup:
- Is the current moment itself a decision someone must make — approve, reject, sign off? Use approval. Its anatomy is the same four regions, but History and Action share the screen with a queue, because the reader is choosing, not just reading.
- Otherwise: how long is the record? Short enough to take in on one scroll (a handful of facts, a short history) → record detail. Long enough that the reader needs to jump between sections rather than scroll through all of them → object page, which adds in-page navigation and a collapsing header — built because a short-record layout stops working past a certain length (roadmap 52.2).
Answering those two questions is the whole choice. Nothing below this page is a third option — a screen that doesn't fit either fork is a new pattern, not a variant of these three, and earns its own Accept criteria the way every pattern here does.
Where each pattern spends the four regions differently
| Region | Record detail | Object page | Approval |
|---|---|---|---|
| Identity | Breadcrumb + title | Sticky header, title + badge | Stepper's current step |
| Facts | Facts strip (.bo-kv) | Collapsing kv strip under the header | Record summary — just enough to decide without leaving |
| History | Record feed, then status timeline + audit trail | One section among several, reached via the anchor bar | Status timeline is the primary content, not a supporting one; audit trail is append-only underneath it |
| Action | Feed input (add a record: receipt, invoice, or note) | Sticky footer action bar | Decision cluster (Approve / Reject) opening a dialog, plus the queue for what's next |