Technician Assignment Algorithms

Deciding which technician goes to which tower, in which order, is the point where a compliance program either holds its inspection cadence or quietly falls behind. The assignment engine is the decision core inside the broader Intelligent Inspection Scheduling & Technician Routing architecture: the scheduling layer decides when a site is due, and the assignment layer decides who is dispatched and whether that dispatch is even legal, safe, and contractually sound. It ingests structured work orders tagged with regulatory urgency, matches them against a certified crew whose skills and daily capacity are finite, filters out anything a weather gate forbids, and emits dispatch-ready assignments with an explicit, logged fallback whenever no valid match exists. Municipal compliance teams rely on it to prove inspection cadence adherence, lease managers use it to avoid contractual penalties, and the Python automation engineers who maintain the pipeline need every decision to be reproducible from an audit record months after the fact.

The Core Challenge #

Assignment in this niche is not a load-balancing problem — it is a constrained-feasibility problem where most candidate pairings are simply illegal. A work order for a guy-wire tensioning inspection on a 320-foot guyed tower cannot be handed to a technician who lacks a current authorized-climber certification, no matter how close they are or how empty their day is. FAA obstruction-lighting checks, TIA-222-H structural inspections, and RF grounding verifications each demand a different certification, and each certification has an expiry date that must be valid on the dispatch date, not merely on file. Overlay lease service-level windows, municipal quiet-hour curfews, per-technician daily capacity, and hard environmental safety gates, and the space of valid assignments for a given order is often a handful of people — sometimes zero.

The concrete failure scenario is a silent mis-dispatch. Suppose site TWR-4471 is due for a TIA-222-H structural audit with a lease SLA deadline of the 30th. A naive nearest-available assigner picks technician TECH-118 because they are geographically closest, without checking that their authorized-climber certification lapsed six days earlier. The technician arrives, cannot legally climb, the visit is logged as completed against the wrong scope, and the lease deadline passes with no valid inspection on record. The penalty clause triggers, and a post-incident audit finds no trace of why the assignment was made. The engine on this page is built to make that impossible: certification validity is a hard gate evaluated at dispatch time, every accepted and rejected pairing is scored transparently, and an order that has no feasible technician is routed to a logged fallback queue rather than forced onto whoever is nearest.

Data Model & Schema #

Assignment logic is only trustworthy if its inputs are strongly typed and its constraints are checked at construction time. Three canonical records drive the engine: the work order to be dispatched, the technician who might take it, and the immutable assignment result the engine emits.

A technician carries the counterpart of that contract — the certifications they actually hold with expiry dates, their remaining capacity for the day, and their current position:

from dataclasses import dataclass, field
from datetime import date, datetime
from enum import IntEnum

class PriorityTier(IntEnum):
    CRITICAL = 100   # federal safety mandate / active fault
    HIGH = 75        # lease SLA at risk
    STANDARD = 50    # routine regulatory cadence
    LOW = 25         # discretionary maintenance

@dataclass(frozen=True)
class Technician:
    tech_id: str                       # TECH-118
    certifications: dict[str, date]    # cert_code -> expiry date
    coordinates: tuple[float, float]
    remaining_capacity: int            # jobs left in the shift
    on_shift: bool = True

Certifications are stored as a code-to-expiry mapping rather than a flat set precisely because “holds the certification” and “holds a currently valid certification” are different questions, and the second is the one that keeps a dispatch legal. Keeping the expiry inside the record lets the engine evaluate validity against the order’s dispatch date without a second lookup, and it keeps the failure mode — an expired but on-file certification — inside the data model where a test can pin it.

Algorithmic Approach #

The engine treats assignment as feasibility-filtering followed by deterministic scoring. For each work order it first eliminates every technician who fails a hard constraint — off shift, at zero capacity, missing a required certification, or holding one that has expired — then scores only the survivors and selects the highest-scoring feasible technician. Scoring is a weighted sum: regulatory exposure (the order’s priority tier and how close its deadline is) dominates, with proximity acting as a tie-breaker so that among equally-urgent, equally-qualified crew the nearest is chosen. This ordering matters. Proximity must never be allowed to override a hard gate, or the engine reproduces the nearest-available mis-dispatch described above.

