Engineering inside Dispatch /

Interface and interaction architecture

D3 renders the saved assignment timeline in the workspace. Dashboard counts are scoped to the most recently updated plan so plan revisions do not inflate completed work.

A constraint-checked insertion heuristic

The scheduler considers job windows, technician shifts, skills, parts and supplied travel durations when building assignments. It returns explanations for work it cannot place and explicitly reports that global optimality is not established. This keeps the algorithm's claim aligned with what it actually computes and lets a dispatcher distinguish missing input from insufficient capacity.

Approval is tied to reviewed content

Records carry a version and content digest. Approval requires the current values, so reviewing one plan cannot silently authorise a later edit. Commit is a separate operation that produces local work orders. Unsupported external calendar targets return a configuration error rather than implying an event was created elsewhere.

Cross-plan checks happen at the write boundary

The server serialises workspace mutations through a revision check and bounded retry. Commit examines existing non-cancelled work orders as well as the current proposal. It rejects repeated job identities, overlapping technician assignments and adjacent stops whose supplied travel time will not fit. These checks protect against two individually valid plans becoming an invalid combined schedule.

Retries and workspace boundaries are explicit

The application has its own local D1 persistence. Reads and references are workspace scoped. Write requests require the expected version, appropriate role, origin and CSRF checks. Idempotency records fingerprint the actor, path, method and body; an exact replay returns the recorded result, while changing the payload under the same key is rejected.

Operating the product

Start with the public interface preview to explore overview and insights using example records. Open /dashboard for account-scoped metrics calculated from your saved records, or /desk for the underlying workflow.

Treat job identifiers as durable business references. Reusing an identifier for different work makes duplicate protection ambiguous; changing the identifier merely to bypass a conflict could create duplicate service visits.

When a version or commit conflict appears, reload the current plan and work orders before changing anything. Another operator may have committed valid work while the older screen was open. Review the resulting schedule, then make a new decision against the latest version.

Retry an uncertain request with the same operation key and unchanged payload. If the command already succeeded, its original result is returned. A changed decision should use a new key after inspecting the current state.

Investigate unassigned explanations in the input: add a missing directed route, correct a skill or stock assumption, or move the service window. Do not interpret a missing assignment as a notification sent to the customer or technician.

Keep local work-order evidence separate from external operating systems. Before relying on Dispatch for a real service day, define who updates the source roster, who approves changes and how a verified backup can be restored.

Independent by construction

Dispatch has its own application source, build configuration, local server, database, object store and session cookie. The fifteen applications reuse copies of a common foundation, but their operational data and credentials are independent. A shared dependency cache on this Mac saves disk space; each product includes a lockfile and a command to install its own dependencies.

Mutations validate the workspace and current record version. Approval binds the reviewed content digest; an idempotency key prevents an identical retry from becoming a second action. These controls are implemented in the server, alongside the product-specific rules described above.