UC4 · Step 4 of 4 — Recap

Maria Rivera · Staffing Clerk · Dept 3630 / Line 5

What just happened

In about 2 minutes, Maria:

Spotted the spread-flagged order by its purple SPREAD badge.
Keyed one activity for one employee — full shift, 8.50 hours.
Tagged three shop orders that the activity contributes to.
Reviewed an allocation preview that derived 4.00 / 3.00 / 1.50 hours from the schedule's line-hour weights.

No math. No spreadsheet. No follow-up email.

What changed vs today

Today	With the new app
TTS is a separate manual workaround.	TTS is a first-class capture, in the same workflow.
Allocation math happens in the clerk's head, on paper, or in a downstream note.	Allocation is derived from schedule line hours, in the app.
Errors surface in warehouse data weeks later.	Allocation preview catches them at capture.
The link between activity and allocation lives outside the system.	The link is captured atomically with the activity.

What stayed the same

Weighting metric: shop-order line hours. The confirmed business rule is unchanged.
Downstream consumers (PLP/BI warehouse, reports) continue to see the same shape of spread data.
Kronos timekeeping is untouched — TTS lives entirely in the new activity model.
The business decision is closed. Only the implementation contract (Option A vs B) remains open, and that decision is invisible to Maria.

What to take into the workshops

Are there other TTS-style spread patterns beyond shop-order weighting? (Multi-line spread, multi-day spread, blended rates?)
Should the allocation preview be savable / shareable so a supervisor or analyst can see what was captured without opening the editor?
Should the tag picker enforce maximum spread count (e.g., no more than 5 shop orders per activity)?
How does spread interact with mid-shift moves and transfers? If Maria moves an employee off a spread order mid-shift, what does the allocation look like?

On the open implementation contract

The two options (persist spread rows in new DB · vs · compute in Mt Olive IT extract) are both fine. The recommendation is:

If IT prefers minimal new tables and is comfortable owning the extract logic → Option B.
If the team wants the new DB to be self-describing for warehouse consumers → Option A.

This is a contract decision for Ryan + IT, not a stakeholder workshop decision. Track it in the PRD as an implementation contract item, not as a reopened business question.