Conflict resolution among competing orders follows a strict regulatory hierarchy: federal safety mandates (CRITICAL) preempt lease SLAs (HIGH), which preempt routine municipal cadence (STANDARD / LOW). Aging orders escalate as their deadline approaches, so a STANDARD order two days from its due date can out-score a HIGH order with a month of slack. Weather is not part of the score at all — it is a gate evaluated before scoring, because a site that fails the wind or lightning threshold is not a lower-priority assignment, it is a forbidden one until conditions clear.

The end-to-end control flow — intake, priority scoring, the weather gate, deadline validity, feasible-crew selection, and the fallback path when no valid technician exists — is shown below.

Figure: constraint filtering, safety gating and scored selection for technician assignment.

Once a technician is selected, ordering the multiple sites in that technician’s shift into an efficient drive path is a separate optimization handled in Optimizing technician routes for multi-site maintenance windows, which takes the day’s confirmed assignments as its input. Assignment answers who; routing answers in what order.

Validation & Compliance Gates #

An assignment is not committed until it clears three gates in sequence, and each gate has an explicit outcome rather than a silent skip. The first is the environmental safety gate: if the site exceeds the configured wind-velocity limit or falls within a 10-mile lightning radius, the order enters a conditional hold and re-enters the queue with its original regulatory timestamp intact once telemetry confirms safe conditions. The threshold values themselves are owned by Weather Window Optimization; the assignment engine only consumes the resulting weather_safe verdict, so a change to climb-safety policy never requires touching assignment code.

The second gate is deadline validity. An order whose regulatory deadline has already passed is not dispatched to a technician who cannot possibly restore compliance; it is deferred, logged as an expired-deadline event, and routed to fallback so a compliance officer sees it explicitly. The third gate is crew feasibility — the certification-validity and capacity filter described above. When all three gates pass but no technician survives feasibility filtering, the order is not dropped: it is routed to a deterministic fallback queue with a generated fallback identifier, and the reason is recorded. Fallback is a first-class routing outcome, not an exception path, because “no one qualified is available today” is an operational fact a lease manager must be able to see and escalate, not a bug to be swallowed. The cadence thresholds that decide how aggressively an aging order escalates before it exhausts feasible crew are tuned in Frequency Logic & Threshold Tuning.

Integration Points #

Assignment sits in the middle of the scheduling graph and rarely runs in isolation. Upstream, Frequency Logic & Threshold Tuning decides which sites are due and at what priority, feeding work orders in with their deadlines already computed; the concrete cadence math for that upstream stage is worked through in Dynamic Inspection Frequency Calculation Based on Tower Age and Load. In parallel, Weather Window Optimization supplies the weather_safe gate result, and the live NOAA feed integration behind that verdict is detailed in Integrating NOAA Weather APIs for Safe Tower Climb Scheduling.

Downstream, the confirmed assignments this engine emits become the input set for Optimizing technician routes for multi-site maintenance windows, which sequences each technician’s day. The implementation below is written to make those handoffs clean: it consumes the weather gate as a plain boolean, emits a structured, audit-hashed assignment record that the routing layer can order directly, and never reaches back into the scheduling or weather layers for state.

Python Implementation #

The following engine implements the three-gate model: it filters technicians by shift, capacity, and certification validity, scores the survivors by regulatory exposure with proximity as a tie-breaker, and emits an immutable assignment record. Every accepted dispatch and every fallback is written to a structured audit log, failures raise a dedicated exception type so pipeline errors are distinguishable from ordinary Python errors, and each result carries a SHA-256 audit hash computed over its canonical payload for tamper-evident traceability.

import hashlib
import json
import logging
from dataclasses import dataclass, asdict
from datetime import date, datetime, timezone
from enum import IntEnum
from typing import Optional

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s | %(levelname)s | %(name)s | %(message)s",
    handlers=[logging.FileHandler("assignment_audit.log"), logging.StreamHandler()],
)
audit = logging.getLogger("compliance.assignment")

class PriorityTier(IntEnum):
    CRITICAL, HIGH, STANDARD, LOW = 100, 75, 50, 25

