Production system Case studyLive, capturingPrivacy scoped

Dispatch Understudy: Turning Expert Scheduling Judgment Into Reviewable Rules

A narrow, opt-in capture that observes how an expert dispatcher schedules an ordinary day and turns that judgment into explicit rules a booking assistant can follow, so the knowledge stops being tribal and starts being reviewable.

Schedulingactions only, nothing elseMaskedcustomer identifiers removed at ingestStays insideno third-party model or vendorProposesnever acts, never books

The problem

You cannot interview your way to the rule someone actually uses.

  • The best scheduling decisions in a field-service business are made by one or two experienced people, in seconds, using rules they have never written down and could not fully state if asked.
  • Interviewing them does not recover it. People sincerely describe the rule they believe they use, which is rarely the rule they actually apply under pressure at 4pm on a Friday.
  • Without that ground truth, an automated booking assistant is built on assumptions and, worse, has no honest way to be scored. It can be confidently and consistently wrong and nothing in the system would notice.

The solution

Observe the decision, mask the person, propose a rule, let a human promote it.

A companion capture records scheduling actions, and only scheduling actions, during defined sessions on an ordinary shift. Running it with the knowledge of the person being observed is a condition of use rather than a courtesy. Customer identifiers are masked before anything is stored, and everything stays on company-controlled infrastructure.

Repeated patterns are reduced to candidate rules stated in plain language: what was true at the time, and what the dispatcher did about it. A person reviews each candidate and decides whether it becomes a production rule. The same record is the scoring set, so the booking assistant's proposals can be compared against what the expert actually did.

What this is, and what it was built not to becomeThis is an expertise-capture tool. It was deliberately scoped so that it cannot be repurposed into a monitoring tool, because the capability to do so was never built into it.

Scope and privacy

The boundaries were set before the first line was written.

This section is the design, not a policy statement written afterwards.

What it does

  • Captures scheduling actions inside one tool, and nothing else.
  • Masks customer identifying data at ingest, so what is retained describes the shape of a decision rather than a person.
  • Keeps every captured record on company-controlled infrastructure.
  • Runs only in defined sessions, for a stated purpose, and only with the knowledge of the person being observed. That is a condition of use, not a courtesy.
  • Produces candidate rules in plain language, for human review.
  • Serves as the ground-truth set used to score the booking assistant and to find its blind spots.

What it does not do

  • Does not log keystrokes, screen contents, or any activity outside the scheduling workflow.
  • Does not measure, rank, score, or report on an individual's performance.
  • Does not retain customer personal data.
  • Does not send anything to a third-party model, vendor, or external service.
  • Does not act. It never books, changes, reschedules, or cancels anything.
  • Does not run continuously. It is scoped to defined capture sessions.
Why the constraints came first

The scope, the masking, and the stays-inside rule were decided before any capture was built, not retrofitted after someone raised a concern. That ordering is the reason the tool cannot quietly become something else: there is no general capture capability sitting behind a configuration flag, because none was ever written.

How it works

Six steps from an observed action to a rule in production.

ScopeNarrow by construction

The capture is bound to scheduling actions in a single tool. There is no general screen or keystroke capture to switch on, because it does not exist in the codebase.

MaskIdentifiers removed at ingest

Customer identifying fields are masked before storage. The retained record preserves the decision shape, such as trade, distance band, and time of day, and discards who it happened to.

StoreCompany-controlled, full stop

Captured actions land in a data store the company owns and controls. No third-party model, analytics vendor, or external service is in the path at any point.

ExtractActions become candidate rules

Repeated patterns are reduced to candidate rules written in plain language, in the form of what was true and what the dispatcher did, so a non-engineer can read and argue with them.

ReviewA person promotes, or does not

No candidate becomes a production rule without human review and approval. The tool proposes. It has no authority to decide what the business believes.

ScoreGround truth for the assistant

The booking assistant's proposals are compared against what the expert actually did. This is how the assistant's blind spots were found, and it is the only honest measure available.

01Opt-in sessionDefined window, participant informed
02Scheduling actionsOne tool, one workflow, nothing else
03Mask identifiersCustomer data removed before storage
04Company-owned storeNo third party in the path
05Candidate rulesPlain language, arguable by a non-engineer
06Human reviewA person promotes or rejects each rule
07Live rulesetFeeds the call-time booking assistant
Two of the seven steps exist purely to constrain what the system is allowed to know.

Why it matters

This is the part that decides whether the automation is trustworthy.

The rule described is not the rule applied

An expert's stated rule and their revealed rule are different rules. Observation recovers the second one, and the second one is what the business actually runs on.

An assistant tuned only against itself

Without an independent record of expert behavior, an automated scheduler has no external reference. It optimizes toward its own assumptions and drifts confidently. This capture is that external reference.

Succession, written down

The secondary outcome matters as much as the primary one. Judgment that lived in one person's head is now written down, reviewable, and arguable. That is a continuity asset for the business regardless of what any model does with it.

What it demonstrates

The skills behind the system.

Expertise capture and knowledge elicitationPrivacy-by-design data collectionPII masking at ingestRule extraction from observed behaviorHuman-in-the-loop rule promotionGround-truth evaluation set constructionScoped, non-continuous captureData residency and third-party exclusionBrowser-extension instrumentationAutomation scoring and blind-spot discoveryDesigning a tool that cannot be repurposed

Outcome

Judgment out of one head, into a reviewable ruleset.

The scheduling judgment that used to live with one person is now written down, reviewable, and used to score the system that depends on it. The capture is narrow, opt-in, masked, and stays on company systems, and those properties are structural rather than promised.