Field service readiness expires

A repair visit is booked, but the technician's truck carries the wrong kit. The correct part exists at a depot. The schedule looks complete. Someone still needs to establish whether the technician can arrive with the right equipment, valid qualifications and confirmed access.

The field-service readiness workbench brings those prerequisites into one dispatcher review. It explains what is missing and which records support the answer. It also handles the awkward part of readiness: a visit that was ready ten minutes ago may no longer be ready now.

Editorial archive date: 1 October 2026. This article was updated on 24 October using later October implementation and evaluation evidence; those results were not produced on the archive date.

A reservation does not put a part on the truck

The synthetic demonstration follows work order WO-1001 for asset PR-204. The assigned truck has KIT-A; the visit requires KIT-B. Owning KIT-B somewhere in the company does not satisfy the job. The rules require the exact compatible part physically on the assigned truck, in sufficient quantity, with a reservation for this work order.

The dispatcher also needs an approved plan for the asset's revision, qualifications covering the whole visit, a usable booking and customer access. Missing, stale, forbidden and conflicting evidence stay separate. Each points to a different next action.

The demo then records KIT-B received and reserved. The worker reassesses the case, and the dispatcher releases that exact assessment. When a later stock withdrawal removes KIT-B, the release is invalidated and the case becomes blocked again.

The demo after a stock withdrawal: the current blocker and earlier invalidated release remain visible together. Real framed capture from 23 October, using synthetic data and rules mode. The lab clock is fixture time.

Approval belongs to an assessment with an expiry

An assessment records its source versions, policy, prerequisite results and expiry. The dispatcher approves one exact assessment hash and case revision. The API rechecks those details under the case lock before committing the release.

This handles more than edits to records already seen. A newly relevant booking can create a conflict; a policy change can alter the answer; elapsed time can make an unchanged observation too old. The release inherits the assessment's expiry. Clicking approve does not refresh the evidence.

flowchart TD
  A[Read parts, people, booking and access records] --> B[Assess prerequisites and expiry]
  B --> C{Ready for dispatcher review?}
  C -->|No| D[Explain blockers and request evidence]
  D --> A
  C -->|Yes| E[Approve the exact current assessment]
  E --> F[Record local release]
  F --> G[Source or policy changes, or evidence expires]
  G --> H[Invalidate release and reassess]
  H --> A

These transactions coordinate the workbench's stored observations. They do not lock a warehouse or an external scheduling system. The repository has no live or replayed operational connector. Its release is an administrative decision inside the demonstration, not an actual technician dispatch or safety clearance. Implemented architecture

Let the agent investigate the blocker

The optional Claude investigator runs through LangGraph. It reads scoped evidence, prepares a cited brief and suggests requests, such as asking the warehouse for the missing receipt. It cannot set readiness, release a case or send a message.

Briefs use typed claims checked against required reads and the trusted assessment. An answer to a request must become an authoritative source observation and be assessed before it can satisfy a prerequisite.

The shipped no-key demo uses a scripted baseline. This framed detail shows the evidence interface, not a paid model result.

The evaluation exposes the tradeoff. In an early twelve-scenario comparison, Sonnet wrote one ready-looking brief after skipping a forbidden access document. The deterministic engine still blocked the visit. Required-read and typed-claim checks were then added.

In the later six-case comparison, Sonnet and Haiku each produced three accepted grounded briefs from six attempts. The remaining Sonnet runs stopped for unsupported claims or cost limits; Haiku stopped for an unsupported claim or malformed output. No misleading result was displayed in that run. Each case had one attempt with no retry. Both the prompt and cases changed from the preceding comparison, so this is not a controlled improvement measurement. Agent evaluation

What is demonstrated, and what remains open

The committed evidence reports 4,071 passing assertions across 189 synthetic scenarios, including eleven process-kill recoveries, with zero false-ready results or unauthorized releases in that suite. That tests the specified workflow boundaries; it does not establish real-world dispatch accuracy. Evidence and reproduction commands

The public repository packages Next.js, Fastify and a pg-boss worker in one application container beside PostgreSQL. The measurements and screenshots predate that fresh public snapshot. No dispatcher has validated its usefulness. Backup and restore are unproven, and investigations do not resume midway. Recovering interrupted model spending still needs an operator; appending to a legacy cost file can invalidate a recorded reconciliation link.

The experiment walkthrough is a shorter introduction. A useful next trial would ask a dispatcher to find and resolve a missing prerequisite using this workbench, then compare the effort with their existing checklist. The agent earns its place only if investigation becomes easier while the basis of the release remains clear.