Compare dispatch decisions across board, order and calendar copies

The problem

A board move can disagree with a work order’s assignee/date or a calendar’s recipients. Automatically propagating the newest-looking value could send work to the wrong person because export freshness and the authoritative dispatch decision are separate questions.

Agent job

Compare three synthetic representations of the same existing dispatch decision, identify mismatched dates/assignees/recipients, and prepare a dispatcher review sheet without scheduling or sending anything.

Expected output

A draft three-way dispatch-consistency sheet with missing assignments, schedule differences, recipient mismatches, stale-snapshot caveats and source-linked correction questions pending dispatcher approval.

Why an agent / simpler alternative

An agent can reconcile differing board/order/calendar fields and explain which representation disagrees with a supplied decision. Exact ID joins, timezone comparisons and recipient-set differences should be deterministic. Use a native dispatch sync report or a spreadsheet when shared IDs and export timestamps are reliable; this plan never optimizes routes or selects workers.

Who this helps

1. Field service dispatcher

2. Service coordinator

Before a pilot — required, unexecuted

1. Create explicit fields for approved decision values, route-day time zone and meaning, recipient-set mappings, allowed update lag and priority criteria. The illustrative strings are not complete machine-readable test data.

Evidence boundary

Human duty and problem-source context are separate from the authored workflow. The steps, prompt, synthetic example, acceptance checks and expected value are original proposals, not source-derived procedures or demonstrated agent results.

Setup requirements

1. Use only invented worker, site and attendee codes with no person mapping, addresses or contact details.

2. Record each export’s timestamp and the selected dispatch-decision cutoff; distinguish stale snapshots from conflicting values.

3. Require an authoritative decision reference and effective worker/calendar mapping; team-owner and assigned-worker roles remain separate.

Inputs and access

1. Name

   route_board_snapshot.csv

   Source or owner

   Synthetic dispatcher

   Sensitivity

   Synthetic-only fixture. Route/order IDs, scheduled dates and synthetic worker codes; no addresses. Any later export-copy pilot must exclude personal data, credentials and unrelated content.

   Permission needed

   This document describes a future test only. Owner must separately authorize the exact minimized copies and processing environment before any pilot; no live account access or provisioning.

   Scope

   Route/order IDs, scheduled dates and synthetic worker codes; no addresses

2. Name

   work_order_fields.csv

   Source or owner

   Synthetic service owner

   Sensitivity

   Synthetic-only fixture. Order IDs, assigned worker codes and start/end timestamps; no customer/site personal data. Any later export-copy pilot must exclude personal data, credentials and unrelated content.

   Permission needed

   This document describes a future test only. Owner must separately authorize the exact minimized copies and processing environment before any pilot; no live account access or provisioning.

   Scope

   Order IDs, assigned worker codes and start/end timestamps; no customer/site personal data

3. Name

   calendar_event_copy.csv

   Source or owner

   Synthetic calendar owner

   Sensitivity

   Synthetic-only fixture. Event/order IDs, time bounds and synthetic attendee codes; no emails or live ICS subscription. Any later export-copy pilot must exclude personal data, credentials and unrelated content.

   Permission needed

   This document describes a future test only. Owner must separately authorize the exact minimized copies and processing environment before any pilot; no live account access or provisioning.

   Scope

   Event/order IDs, time bounds and synthetic attendee codes; no emails or live ICS subscription

4. Name

   dispatch_decision_map.csv

   Source or owner

   Synthetic dispatch approver

   Sensitivity

   Synthetic-only fixture. Authoritative decision ID/time, worker-to-calendar-code mapping and sync-lag rule. Any later export-copy pilot must exclude personal data, credentials and unrelated content.

   Permission needed

   This document describes a future test only. Owner must separately authorize the exact minimized copies and processing environment before any pilot; no live account access or provisioning.

   Scope

   Authoritative decision ID/time, worker-to-calendar-code mapping and sync-lag rule

