Repair & Reuse · Question 05 · Update attribution
Keep the update with its job.
How do we keep a fast status update attached to the correct job, hub and team?
Start the update from a job card or scanned job reference. Carry the stable job ID and hub into a visible confirmation, then resolve the team from a dated assignment roster. A title, sender or chat channel is a useful hint, but is not a safe join key: six cross-trained staff work across two hubs.
The evidence boundary: these fixtures establish three job IDs, hubs and named owners. They supply no team IDs or roster. We can check job and hub here; actual team attribution remains unresolved. The optional team map below is an authored demonstration assumption.
Fictional what-if workspace. Changes stay in this tab and reset on reload; no record is saved and no external system is changed.
Try a fast update
First pick the job you think receives the message. Similar jobs at the other hub make the title and named owner insufficient. Inspect the source card to reveal the decisive cue, then check your answer.
Inspect the source job card — reveal the resolving cue
| Choose the receiving job | Hub | Owner | Evidence type |
|---|
Simulate the attribution gate
Use the source context above, or enter it manually to test a missing or contradictory cue. The gate compares these fields with the selected update’s supplied source record. A correct quiz answer alone does not supply the attachment context.
1–280 characters; content is carried as text. “Complete”, “ready” or “signed off” is the reported status, not verified work completion or safety approval. The fixture names an owner; it does not identify the reporter.
Demonstration map, not a supplied roster
For this exercise only: North → North launch crew; South → South launch crew. This assumes one launch crew per hub at the update’s event date. Cross-training or a changed assignment could invalidate that assumption.
No simulation has run.
In-tab simulation receipt
- Receipt / version
- Outcome
- Source update
- Job and hub
- Team
- Source owner / date
- Text carried
- What changed
- Only this in-tab preview. No operational record, file, notification, staffing assignment, approval or job status was changed.
- Correction / lifetime
- Edit the fields and simulate again to replace this preview with the next version. Repeating unchanged input reuses the same version. Reset or reload removes all previews.
Inspect this tab’s evidence trail
Keeps outcomes and correction versions only for this tab; this is not an audit log or durable history.
- No checks or simulations yet.
The rule is an explicit join, not a confidence score
IDs are compared after trimming spaces and lowercasing. The update text is trimmed but never interpreted as an instruction or used to choose the job. No fuzzy matching, probability, score threshold or automatic safety sign-off is claimed.
Make the real fast path short
- Open the job card or scan its unique reference. Pre-fill job and hub, showing both before submission.
- Resolve the team using the assignment valid at the event time. Keep the reporter separate from the responsible team.
- Show a compact “job · hub · team” confirmation. If anything is missing or contradictory, retain the draft and explain the hold.
- On a real service, return a durable receipt and a direct link to the same update. Use an update ID and revision checks to make retries safe.
Keep correction accountable
Store stable update ID, job ID, hub ID, team ID, reporter identity, event time, received time, source reference and assignment version. A changed attribution should preserve who corrected it, why and the previous link.
Those fields are a proposed production contract, not information present in this exercise. The supplied “Day 10–12” labels are retained as labels; they are not converted into timestamps or treated as proof that an assignment is current.
Evidence, answer key and limits
The ground truth for the answer check is benchmark 1.0.0 · taskFixtures.updates. All records are fictional.
| ID | task | title | hub | owner | date |
|---|---|---|---|---|---|
| u1 | s-gate | Gate replacement complete | South | Sam | Day 10 |
| u2 | n-tester | Tester calibration ready | North | Asha | Day 11 |
| u3 | s-induction | Induction signed off | South | Rae | Day 12 |
Authored confusables: n-gate / North / Sam, s-tester / South / Asha, n-induction / North / Rae. These are additional teaching records, not supplied evidence. Their work names and owners deliberately match their opposite-hub counterparts. Candidate work names are short labels derived from the update titles.
Why the cue works: in this six-record exercise, title plus owner leaves two candidate jobs. Hub narrows that pair to one; the stable job ID identifies it directly and the hub cross-check catches contradiction. This is a constructed ambiguity check, not a measured real-world reduction in errors. Hub alone leaves three jobs.
Acceptance checks and reproducible exercises
- Select u1 and choose
n-gate. Check the answer: it should reject North and showu1.task = s-gateas the decisive source cue. - Choose
s-gateand check again: the answer is correct. Inspect the source context and use it to attach the ID and hub. - Keep “Fixture only” and simulate: the outcome must be held because team evidence is absent, even with a correct job and hub.
- Choose the demonstration map, acknowledge its assumption and simulate: the outcome is provisional, with “South launch crew” clearly marked assumed.
- Change the attached hub to North and simulate: the contradiction must block a new preview. The previous receipt remains visible and is marked out of date.
- Correct back to South; unchanged input must reuse the existing receipt version. Edit the note and simulate to create a new preview version. Reset must return to u1, blank context and no receipt.
Limits: no real job registry, team roster, staff authentication, concurrent editor, network retry or persistence is tested. Exact fixture comparison cannot detect incorrect source data. Proposed production controls require separate operational and user testing. A matching identity does not establish that the reported work happened or that its sign-off is authorised.