UC2 · Step 5 of 5 — Recap

Kavi Patel · Timekeeper

What just happened

In about 3 minutes, Kavi:

Opened the Activity Errors queue and saw 12 hard fails ranked by severity.
Selected the top item and read the punch-vs-activity timeline.
Chose the right fix (trim activity to punch out).
Saved — and the error cleared from PLP feed, the Activity Errors report, the supervisor's dashboard, and the queue itself.

Today	With the new app
Activity errors live in multiple reports and spreadsheets.	All in one Activity Errors queue.
Investigating "what really happened" means pulling several sources.	The punch-vs-activity timeline shows it in one picture.
Fixing an error and fixing its downstream consequences are separate steps.	One save handles both.
Kronos punch adjustments are a separate process Kavi has to remember to trigger.	The "send to Kronos missing-punch queue" option routes through the existing path with one click.
The supervisor finds out about a resolution by asking.	The supervisor's dashboard reflects the change on the next refresh.

Kronos still owns punches and missing-punch resolution. The new app routes there through the existing path; it does not write back.
Kavi's judgment is still the input. The system offers shape; the decision is human.
Audit is unchanged in spirit, complete in coverage. Every correction is recorded with who, what, when, before/after.
No auto-correction. Hard fails wait for a human.

Are the three resolution options (Trim, Split, Send to Kronos missing-punch) the complete set? What's missing?
Is the 30-minute SLA for hard fails right? Should it vary by error type or by shift end proximity?
Should Saved Views be per-user, per-role, or both? Which ones should ship by default?
Is the Downstream Check panel the right level of detail, or do timekeepers want more (cycle counts, last poll timestamp, retry queue)?
Should the queue support bulk fix for low-judgment cases (e.g., a batch of identical coverage-gap warnings)?