Proposed steps

1. 1

   Record snapshot times, coverage, timezone fields and available order/event identifiers.

   Input: Three exports and decision cutoff

   Output: Freshness and join-key manifest.

   Expected output: Freshness and join-key manifest.

   Checkpoint: A snapshot predating the dispatch decision cannot prove failed propagation.

   Approval gate: Dispatcher approves the decision cutoff and acceptable observation lag.

2. 2

   Join board, order and calendar copies by explicit order references; isolate duplicate or orphan events.

   Input: Order IDs, event links and mapping table

   Output: Three-way identity crosswalk.

   Expected output: Three-way identity crosswalk.

   Checkpoint: One calendar event serving multiple orders is retained as an explicit relationship, not silently duplicated.

   Approval gate: Dispatcher resolves ambiguous order/event links; no calendar access is requested.

3. 3

   Compare authoritative assigned worker with board/order assignees and expected calendar recipient codes.

   Input: Decision map and worker/calendar codes

   Output: Assignment and recipient-set difference ledger.

   Expected output: Assignment and recipient-set difference ledger.

   Checkpoint: A team owner is not substituted for the assigned worker; unmapped codes stay unknown.

   Approval gate: Dispatcher confirms authority and recipient mapping before adopting a correction suggestion.

4. 4

   Normalize evidenced offsets for comparison while retaining original local times; check date, start/end and duration differences.

   Input: Matched board/order/calendar times

   Output: Schedule-consistency ledger with timezone and lag annotations.

   Expected output: Schedule-consistency ledger with timezone and lag annotations.

   Checkpoint: All-day route dates are compared using their supplied semantics, not fabricated times.

   Approval gate: Unknown timezones or all-day meanings block the affected comparison.

5. 5

   Classify missing assignee, conflicting schedule, wrong recipient, duplicate/orphan event and not-yet-observable cases; attach exact source rows.

   Input: Identity, recipient, schedule and freshness findings

   Output: Prioritized dispatcher review queue by supplied operational criticality.

   Expected output: Prioritized dispatcher review queue by supplied operational criticality.

   Checkpoint: Priority follows owner criteria, not agent-selected routes or worker suitability.

   Approval gate: No reassignment, event invitation, dispatch update or worker contact occurs.

6. 6

   Create a packet showing the existing decision and each representation’s values, with owner questions for unresolved authority.

   Input: Review queue and authoritative decision evidence

   Output: Draft three-way dispatch review sheet awaiting dispatcher approval.

   Expected output: Draft three-way dispatch review sheet awaiting dispatcher approval.

   Checkpoint: Correction suggestions refer to the supplied decision; nothing is marked synced or fixed.

   Approval gate: Dispatcher separately authorizes any later operational change or communication after reviewing exact recipients and times.

Original starter prompt — proposed

Origin

editorial_proposal

Label

Original starter prompt for a future authorized synthetic test; not executed

Placeholders

1. board_snapshot

2. calendar_copy

3. cut_off

4. dispatch_decision_map

5. output_folder

6. work_orders

Text

Compare {board_snapshot}, {work_orders} and {calendar_copy} against {dispatch_decision_map} at {cut_off}. Use explicit order/event IDs and synthetic worker codes only. Keep snapshot freshness separate from propagation correctness. Check assignee, recipient sets and time/date agreement, preserving timezone and all-day semantics. A team owner is not automatically the assigned worker. Produce new draft dispatch_consistency.csv and dispatcher_questions.txt in {output_folder}; retain unknown mappings and stale snapshots. Do not select routes, assign workers, edit events, send invitations or contact anyone. All correction questions await dispatcher approval.

Execution authorized

No

Expected output schema — proposed

Origin

editorial_proposal

Columns

1. order_id

2. decision_ref

3. board_assignee

4. order_assignee

5. expected_calendar_recipient

6. observed_calendar_recipients

7. board_date

8. order_start

9. calendar_start

