Public records requests, against the clock
The statutory clock starts when the request arrives, not when somebody notices it. Tracking is a spreadsheet, and the deadline is remembered rather than shown.
For a city secretary or records officer.
Public records requests, against the clock
Illustrative sample. Not a client record.
| Request | Item | Status |
|---|---|---|
| PIR-2026-118 | Council correspondence | Open |
| PIR-2026-119 | Police body-cam index Due in 2 business days and not yet assigned. Volume suggests it needs a cost estimate letter, which has its own deadline. | Open |
| PIR-2026-120 | Contract file | Open |
| PIR-2026-121 | Personnel file Contains material that may be excepted. Needs an Attorney General ruling request, and that clock is shorter than the response clock. | Open |
| PIR-2026-122 | Permit history | Open |
| PIR-2026-123 | Budget workpapers | Open |
Two requests need action before their deadline rather than on it, and each needs a different action. The system escalates ahead of the date rather than reporting the miss afterwards.
Today the clock lives in somebody’s memory and a spreadsheet, and the first sign of a problem is a complaint.
This is a demonstration, not a product. Every record above is invented. The point is not the table — it is that the exception is named, with the field at fault and what it usually means, rather than returned as a code somebody has to decode.
What we would build for you runs on your data, in your environment, and looks like your process rather than this one. More on this category: Records and case workflow.
The other three
- State reporting, validated before submission A district data manager in a submission window
- One permit queue across three departments A permit technician and the departments they chase
- One number, from three systems that disagree A finance director assembling a board packet