Fix the review date and counting rule
This original fictional office ledger is reviewed as of October 13, 2026. It tracks ordinary office requests, not repair instructions or operational safety clearance. A request is overdue-open when it is not closed and its due date is earlier than the as-of date.
| ID / request | Due | Owner | State | Evidence or gap |
|---|---|---|---|---|
| M1 / Lobby printer | October 12 | Operations | Waiting for vendor | Vendor update needed; no closure note. |
| M2 / Meeting-room display | October 14 | IT | Scheduled | Appointment planning note; completion not supplied. |
| M3 / Desk cable organizer | October 12 | Operations | Closed October 12 | Fictional completion note DEMO-C03 supplied. |
| M4 / Copier check | October 10 | [UNCONFIRMED] | Open | Owner and next action to confirm. |
All rows and notes are invented demonstration inputs. The LeanSuite public work-order description distinguishes request, planning, completion, and handback fields and describes backlog review. This office request model does not reproduce its gated workbook, adopt machinery procedures, or use its sample performance figures.
Count the rows before making the tiles
There are four unique requests, three open, two overdue-open, and one closed. The overdue-open IDs are M1 and M4.
M2 is open but not overdue on October 13 because its due date is October 14. M3 has a past due date but is closed, so it is not overdue-open. If you want a historical late-completion measure, define and calculate it separately from this open-backlog rule.
Do not turn these counts into equipment reliability or repair success rates. The ledger lacks the operating-time, failure, repair-duration, and outcome data those measures would need. It also does not say whether an asset may safely be used.
Make the next owner action visible
For M1, show the vendor dependency and ask Operations for the next update. For M4, show Owner to confirm before a due-date warning; the review needs someone to take responsibility, not merely a red tile.
For M2, retain scheduled status until the actual work and authorized completion evidence arrive. For M3, let the reviewer inspect the supplied demonstration closure note instead of changing every “done” entry into an unexamined success claim.
If a record is labeled closed but its required evidence is missing, flag a contradiction for the record owner. Do not silently reopen, certify, or dispatch it from a review copy.
Label the scope of each filter
An IT filter shows only M2: one matching open request, zero matching overdue-open requests. Keep the whole-ledger summary labeled as four/three/two/one, or explicitly change its scope label with the filter. A filtered zero does not mean the organization has no overdue work.
Keep the as-of date visible in every snapshot. Updating a date without recomputing the rows can leave a summary describing a different review period.
Copy a request-dashboard prompt
Draft an original maintenance-request review dashboard in US English.
Source rows with unique IDs, due dates, owners, states and evidence: [inputs]
As-of date and overdue/closure policy: [inputs]
Blockers, required follow-ups and authorized original record format: [inputs]
Show the underlying ledger and derive counts only from eligible unique rows. Define overdue-open with the supplied date rule and exclude closed requests from that count. Preserve scheduled/waiting/open/closed distinctions and missing owners or closure evidence. Connect summary figures to inspectable rows and the next action, without changing approvals or dispatching work. Label filtered counts separately from overall scope and retain the as-of date.
Do not invent owners, dates, work completion, reliability/repair metrics, safety clearance or live integrations. Use fictional ordinary-office data for a public example and [NEEDED: input] for gaps. Optional local filters/row inspection need keyboard/text states; no real dispatch, CMMS connection or saved record changes. Return a review specification, preserving authorized histories and approvals in the original system.
Confirm M4's owner and M1's next vendor update in the maintained work-order record. Reconcile closure evidence before changing states. End the weekly review with traceable pending actions, not a summary that hides the requests behind it.
Optional: read a sanitized backlog snapshot in NOS
NOS can save and render a prepared HTML review of the fictional ledger. Use it to inspect the dated counts beside unassigned and blocked requests; keep actual work-order histories, completion approvals, and operational decisions in the authorized system.