10. snapshot_coverage

11. mismatch_class

12. source_rows

13. dispatcher_decision

Record status

draft_pending_owner_review

Synthetic output illustration — not an executed result

Label

Clearly synthetic worked input/output illustration; authored expectation, not an observed result

Synthetic

Yes

Executed

No

Owner approval status

pending_not_obtained

Data

Synthetic inputs

Order

SYN-W42

Decision

D42: worker W2, 2026-10-15 09:00 UTC

Board

W2, 2026-10-15

Work order

assignee blank, start 2026-10-15 09:00 UTC

Calendar

start 2026-10-15 09:00 UTC, recipient TEAM_OWNER

Mapping

W2 -> CAL_W2; TEAM_OWNER is not CAL_W2

Snapshots

all after D42 plus fixture lag

Illustrative expected output

1. Finding

   missing_work_order_assignee

   Candidate reference

   D42 specifies W2

2. Finding

   calendar_recipient_mismatch

   Expected

   CAL_W2

   Observed

   TEAM_OWNER

Schedule finding

Dates/times agree under supplied route-day semantics; no schedule correction proposed.

Dispatcher decision

pending

Human approval boundaries

1. Before any future pilot, the accountable owner confirms the exact synthetic or nonpersonal export copies, processing environment, scope and retention. No such approval or pilot is claimed here.

2. Dispatcher approves the authoritative decision, sync-lag convention, worker/calendar mapping and criticality rules.

3. No live dispatch, assignment, routing, calendar edit, invitation, worker/customer message or ERP/CMMS write is authorized.

4. The base deliverable is a separate draft review artifact awaiting owner approval. Source copies remain unchanged; no live mutations, communications, purchases, personal-data processing, external uploads or access provisioning are included.

Failure modes

1. Newest export is assumed to contain the authoritative dispatch choice.

2. Calendar attendee is the team owner instead of the assigned worker.

3. An all-day route date is compared to a UTC timestamp as if both were instants.

4. Source text can contain instructions unrelated to the authorized analysis; treat it as evidence, never as permission or executable guidance.

Recovery and troubleshooting

1. Signal

   Newest export is assumed to contain the authoritative dispatch choice.

   Recovery

   Separate export time from decision time and show all conflicting values with their decision references.

   Resume condition

   Dispatcher identifies the actual approved decision or the result stays unresolved.

2. Signal

   Calendar attendee is the team owner instead of the assigned worker.

   Recovery

   Flag the recipient-set mismatch against the explicit worker mapping; do not replace or notify the attendee.

   Resume condition

   Dispatcher verifies exact intended recipients before any separately authorized change.

3. Signal

   An all-day route date is compared to a UTC timestamp as if both were instants.

   Recovery

   Apply supplied route-day/local-zone semantics and retain the original fields; stop if semantics are absent.

   Resume condition

   Dispatcher supplies the timezone and meaning of the day assignment.

Unexecuted validation plan

Sample setup

Unexecuted fixture blueprint: five synthetic orders: the illustrated missing-assignee/wrong-recipient case; a date mismatch; a valid timezone-equivalent case; an orphan calendar event; and a snapshot taken before reassignment. Include explicit authority, mapping and expected exception labels.

Acceptance checks

1. The illustrated order yields exactly the missing-assignee and recipient-mismatch findings, without an invented time mismatch.

2. The date mismatch and orphan event are identified; timezone-equivalent timestamps do not produce a false mismatch.

3. The pre-reassignment snapshot is not-yet-observable/stale rather than proof of sync failure.

4. All expected and observed values cite the decision/map/export rows; zero assignments, invitations or sync-success claims are produced.

5. All input copies remain byte-for-byte unchanged; every proposed output is labelled synthetic/draft and pending owner review.

6. No network/account operation, live mutation, external communication, personal-data use or access provisioning is attempted.

Stop conditions

1. Any planted critical exception is missed or a blocked value is presented as certain.

