Skip to content
ALIA Pipeline / 04Doc ALIA-PL-04 Rev AIN DEVELOPMENT

ConstraintForge

Field-service dispatch that replans the whole day in seconds when reality changes.

Category
Field-service dispatch
Model
SaaS
Core platform
ALIA Constraint Engine
Status
IN DEVELOPMENT

01 Problem

Field-service fleets plan a clean day at seven in the morning and watch it collapse by ten. An emergency call, a job that runs long or a missing part invalidates the whole plan, and dispatchers rebuild it by phone and memory.

The cost is technicians driving past jobs they could have taken and second visits that a better plan would have avoided.

02 Specification

This is the specification we are building toward. The status column shows what exists today.

  • Live schedule re-optimizationIN PROGRESS

    The day’s plan is re-optimized continuously as jobs complete, overrun or land, instead of once at dispatch.

  • Technician skill and certification constraintsPLANNED

    Work is assigned only to technicians who hold the certifications and skills the job legally and practically requires.

  • Van inventory as a hard constraintPLANNED

    A technician is never routed to a job that the parts in their van cannot finish.

  • Overtime and labor-rule compliancePLANNED

    Hours, breaks and overtime rules are enforced inside the optimizer instead of being discovered on the timesheet.

  • Emergency insertionPLANNED

    An emergency call is inserted into the running day with the minimum disturbance to everything already promised.

  • Travel-time and geography modelingPLANNED

    Drive times and territory are modeled so the plan reflects roads, not straight lines.

  • Explainable dispatch recommendationsPLANNED

    Every assignment carries the reason it was made, so dispatchers override with understanding instead of guesswork.

  • Offline-tolerant mobilePLANNED

    Technicians see their day, update jobs and capture completion with no signal, and everything reconciles when coverage returns.

  • First-time-fix analyticsPLANNED

    The system reports which constraints, parts gaps and assignments are driving repeat visits.

Updated as capabilities ship. BUILT means working and validated; nothing gets that label early.

03 System

  1. 01Jobs and emergencies
  2. 02Constraint model (skills, parts, hours)
  3. 03Re-optimizer
  4. 04Dispatch board and mobile
  5. 05Live replan
FIG. 01 ConstraintForge system architecture, stage by stage.

04 Engineering

Constraint core

ConstraintForge is built on the ALIA Constraint Engine. Skills, certifications, van inventory, labor rules and travel are expressed as hard constraints in one standing model, and re-optimization is incremental: an emergency call or an overrun perturbs the existing solution instead of resolving the day from scratch, which is what makes seconds achievable.

Explanation and override

Every recommendation carries the constraint trail that produced it, and dispatcher overrides are treated as input rather than error. The model absorbs the override and replans the rest of the day around it.

Deployment and integration

The optimizer runs as a service, and the mobile side is built offline-first so technicians in basements and rural coverage gaps keep working and reconcile when signal returns. Jobs, inventory and hours arrive from the systems the fleet already runs.

05 Why this is hard

The genuine problem is constraint-rich re-optimization in seconds under incomplete information. The optimizer never knows the true state of the day: jobs report late, van inventory drifts, and traffic does what it wants. The engineering work is a solver that commits to good decisions on partial data, revises them cheaply as the truth arrives, and never emits a plan that violates a certification, an inventory fact or a labor rule.

06 Design constraints

  • Replans the day in seconds
  • Certifications, parts and hours are never soft constraints
  • Mobile works with no signal
  • Every assignment carries its reason
  • Overrides are input, not errors

07 Design partner program

Design partner program.

We are looking for a small number of design and pilot partners. A partner gets the problem solved for their operation first, direct influence on the specification above, and pilot pricing. In exchange we get reality: real constraints, real data, real operators. No external partner is engaged on this product yet.