LAT
Lifecycle Assessment Tracker — Designing an AI-assisted maintenance system people could trust with $180K decisions
01 — Snapshot
TL;DR
Fragmented data was forcing humans to do the work a system should have done
70–75% of operational U.S. buildings predate 2000 (EIA.gov). The tools we evaluated didn't connect maintenance history, lifecycle risk, and capital planning to fit the university's existing systems.
A technician underground can't access repair history. A manager stitches spreadsheets before planning. Leadership decides on partial data.
"I do the physical work in 30 minutes, but reporting takes another 20."
"Each year I'm choosing between urgent-now and smart-long-term with partial data."
Impact
Pilot cohort: 43 people (18 technicians, 15 operations/asset managers, 7 accounting, 3 executives), tracked over 12 weeks — the test group for a tool that rolled out to ~4,000 technicians and facilities-adjacent staff with system access across every building and campus.
Observed metrics come directly from pilot and rollout usage logs.
Operational. Linking work orders to lifecycle cost made repair history visible in real time.
Decision-making. Teams stopped entering meetings to reconcile facts, and started entering them to decide.
Strategic. Scenario simulation moved feasibility analysis in-house and drew interest from other universities.
02 — Context & Problem
Why existing tools failed the people managing this infrastructure
Discovery research (separate from the 43-person pilot that came later): 7–8 technicians and vendors, 4 project managers, 2 accountants, 5–6 executives, and the Director of Facilities — the university's primary sponsor.
CMMS platforms don't model asset lifespan or CapEx tradeoffs — preventive maintenance ran on time, not risk. Replacing the stack wasn't viable, and no tool we evaluated offered the integrated version at any price.
Technicians worked underground with no signal → connectivity isn't guaranteed → offline-first capture with queued auto-sync
Managers scanned a wall of graphs before acting on anything → more information wasn't producing better decisions → a ranked priority queue replaced the dashboard
Managers hesitated on a "68% failure risk" alert → a risk score tells you how worried to be, not what to do → alerts reframed around cost and timeframe
Legacy records had inherited duplicates that inflated risk scores → an AI system inherits its data's quality problems → a "Needs Verification" state with mandatory human approval
03 — Solution
Three decisions, one standard running through all of them: never act without a human verifying it first
Translating numbers into decisions was the real problem. The system did three things: kept data clean, prioritized attention, explained financial stakes — each one verified before it reached a budget. Trustworthy decisions were the actual product.
Problem. Field data is where "50% data accuracy" actually breaks — a completed job whose update never reaches the system is, downstream, a job that never happened.
Sync state became visible on the work order itself — saved, sending, or failed, with a one-tap retry.
A failed sync shouldn't feel like lost work. We kept the update safely on-device and made recovery one tap.
Result. This is the field layer behind the 50%→92% data-accuracy jump (see Impact). Median approval time: 7-9 minutes with everything needed, 2.2-2.8 hours when still waiting on data.
Problem. 8 of 10 managers were overwhelmed by the dashboard's graphs, map, and calendar — and queued items instead of acting.
Considered. Five versions, from a 26-panel dashboard down to one decision and three tasks — each one removed or added something, and the overwhelm only eased once we stopped trimming panels and started ranking what the manager should do.
Click a screen to view the full image.
Cut the graphs
Still no first action — every remaining panel had equal weight.
Added AI help
A summary and 4 dropdowns added more to read, not more direction.
Queue replaces the grid
Five equal rows — the boiler said "Review," not a decision.
One decision first
Cost + date framing worked — everything else reads as secondary.
Design. A ranked priority queue replaced it; filters now show which options are feasible.
Cost. Lost the liked-but-messy auto-arranged calendar; rolled out to 20 managers for two weeks before the full 64.
Result. Weekly closure rate roughly doubled (4/10 → 8–9/10 across 12 managers), decision time dropped 14→4 min, and IT saw just 1–2 help requests a month after full launch.
Model said: Critical — Boiler Unit 3, the same asset Decision 03 below walks through, now flagged for a $180K replacement.
Human found: duplicated maintenance records had inflated the risk score.
Design response: a "Needs Verification" state, visible risk drivers, mandatory manager approval, and logged overrides.
Result: adoption held steady — the near-miss became a reason to trust the system more, not less.
First version showed "Boiler failure risk: 68%." Managers didn't trust a number they couldn't trace. We landed on dollars instead — managers think in the monthly CAPEX cycle, where a figure maps straight onto "can I request this now."
Boiler failure risk: 68%
3 years past 9-year lifespan → $3K/month if not replaced
Result. Override rate 61%→19%; acceptance 42%→78%; resolution time 3 days→2 hours — voice capture in the field closed the gap technicians avoided by skipping the office trip.
Risk routes into Critical / Monitor / Safe, never a raw probability. Critical alerts always show their drivers and require a human call before touching budget.
Watching for rubber-stamping: managers log reasoning even when they agree, so a falling override rate reads as trust, not deferral.
"It's great that I can add my own opinion instead of just accepting or rejecting a flagged asset, and pulling up its history in one click instead of digging through folders has made decision-making a lot less stressful."
— facilities manager, post-launch stakeholder interview
Outside the core prioritize → explain → verify loop, two more workflows fed the same data model.
Offline field reporting. Work Orders, Asset DNA, and Cost-to-Date link automatically — offline capture, voice input, and auto-sync cut average reporting time from ~20 to ~8 minutes per ticket.
Typing underground or on a swing stage isn't practical, so voice fills the form hands-free. 40+ technicians used offline capture in the first month, surfacing an unscoped need for offline asset history, which we added. The real win, per managers: synced updates close jobs without chasing technicians.
Scenario simulation. In-house cost comparisons replaced feasibility studies, drawing outside interest.
04 — The Turning Point
We weren't designing another dashboard — we were connecting decisions that used to happen in isolation
We thought we were customizing a product. Research showed each role was making decisions in isolation, off the same data — what was missing was shared context and trust.
So instead of one dashboard for everyone, we built role-based surfaces over a shared foundation, surfacing only what was actionable.
05 — Constraints & Design Responses
The legacy ecosystem couldn't be disrupted — LAT shipped as a modular layer alongside it
06 — Tradeoffs
We chose human-in-the-loop over speed, even where it cost us
Every feature mapped to one driver: cost, planning accuracy, or adoption. Offline workflows and data integrity came before expanding AI scope — these three tradeoffs show where.
Override rate = the share of AI flags a manager or accountant overturned, compared early vs. late in the 12-week pilot. The drop was gradual — it fell week over week as managers built confidence in the score and began logging reasoning notes even when they agreed with it.
07 — Reflection
Clarity drove action more than completeness — users didn't want more data, they wanted less to think about
What I got wrong. I thought predictive accuracy would drive adoption. Data integrity mattered more — strong predictions failed when the data was messy.
What mattered more. The lifecycle linkage, not the AI. Once work orders, asset history, and cost were reliably connected, decisions improved before the predictive layer even matured.
What I learned about AI in enterprise. Adoption depends less on model sophistication than on whether people can see why it's wrong when it is. Design for the failure, not the demo.