InfraEcho

We turn scattered municipal work-order notes into asset-aware recurrence alerts, explainable maintenance hypotheses, and dispatcher-ready preventive actions.

Comment

Inspiration

Municipal maintenance teams record valuable information every day, but much of it remains trapped in free-text work-order notes. A single leaking water main may appear across several separate records: one report mentions a leak, another records a repair, a later visit says “no problems found,” and a future request reports that water is appearing again.

Individually, each work order looks ordinary. Together, the records may reveal a recurring infrastructure problem.

This inspired us to build Maintenance Memory, an explainable prototype that converts scattered work-order notes into asset-aware recurrence alerts and practical maintenance recommendations.

What it does

The system analyzes municipal work orders from water, sewer, streets, traffic, electric, and building departments. Our prototype focuses on recurring water-distribution problems because the dataset includes clear water-main procedures and operational language.

The pipeline:

  1. Normalizes work-order records at the correct work-order grain.
  2. Builds a reliable asset key using EntityType|EntityUid.
  3. Removes dispatcher boilerplate and employee names before text retrieval.
  4. Groups visits into asset histories and recurring episodes.
  5. Mines an Agent Logic Package, or ALP, from phrases actually written by crews.
  6. Assigns a transparent triage score for human review.
  7. Produces a grounded PM_INSIGHT_REPORT containing work-order IDs, dates, locations, evidence, hypotheses, and recommended actions.

The system does not treat a closed status as proof that a physical problem was resolved. Instead, it reads the final note and checks whether later records show recurrence.

How we built it

We used the challenge dataset containing:

  • 37,778 work orders
  • 867,448 work-order-to-asset records
  • 33,572 technician comments

For data normalization, we used one row per work order when counting jobs. Asset histories use the combined key EntityType|EntityUid, because the same numeric identifier can represent different asset types.

We filtered invalid date sentinels, excluded bulk attachment jobs from recurrence analysis, and segmented asset histories using a transparent 180-day quiet-period rule.

For retrieval, we built an offline TF-IDF text-retrieval baseline. This keeps the prototype lightweight, reproducible, and privacy-conscious. The retrieved work orders are then used as evidence for the dispatcher report.

The recurrence triage score is calculated as:

$$ S_{\text{triage}} = 0.40R + 0.30I + 0.20P + 0.10V $$

where:

  • R represents recurrence evidence;
  • I represents same-issue evidence;
  • P represents time proximity between visits;
  • V represents a verification gap, such as “no problem found” followed by another related visit.

This score is used as a transparent review ranking, not as a calibrated probability.

Our ALP follows this structure:

Observation → Meaning → Action

Observation Meaning Action
“Still leaking” or “again” Possible repeat failure Link the record to the prior asset episode
“No problems found” The symptom may be intermittent or unverified Schedule follow-up verification
“Water coming up from the ground” Active or suspected water loss Dispatch targeted leak localization
“Low pressure” Possible restriction, valve issue, or leak Perform pressure and isolation checks
“Repair complete” Corrective action was attempted Look for later recurrence before declaring success

Example Insight

The prototype identified the following candidate episode:

  • Asset: WMAIN|2456
  • Location: 1502 W DANFORTH RD
  • Period: 78 days
  • Related work orders: 93323, 95876, 96720, and 98303

The sequence contains:

  • 93323: water was “still leaking”
  • 95876: a main break and repair activity were recorded
  • 96720: leak detection found “no problems”
  • 98303: water was coming up from the ground “again”

The evidence supports a recurring or incompletely verified water-loss problem. We deliberately label the physical cause as a hypothesis because the dataset does not contain a direct cause field.

The recommended action is to link the records into one recurrence episode, perform targeted leak localization and isolation or pressure testing, and require verification evidence after repair and service restoration.

The supplied water-line-break and chlorination procedures further support a response sequence involving stopping water loss, repairing and restoring service, flushing, sampling, and documenting the result.

Challenges we ran into

The dataset has no answer key. It does not directly tell us which records belong to the same incident, whether an issue was truly resolved, or what caused a failure.

We also encountered inconsistent addresses, duplicated asset attachments, catch-all asset identifiers, dispatcher boilerplate, and records with missing or very short notes.

To keep the system explainable, we avoided presenting the triage score as a calibrated probability. It is a transparent ranking that helps prioritize human review.

Accomplishments that we're proud of

We transformed a large, messy municipal dataset into an end-to-end, reproducible analysis pipeline.

We correctly handled the difference between work-order records and work-order-to-asset records, avoiding inflated job counts.

We built asset-aware recurrence episodes using real infrastructure identifiers instead of relying only on text similarity.

We created a corpus-specific ALP based on phrases that municipal crews actually wrote, including “still leaking,” “again,” “no problems found,” and “low pressure.”

We produced a grounded insight using real work-order IDs rather than a synthetic example.

We separated direct observations from causal hypotheses, making the system more transparent and trustworthy.

We created dispatcher-ready recommendations that connect recurring reactive work to preventive-maintenance actions.

We designed the prototype to be lightweight, privacy-conscious, and reproducible without requiring a large language model or paid API access.

What we learned

The challenge revealed several important data-engineering issues:

  • Counting rows after joining work orders to assets overstates the number of jobs.
  • EntityUid alone is not a safe asset identifier.
  • Work-order descriptions are templates, not reliable evidence of what happened.
  • Priority is mostly a default value and provides little analytical value.
  • “Closed” does not necessarily mean physically resolved.
  • Causes are rarely written explicitly and must be inferred across multiple records.
  • Generic AI triggers do not work well unless they are adapted to the vocabulary of the actual corpus.
  • Employee names appear inside technician notes and should be removed before sending records to external AI services.

What's next for InfraEcho

The current system is a strong partial prototype rather than a finished production system. Our next steps would be:

  • Hand-audit the top 50 recurring episodes.
  • Improve the ALP using reviewer feedback.
  • Normalize addresses using geocoding or canonical location identifiers.
  • Compare TF-IDF retrieval with sentence-transformer embeddings.
  • Calibrate the triage score using expert-reviewed examples.
  • Add a privacy-safe language model for report generation.
  • Connect recurring patterns to preventive-maintenance schedules.

Built With

Share this project:

Updates

Submission history