Remote Public Housing Repair Triage: Why I Hide Model Confidence from Tenants

Building a repair triage system for remote communities sounds like a standard operations research problem. But when the algorithm's confidence scores are badly miscalibrated, and the cost of an error is leaving residents without water for weeks, technical choices become ethical choices. ReachNT, built by Team Top Enders for the CDU IT Code Fair 2026 AI Challenge, is exactly this kind of case.

The Problem: A Service Gap Created by Arithmetic

A household in a remote Northern Territory community loses water and calls the repair hotline. In Darwin, a plumber typically arrives within days; but in the bush, the same repair can drag on for weeks.

The reason isn't complicated. Sending a tradesperson to a remote community for a single work order costs a lot, so remote work orders keep getting deprioritized. Urgent repairs in town are completed within days, while the same work order in a remote area waits for weeks. ReachNT was built to close this gap: a repair triage system for remote public housing in the Northern Territory that fairly prioritizes repairs and intelligently plans trips.

Built by Aashish and the author as Team Top Enders for a coding competition, the system is a working demo, not a production system. It reads tenants' repair reports, ranks them by need, batches nearby communities into shared weekly trips, and gives every tenant a plain-language explanation of why their repair waited as long as it did.

The Data Boundary: Real Geography, Synthetic Requests

A public Northern Territory work-order dataset doesn't exist, and that's a premise of the system design. With no real repair requests to train on, the team wrote an entire year of synthetic requests.

What's real: 70 communities, housing counts, repair crew hubs, road closures, airstrips, and response-time data, all from real geographic information. Synthetic requests are explicitly labeled as synthetic inside the product, and the demo page doesn't pretend to be a real work-order record.

This boundary is built directly into the product, not buried in a README. Anyone who clicks around can see which parts are real geography and which are simulated data. That transparency is the foundation for trust.

Ranking Principle: Urgency Is a Property of the Fault

The first design decision: queue position must not depend on any characteristic of the tenant — not reporting time, not contact channel, not how detailed the description is, not English proficiency. Urgency is a property of the fault itself, not of the person describing it.

The urgency model reads tenants' plain-language repair reports and scores them. On phrasing the model hasn't seen in training, ROC-AUC is 0.84 — a middling result: ranking is mostly right, but it still makes mistakes. As part of a larger system that includes human review, it catches 99.3% of dangerous work orders.

The key phrase is "as part of a larger system." The model itself isn't the whole safety story — the system around it is.

The Calibration Problem: A Number That Shouldn't Be Shown

The model ranks reasonably well, but its confidence is alarming. When the model claims at least 90% certainty, it's actually right only 56% of the time. This is a badly miscalibrated model, and showing those numbers to tenants would be dishonest.

So tenants never see confidence percentages. 42% of dangerous reports are routed to human handling before any decision is made.

This was one of the hardest decisions in the project. Confidence scores look informative — the kind of number dashboards love to display. But a number with such a high error rate, shown to someone waiting for a repair, causes real harm — either false comfort or needless worry. The team chose to show tenants something true: a plain-language explanation of why the repair waited as long as it did. Show explanations, not probabilities.

The broader point: calibration is a metric nobody benchmarks but everyone should care about. A model can rank well and still be unfit to display its own certainty. The fix isn't a better model — it's acknowledging what the model can't do and designing around it.

Calibration and discrimination are often conflated, but they're two separate metrics. Discrimination measures a model's ability to rank positives ahead of negatives, represented by ROC-AUC; calibration measures whether the model's output probabilities match real-world frequencies. A model can have high AUC and accurate ranking while systematically overestimating or underestimating its own certainty — for example, always being "90% sure" when it's actually right only 50% of the time. Common calibration metrics include expected calibration error (ECE) and reliability diagrams, with fixes like Platt scaling, isotonic regression, and temperature scaling. For user-facing systems, calibration is often more important than AUC: users can tolerate the model occasionally misranking and being caught by human fallback, but they can't tolerate being told a false probability. This is the technical basis for hiding confidence in this article.

Shared Trips: Using an H3 Grid to Cut Remote Service Costs

Ranking is only half the system; the other half is getting tradespeople on site without blowing the budget. Batch scheduling is built on Uber's H3 grid.

H3 divides the Northern Territory into hexagonal cells, and communities falling into adjacent cells are grouped into shared weekly trips, letting one tradesperson cover multiple communities in a single journey. Across five random synthetic years, shared trips saved $67 to $76 per repair. Against a baseline of about $821 per repair, that's a real reduction.

Batch scheduling must work in concert with urgency ranking. Shared trips only make sense if the urgent work orders within them still get done first. The planner schedules by need within each trip, so grouping communities never means urgent repairs fall behind cosmetic ones. Batch scheduling saves money, ranking determines order, and neither overrides the other.

H3 is Uber's open-source hierarchical hexagonal geospatial indexing system. It recursively divides the Earth's surface into a series of resolution levels, with each hexagonal cell having a 64-bit integer-encoded address that can be cheaply expanded from parent to child cells. Compared to latitude-longitude grids, hexagons are more uniform in neighborhood distance: each cell has exactly six equidistant neighbors, avoiding the distortion in square grids where "diagonal neighbors are farther away," making them especially suited to neighborhood aggregation and regional grouping. In scheduling scenarios, H3 is commonly used to group spatially nearby points into the same cell, enabling batching or partitioning at a fixed granularity. This article uses it to put adjacent communities into the same weekly trip, exploiting the uniformity of hexagonal neighborhoods to approximate the concept of "on the way"; higher resolutions mean smaller cells and finer grouping, while lower resolutions mean more concentrated trips.

