Start with the question and the supplied records
The example asks a warehouse coordinator which orders need attention. Its eight orders are original fictional records: four shipped, two packed and two blocked. The blocked rows show an assumed label problem and an assumed stock check. They are not a live warehouse feed or evidence of a real business's performance.
Make every headline count traceable to the same records. The summary counts all eight supplied rows. Choosing Blocked narrows the table to two records, while the overall summary stays explicitly labeled for all eight. Choosing Returned shows an empty result rather than inventing a record. The filter changes this local view; it does not update orders or contact an operational system.
Grafana's dashboard design guidance recommends answering a question and progressing from general information to detail. Borrow that structure here: the counts tell you where to look, and the rows explain the next checks. This HTML example does not use Grafana or its live data sources.
Check the generated behavior, not only the design
Give the generator the row identifiers, allowed statuses and metric definitions. Say whether a summary should represent all records or only the current filter. Do not let an attractive chart silently change the denominator.
The sample uses local buttons with visible focus and a selected state. The result count and empty message come from the matching rows. No network, refresh promise, saved filter, edit control or fake success toast is included. Replacing the sample with real records requires your actual data permissions and an explicit export or integration process.
Before relying on the output, check duplicates, missing statuses, totals and the empty-filter case. Keep an unknown value unknown rather than treating it as a shipped order. Verify any extra calculation separately; these counts do not establish shipping speed or service quality.
Generate from a bounded data brief
Create a single offline HTML order dashboard.
Decision and intended reader: [PASTE]
Supplied rows with unique IDs, statuses and action notes: [PASTE]
Allowed statuses, count definitions and missing-data policy: [PASTE]
Whether summaries cover all rows or filtered rows: [PASTE]
Use supplied data only. Mark missing facts [TO CONFIRM]. Label fictional assumptions once. Derive counts from the same rows; flag duplicate IDs or unknown statuses instead of inventing corrections. Include a working local status filter, visible matching count and empty state. Label overall versus filtered totals. No live-data, saved-state, order-update or notification claim.
Use semantic headings, captioned table/scoped headers, labeled rows at 360px and visible keyboard focus. Inline CSS/JavaScript only, at least 16px body text. No external assets, network, storage, editable fields or fake controls. Use textContent for computed messages. Return full HTML and data checks requiring confirmation.
Ask the coordinator to follow one exception
Send the dashboard to a colleague and ask what they would check for each blocked order. If the summary and action notes are hard to compare, read them together in the prepared HTML review copy in NOS, then revise the actual operations brief.
Send the corrected counts with the exception rows attached. Use the real order workflow to make changes and tell the responsible team; changing this review view does neither.