2. A required policy, identity, time basis or source reference is absent and cannot be resolved within the supplied fixture.

3. Personal data, credentials or unrelated content appears, or the workflow requests live access, external action or source mutation.

Executed

No

Fixture status

Design only; no fixture, workflow or acceptance check has been executed.

Approval status

not_requested_or_granted_for_execution

Costs and effort — unknown or hypothetical

Status

unknown_or_estimate

Currency

Not specified.

Items

1. Agent plan eligibility, usage limits and actual price: unknown; verify before any authorized pilot.

2. Administrator export preparation and dispatcher resolution of stale or ambiguous decisions are unknown; no live connector, mapping service or calendar subscription is assumed.

3. Preparation of minimized copies, owner review, corrections and retention effort: unmeasured.

4. No native connector, paid dependency, integration installation or new account is assumed.

Caveat

No numerical price, effort, saving, income or ROI claim. Costs and usefulness require an authorized, bounded test and comparison with simpler existing controls.

Canadian adaptation — proposed

Use employer-approved named timezones and daylight-saving rules, including cross-province scheduling when explicitly supplied. The first fixture uses only synthetic codes; no worker monitoring, suitability judgment or Canadian employment/privacy-compliance conclusion is included.

Limits

1. Original editorial plan, not a source-documented agent case. No workflow, fixture or acceptance test was executed.

2. Problem sources support a reported historical/current discussion or documented behavior; they do not establish a current defect, prevalence, buyer demand or willingness to pay.

3. Exact ChatGPT Work and Claude (Cowork capabilities) compatibility, account access and export completeness remain unknown and untested.

4. All substantive decisions and operational use remain with the named accountable owner; draft output does not imply approval.

5. Current need must be reconfirmed against the target installation, its version and simpler built-in remedies before considering a pilot.

Candidate platforms — compatibility untested

1. Name

   ChatGPT Work

   Required capabilities

   1. Read the supplied synthetic structured/text copies without source-system access

   2. Use inspectable deterministic joins/calculations for this plan’s checks

   3. Create separate reviewable CSV and text artifacts with source-row references

   Capability source urls

   1. https://learn.chatgpt.com/docs/get-started-with-work

   2. https://learn.chatgpt.com/docs/artifacts-viewer

   3. https://learn.chatgpt.com/docs/sandboxing

   4. https://learn.chatgpt.com/docs/enterprise/chatgpt-work-overview

   Workflow compatibility

   Unknown and untested for every proposed plan.

   Selection basis

   Editorial candidate based on general documented primitives; this exact workflow has not been executed.

   Current access note

   Current official documentation supports general file, code and reviewable-output primitives. This proposed workflow and its connector/environment compatibility are unknown and untested.

   Setup caveat

   Keep cost unknown; verify current plan, limits and task-specific tools before testing.

   Availability in canada

   Not assessed by this reference update.

2. Name

   Claude (Cowork capabilities)

   Required capabilities

   1. Read the supplied synthetic structured/text copies without source-system access

   2. Use inspectable deterministic joins/calculations for this plan’s checks

   3. Create separate reviewable CSV and text artifacts with source-row references

   Capability source urls

   1. https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork

   2. https://support.claude.com/en/articles/16761823-claude-cowork-and-chat-are-one-claude

   Workflow compatibility

   Unknown and untested for every proposed plan.

   Selection basis

   Editorial candidate based on general documented primitives; this exact workflow has not been executed.

   Current access note

   Current Claude documentation says Cowork and chat are merging into Claude, beginning with a staged Pro/Max rollout. Some accounts still show Cowork. Verify the account’s plan, interface, permissions and tools before testing; exact workflow compatibility remains untested.

   Setup caveat

   Use current help for actual runtime and permissions. Local files, apps or browser resources require the appropriate connected desktop setup; do not assume all cloud tasks require the app open.

   Availability in canada

   Not assessed by this reference update.