class AssignmentError(Exception):
    """Raised when an order cannot be assigned and must be routed to fallback."""

@dataclass(frozen=True)
class WorkOrder:
    order_id: str                      # WO-004471
    site_id: str                       # TWR-4471
    priority: PriorityTier
    deadline: datetime                 # tz-aware UTC
    required_certs: frozenset[str]     # {"climb_auth", "tia222"}
    coordinates: tuple[float, float]
    weather_safe: bool = True

@dataclass(frozen=True)
class Technician:
    tech_id: str                       # TECH-118
    certifications: dict               # cert_code -> expiry date
    coordinates: tuple[float, float]
    remaining_capacity: int
    on_shift: bool = True

class TechnicianAssignmentEngine:
    def __init__(self, dispatch_day: Optional[date] = None):
        self.dispatch_day = dispatch_day or datetime.now(timezone.utc).date()

    def _feasible(self, order: WorkOrder, tech: Technician) -> bool:
        if not tech.on_shift or tech.remaining_capacity <= 0:
            return False
        for cert in order.required_certs:                 # hard certification gate
            expiry = tech.certifications.get(cert)
            if expiry is None or expiry < self.dispatch_day:
                return False                              # missing or lapsed
        return True

    def _score(self, order: WorkOrder, tech: Technician) -> float:
        days_left = max((order.deadline - datetime.now(timezone.utc)).days, 0)
        urgency = order.priority.value + max(0, 30 - days_left) * 2   # escalate as deadline nears
        dist = abs(order.coordinates[0] - tech.coordinates[0]) + \
               abs(order.coordinates[1] - tech.coordinates[1])
        return urgency - dist                             # proximity only breaks ties

    def _hash(self, payload: dict) -> str:
        return hashlib.sha256(json.dumps(payload, sort_keys=True, default=str).encode()).hexdigest()

    def assign(self, order: WorkOrder, crew: list[Technician]) -> dict:
        try:
            if not order.weather_safe:
                raise AssignmentError("weather gate: conditional hold")
            if order.deadline < datetime.now(timezone.utc):
                raise AssignmentError("regulatory deadline expired")
            feasible = [t for t in crew if self._feasible(order, t)]
            if not feasible:
                raise AssignmentError("no technician with valid certifications and capacity")

            best = max(feasible, key=lambda t: self._score(order, t))
            record = {
                "order_id": order.order_id, "site_id": order.site_id,
                "technician_id": best.tech_id, "priority": order.priority.name,
                "assigned_at": datetime.now(timezone.utc).isoformat(), "status": "DISPATCHED",
            }
            record["audit_hash"] = self._hash(record)
            audit.info("ASSIGNMENT_COMMITTED | %s -> %s | %s",
                       order.order_id, best.tech_id, record["audit_hash"][:12])
            return record

        except AssignmentError as exc:
            fallback = f"FALLBACK-{order.site_id}-{self._hash(asdict(order))[:8]}"
            record = {
                "order_id": order.order_id, "site_id": order.site_id,
                "status": "DEFERRED", "reason": str(exc), "fallback_route": fallback,
                "deferred_at": datetime.now(timezone.utc).isoformat(),
            }
            record["audit_hash"] = self._hash(record)
            audit.warning("ASSIGNMENT_DEFERRED | %s | %s", order.order_id, exc)
            return record

if __name__ == "__main__":
    order = WorkOrder(
        order_id="WO-004471", site_id="TWR-4471", priority=PriorityTier.HIGH,
        deadline=datetime(2026, 7, 30, tzinfo=timezone.utc),
        required_certs=frozenset({"climb_auth", "tia222"}), coordinates=(38.90, -77.04),
    )
    crew = [
        Technician("TECH-118", {"climb_auth": date(2026, 6, 27), "tia222": date(2027, 1, 1)},
                   (38.95, -77.01), remaining_capacity=2),          # climb_auth lapsed
        Technician("TECH-204", {"climb_auth": date(2027, 3, 1), "tia222": date(2026, 12, 1)},
                   (39.10, -77.20), remaining_capacity=1),          # fully qualified
    ]
    print(TechnicianAssignmentEngine().assign(order, crew)["status"])

Testing & Verification #