The Weekly Planner: Solver Speed and Human Sign-Off

The weekly plan comes from a CP-SAT solver. Across 26,018 weekly plans, 99.5% were proven optimal, with a median solve time of 8 milliseconds.

Speed matters because plans are only drafts before human sign-off. Every weekly plan requires a named coordinator's signature before it goes out. The solver optimizes cost and fault-days but refuses to sacrifice urgency order — a cheaper plan that puts urgent repairs behind routine ones isn't a valid plan.

The point of sign-off: when a tenant asks why their repair waited, there's a person who approved the plan, not a black box. The solver is fast and near-optimal, but its inputs are synthetic requests and scheduled distances. A coordinator familiar with the roads and communities reviews the plan before it goes out.

CP-SAT is the constraint programming solver in Google OR-Tools, aimed at combinatorial optimization problems over integer and Boolean variables. It expresses problems as variables, constraints, and an objective function, internally combining SAT solving, linear relaxation, cutting planes, and large neighborhood search, often delivering provably optimal or near-optimal solutions in milliseconds on NP-hard problems like scheduling, timetabling, and bin packing. Unlike linear programming solvers, it's naturally suited to logical constraints (e.g., "if A then not B") and non-divisible assignment relationships. In this article, "99.5% proven optimal" means the solver not only found a solution but also provided an optimality proof; the median 8-millisecond speed makes "recomputing the plan every time" economically feasible. Note that optimality holds only relative to the objectives and constraints input during modeling — if the objective function doesn't capture fairness, the solver will precisely optimize the wrong quantity.

Data Comparison: Cost per Repair vs. the Fairness Trade-off

In one synthetic year, ReachNT averaged $821 per repair, with nine in ten remote urgent repairs fixed within 3 days and a weighted fault-day count of 61,700. The cheapest-first baseline averaged $561 per repair, but remote urgent repairs waited 62 days versus 3 days in town, with fault-days reaching 233,100.

Cheapest-first looks cheaper per work order, but it produces a system where a remote household waits two months for an urgent repair while town waits three days. ReachNT costs more per repair but closes the gap. The tool openly prices the fairness trade-off rather than hiding it in averages.

The author is candid about limitations: this is a synthetic evaluation. Repair requests are fabricated, tenant behavior is fabricated, and how a model trained on synthetic text behaves on real reports is unknown. Given real work orders, the top three priorities would be: retrain the urgency model on real tenant phrasing; re-run the calibration analysis; and test shared-trip batching with actual travel patterns rather than scheduled distances. The team is proposing a pilot in 16 communities around the Katherine hub.

Adversarial Audit: A Safety-Critical Defect

Before launch, the team ran a multi-agent AI audit on the system. It found a real defect: a dangerous life-support repair could be downgraded based on a single photo.

Here's what that means: a tenant uploads a photo, someone re-evaluates the report based on the image, and a repair keeping medical equipment running gets reclassified as routine. In a system premised on urgency determining order, this is the worst possible failure mode.

The fix came at three layers: the portal blocks that downgrade path in the UI; the server validates; and the database design records the original severity so later edits can't silently erase it. One defect, three layers of defense, because a safety property that exists in only one layer is just a suggestion.

The audit was the single most worthwhile thing in the project. Everything else in ReachNT was a consciously chosen trade-off; this was an unchosen one, and the audit caught it before tenants hit it. For safety-critical paths, adversarial review should happen before release, not after — that's the most portable lesson from this case.

Multi-agent adversarial auditing means having several AI agents with different role settings attack and defend against each other to expose a system's failure modes. A typical setup has red-team agents trying to construct bypasses, downgrades, or fraud paths, blue-team agents defending and patching, and a judge agent evaluating the validity of findings. Compared to traditional manual penetration testing, its advantages are lower cost and parallel coverage of many edge cases, especially good at finding logic flaws like "a legal sequence of operations leading to an illegal state" — such as downgrading a life-support repair with just a photo in this article. Its limitations are equally clear: the agents' attack surface is bounded by their prompts and tools, generated findings need human review, and complete coverage can't be guaranteed. "Safety-critical paths should get adversarial review before release, not after" is a portable engineering principle: treat auditing as part of the test suite, not a post-launch remediation step.

One-line Summary

Building the ReachNT repair triage system for remote Northern Territory communities, making ethical choices between miscalibrated algorithms and the cost of fairness.

Paragraph Summary

This article reviews ReachNT, the repair triage system built by Team Top Enders for the CDU IT Code Fair 2026 AI Challenge. Targeting the gap where remote Northern Territory communities wait weeks for repairs while towns wait days, it uses an urgency model to rank reports, Uber's H3 hexagonal grid to batch nearby communities into shared weekly trips, and a CP-SAT solver to generate plans requiring a named coordinator's sign-off. The team insists urgency depends only on the fault itself, not on the reporter's characteristics, and — because the model is badly miscalibrated (claiming 90% certainty when actually right only 56% of the time) — refuses to show tenants any confidence percentage, offering plain-language explanations instead. Synthetic evaluation shows $821 per repair with nine in ten remote urgent work orders fixed within three days, while the cheapest-first baseline costs only $561 but leaves remote households waiting sixty-two days. The adversarial audit also found that dangerous repairs could be downgraded with just a photo, with fixes spanning the UI, server, and database layers.