AI Rostering: Accept, Edit, Override — and Log Why
“The model proposes 94% occupancy. Exactly one thing is wrong with it.”
A planner board with an AI copilot: each week shows the proposal and four evidence objects to inspect; the planner accepts, edits (a real change) or overrides, cites the evidence and can flag data gaps. The debrief audits the REASONS: copy-paste reasoning, silent accepts and reflex overrides all cost; a corrected board with a specific reason scores highest.
The Audience
Planning and operations teams adopting AI scheduling — plus anyone designing human-in-the-loop processes.
Responsibilities
Constraint-violation design · reason-audit scoring · model-feedback framing — judgment as an auditable practice.
The Build
Scenario design · audit mechanics · AI-collaboration framing · AI-assisted drafting (disclosed)
How I used AI in this case
AI drafted schedule-proposal variants and reason-log phrasings; constraint-violation design, audit scoring and the human-in-the-loop framing were authored by me. Edited, verified and disclosed.
The build itself, not a video about it — open it, make the calls, and read what each one costs.
Roster Reset — Primary Build
The full planner: weekly proposals, violation seeding, reason-log audit, debrief
3D planning table
Inspect the route, contract cards, room calendar and attendance ledger on the table; then accept, edit (a pawn or group moves and occupancy changes) or override, cite the evidence and flag data gaps.
Scene-by-Scene Storyboard & UI Spec
Scene plan: weekly proposals, violation seeds, reason-log rounds, before build. Full branching dialogue, distractor rationales, and visual system tokens.
Why conventional training failed the operational reality
Four weeks, four different model failures — and one of them isn't a failure at all:
Full trust at 94% and manual override of everything are the same failure in opposite directions: neither leaves a trail the next planner — or the model — can learn from.
Core diagnostic finding
In this fictional brief the planners could use every button in the tool. What failed was the layer above it: proposals with a strong occupancy figure were accepted without checking what the model could not know (travel time, contract terms, last year’s no-shows), or were rebuilt by hand so the model never learned. The skill is inspecting, correcting in place and reporting the gap.
The AI must be nearly right
Illustrative premise: occupancy built on a trainer who cannot be in two cities — the model is blind to geography
Design Constraint → Build Rule: A copilot that is obviously wrong teaches nothing. Proposals had to be genuinely good — with one hidden constraint violation that only audit reasoning catches.
Auditing reasons, not clicks
Illustrative premise: sessions against a contract cap — the model is over-eager, a different disease
Design Constraint → Build Rule: The decision, the cited evidence and the flag are each scored; a reason that does not cite the deciding evidence earns nothing.
Judgment as practice
Design premise: the planner has to find the flaw in the evidence, not read it in the proposal
Design Constraint → Build Rule: The design treats AI collaboration as an auditable skill — a corrected board with a stated reason outranks a lucky accept.
The judgment layer on top of an AI rostering tool
Performance problem
In this fictional training provider, an AI tool proposes weekly trainer rosters. Planners either trust the occupancy figure or override by hand. Impossible schedules reached trainers twice last quarter, and the same pattern of regional no-shows repeated because nobody told the tool’s owner.
Learners and context
Planners and planning coordinators who use the tool daily. Confident with the interface, sceptical or over-trusting of the model depending on the person. A 10-minute run on four representative weeks.
Is training the answer? Not on its own
- Missing model data. Travel times between sites and last year’s attendance history should be inputs to the model. Recommended to the tool owner; the flag step rehearses the report, it does not fix the data.
- Feedback route. Planners need a place to send flags that someone reads, with an answer. Without it, flagging stops after a month.
- Occupancy targets. If planners are judged on occupancy alone, accepting 94% will always be rewarded. The target should include feasibility.
Alignment: every objective has practice, evidence, feedback and a route back to the job
| Objective | Practice | Assessment | Feedback | Transfer |
|---|---|---|---|---|
| LO1 Inspect the evidence the model cannot see before deciding | Four evidence objects per week; decisions locked until one is opened | Citing the deciding evidence scores 1 | Says whether you opened the deciding object at all | Pre-acceptance check: route, contract, rooms, history (proposed) |
| LO2 Choose accept, edit or override, and make the smallest real edit | Real edit options with occupancy effect | 2 / 1 / 0; accepting week 34 or 36 is critical | Per-edit explanation of feasibility and trade-off | Edit in the tool rather than rebuilding outside it |
| LO3 Report data gaps to the model’s owner | Flag option every week | Scored on the two blind-spot weeks | “The edit fixes the week; the flag fixes the model” | A real flag channel with a named owner (recommended) |
Evidence register: what is real, what is invented
- Fictional premise Certum Opleidingen, its trainers and its roster tool. The model is scripted scenario logic.
- Illustrative values Occupancy figures, the 90-minute route and the 22% no-show wave.
- Design decision The scoring and the two critical weeks.
- Not measured Planner behaviour or roster quality. Earlier claims of re-randomised weeks and copy-paste detection described features that did not exist; they were removed.
Measurable Performance Objectives
Three objectives. Reasons are now tied to evidence rather than word count (the earlier rule accepted any reason of four words).
Inspect the evidence the model cannot see — travel times, contract terms, room bookings, attendance history — before accepting a proposal.
Evidence in the build: citing the deciding evidence each week (1 point).
Accept, edit or override a proposal, making the smallest real edit that fixes the week.
Evidence in the build: the decision and edit (2 / 1 / 0); two critical weeks.
Report a data gap to the model’s owner when the model was blind rather than wrong.
Evidence in the build: the flag on weeks 34 and 40 (1 point each).
Why This Modality Won (Trade-Off Analysis)
Before committing to the final architecture, we evaluated and rejected lower-transfer alternatives against the workplace constraints:
The vendor's default onboarding. Rejected because the planners could already click every button — the failures were judgment failures (silent accepts, reflex overrides), and no feature tour builds the habit of writing down WHY. The buttons were never the gap.
Safe-sounding governance. Rejected because blanket approval without reasons is automation theatre: the model receives no signal, the planner learns nothing, and next month's 94% gets fixed by hand all over again. Edit-fixes-the-week; the flag fixes the model.
A planner board with an AI copilot: each week shows the proposal and four evidence objects to inspect; the planner accepts, edits (a real change) or overrides, cites the evidence and can flag data gaps. The debrief audits the REASONS: copy-paste reasoning, silent accepts and reflex overrides all cost; a corrected board with a specific reason scores highest.
Why hidden evidence
Make inspection the task
If the flaw is written in the proposal, the exercise tests reading. With four evidence objects and the flaw in one of them, it tests whether the planner looks, and where.
Why a clean week
Trust is also a decision
Week 38 is right. Accepting it on the record, with a note for facilities, is the counterweight to override-everything. A trainer that only rewards correction teaches distrust.
Why 3D here
Geography is the flaw
On the map, the route between Venlo and Eindhoven only draws when inspected, and three regional groups travelling three times is visible as three lines. The planner board looks perfect; the table around it does not.
Production Sequence & Traceable Artifacts
The stages below show how the artifacts depend on each other. In this fictional case one designer produced all of them.
What would tell us it worked
A proposed plan. Nothing below has been measured.
| Question | Measure / instrument | When | What we would do with the answer |
|---|---|---|---|
| Do planners inspect before accepting? | Objects opened per week and citation accuracy | Pilot with 6–8 planners | If week 40’s ledger is rarely opened, history needs to be visible in the real tool, not just in training |
| Do they edit rather than rebuild? | Share of edits vs overrides on weeks 34, 36 and 40 | Same pilot | High override rates suggest distrust worth discussing with the tool owner |
| Do flags reach the model? | Flags received by the tool owner and the share acted on | Three months | Without acted-on flags, stop asking planners to send them |
| Do infeasible rosters still reach trainers? | Roster changes requested by trainers after publication | One quarter before and after | Credit model data changes and planner checks separately |
Instructional Design Takeaway
“Why this form wins: the problem is uncalibrated trust with no trail, so the solution requires the reason on every accept, edit and override — and scores the audit trail, because the loop is a log.”
The AI planning rollout had no failure mode for trust: some planners accepted 94% occupancy rosters blindly, others overrode everything and the model never learned. The missing layer was judgment WITH an audit trail. The proposal was a planner board with an AI copilot: four weeks, one hidden constraint flaw each, and a required reason log — with the debrief auditing the reasons, not the choices, because the log is what the next planner and the model owner inherit.
Transparent Portfolio Scope
Honest limitation: four scripted weeks and a stylised map. Real rosters have more constraints than four evidence objects, and the “AI” here does not learn from flags.