Because feasibility and scoring are pure functions of their inputs, the engine’s behavior can be pinned with lightweight assertions rather than a running dispatch system. The properties worth locking down are the certification gate, the fallback path, and audit-hash stability:

import logging
from datetime import date, datetime, timezone

def _order(**kw):
    base = dict(order_id="WO-000001", site_id="TWR-4471", priority=PriorityTier.HIGH,
                deadline=datetime(2026, 7, 30, tzinfo=timezone.utc),
                required_certs=frozenset({"climb_auth"}), coordinates=(0.0, 0.0))
    base.update(kw); return WorkOrder(**base)

def test_lapsed_cert_is_infeasible():
    eng = TechnicianAssignmentEngine(dispatch_day=date(2026, 7, 3))
    lapsed = Technician("TECH-118", {"climb_auth": date(2026, 6, 27)}, (0.0, 0.0), 2)
    assert eng.assign(_order(), [lapsed])["status"] == "DEFERRED"

def test_no_crew_routes_to_fallback():
    rec = TechnicianAssignmentEngine().assign(_order(), [])
    assert rec["status"] == "DEFERRED" and rec["fallback_route"].startswith("FALLBACK-TWR-4471")

def test_expired_deadline_defers():
    past = _order(deadline=datetime(2020, 1, 1, tzinfo=timezone.utc))
    valid = Technician("TECH-204", {"climb_auth": date(2027, 3, 1)}, (0.0, 0.0), 1)
    assert TechnicianAssignmentEngine().assign(past, [valid])["reason"] == "regulatory deadline expired"

def test_audit_hash_present_on_dispatch():
    valid = Technician("TECH-204", {"climb_auth": date(2027, 3, 1)}, (0.0, 0.0), 1)
    rec = TechnicianAssignmentEngine().assign(_order(), [valid])
    assert rec["status"] == "DISPATCHED" and len(rec["audit_hash"]) == 64

A passing dispatch run prints DISPATCHED and writes one ASSIGNMENT_COMMITTED line naming the order, the selected technician, and a hash prefix such as ASSIGNMENT_COMMITTED | WO-004471 -> TECH-204 | 9c1b4f2a7e0d. In the __main__ demo above, TECH-118 is correctly filtered out because its climb_auth lapsed on June 27, so the run selects TECH-204. A failure looks different: an order with no feasible crew prints DEFERRED, logs ASSIGNMENT_DEFERRED with the reason, and returns a FALLBACK-TWR-4471-... route — the signal for a compliance officer to escalate rather than a silently dropped inspection.

Operational Considerations #

Field realities complicate the clean path. Certification data is the most common source of bad assignments, and its worst failure mode is staleness rather than absence — a technician’s climb authorization that expired last week but was never synced from the credentialing system will pass a naive “cert on file” check and fail the real one at the tower. Treat the certification store as authoritative-with-expiry, evaluate validity against the actual dispatch date, and re-pull credentials at the start of each shift rather than caching them for the week. Offline field devices add a second wrinkle: when a mobile client cannot reach the dispatcher, it must not invent assignments, so the engine’s output is designed to be computed centrally and pushed, with the device holding only a read-only manifest.

Multi-jurisdiction portfolios introduce curfew and quiet-hour constraints that vary by municipality, so a technician who is feasible on certification and capacity may still be barred from a night dispatch at one site while permitted at the next county over — those windows belong in the same feasibility filter, keyed per site, not bolted on afterward. On performance, feasibility filtering is linear in crew size and runs comfortably for regional crews of a few hundred; the scoring pass touches only survivors, which is typically a small fraction. Emergency override tickets — an active structural fault or an FAA lighting outage — are injected at CRITICAL and preempt scheduled work by out-scoring everything, and every such preemption writes its own audit record so a post-incident review can reconstruct why a routine visit was bumped.

FAQ #

Related #

• Up to the parent architecture: Intelligent Inspection Scheduling & Technician Routing
• Sibling topic: Frequency Logic & Threshold Tuning
• Sibling topic: Weather Window Optimization
• Deeper dive: Optimizing technician routes for multi-site maintenance windows
• Related how-to: Integrating NOAA Weather APIs for Safe Tower Climb Scheduling