21,000 repeat trips at $337 each: a leak AI could close
When a carrier like T-Mobile needs work done on a cell tower, it doesn't send its own people — it hires a contractor, whose technician climbs 150–200 feet, does the job, and records it on a phone: equipment at the right angle, grounding wires secured, serial numbers readable. Around 100 photos and 20 videos per site. Nobody from the carrier is there to watch, so those images are the only proof the work happened. Nothing gets paid until they're approved.
So the entire payment chain rested on evidence no one could verify at the point it mattered. Photos were checked two or three days later, at a desk — by which time the crew was 50 miles away, and the only remedy for a bad one was to send someone back up the tower. That gap cost money the obvious way, and it invited abuse in ways that were harder to see: photos that were sharp but showed the wrong part, credentials that were valid but belonged to someone else, real photos recycled from another site. The camera was never the problem. We were checking the evidence too late, and never against what the contract actually required.
My role
Sole PM — discovery to rollout
Product
Scopeworker · field evidence validation
Scale
150–200ft towers · ~100 photos + 20 videos per site
What I found
$7.1M billed twice
The fix was to move trust to the moment of capture — validate each photo on the tower, while the technician can still act on it, and validate it against what this job actually demands.
$7.1M
billed twice for repeat site visits over three years
21,000
repeat climbs for a visit the contract already covered
18% → <2%
submissions sent back for rework
Desk → tower
where the check happens
Afterfig.01The check now happens here — in the technician's hands, on the tower, before they unclip.
The problem
Payment rested on evidence we checked too late
Nobody in this chain was careless. The technician took the photos they were asked for, in the conditions they had — wind, glare, a phone held one-handed at 180 feet. The reviewer checked them properly. What went wrong was the distance between those two moments.
The climb
Technician climbs 150–200 feet and does the job
Hours of precise work, often in wind or glare.
↓
The capture
Records ~100 photos and 20 videos on a phone, then descends
↓
The departure
Crew packs up and drives to the next site
Often hours away. As far as they know, the job is done.
↓ two to three days later
The review
A reviewer finally opens the package
↓
The rejection
One serial number isn't readable
The crew is 50 miles away, already on another job.
On a phone screen in bright sun, the photo looked fine. Two days later on a desktop monitor, the serial number wasn't legible — and the only person who could retake it was on another tower in another county. That gap cost money in the plainest way: $337 a trip, 21,000 times over three years — about $7.1M. And every one of those was a person put back up a 150-to-200-foot structure to retake a photograph. Whatever the good reasons are for climbing a tower, that isn't one of them.
But the delay didn't just cost re-climbs. The same gap — evidence checked late, and never against the contract — let subtler things through, and these are the ones a reviewer often couldn't catch at all:
Unreadable. Blur, glare, wrong angle. The honest failure — and the one that cost a re-climb.
Gamed. A technician submits a deliberately bad photo, waits for the rejection to trigger a $337 return-visit payment, then uploads the good photo they'd had on their phone the whole time. The delay is what made it pay.
Wrong part. A sharp, well-framed photo of a part that isn't what this client's spec actually required.
Wrong person, or recycled. A valid certificate belonging to someone who wasn't on site; a real photo taken weeks earlier, somewhere else.
One root cause, four shapes
Four different failures, one cause: we verified evidence after the fact, disconnected from what the job actually required. Fixing it meant changing where and when the check happened — and what it checked against.
The solution
One question, asked at the moment of capture
The four failures shared a root cause, so they shared a fix: ask "is this real, correct evidence for this job?" while the answer is still cheap — on the tower, before the technician unclips — and check it against what the contract requires, not a general idea of a good install.
That took four layers. The order matters: cheap, certain checks first; the model last, only on what survives.
First — no AI
Provenance: timestamp, location, duplicate check
Answers already in the file.
↓ only what passes continues
Then — the model
Reads the photo against this client's spec, and checks fields against each other
↓
Result
Evidence that belongs to this job, showing what the contract asked for
1 · The check moves to the tower
Simple rules can confirm a file exists or clears some resolution. They can't tell whether a serial number is readable through glare, or whether the frame shows the grounding wire actually meeting the lug.
So a multimodal model reads each photo against a description of what it should show — for a grounding lug, about ten things — and answers before the technician comes down.
fig.02Each photo is checked against 10+ workflow-specific parameters — is it the right unit, does the cabling match the diagram, is the serial legible — tailored per workflow with prompts, not hard-coded rules.
Illustrative — the on-tower feedback, not a real screenshot
CAPTURE · grounding lugon-site
Is the lug in frame? · Is the connection point visible? · Is the bolt seated? · Is the serial legible through the glare? · Is the angle close to spec?
✕ serial number in shadow"Tilt about 10° left and retake" — while still on the tower
Getting it wrong now costs ten seconds. Getting it wrong before cost $337 and a second climb.
Why crews actually used it
A model that only said "Rejected" would be worse than nothing — the technician is 180 feet up and now knows something's wrong but not what. It returns the fix instead: "the serial number is in shadow — tilt about 10° left and retake." That specific instruction is most of why the group likeliest to reject the tool didn't.
2 · The model reads the contract, not its own instincts
A sharp photo of the wrong part still passed — we'd told the model what the photo was of, never what the contract required of it.
Every client already had this written down — specs, method statements, the SOPs their own engineers work from — in documents nothing in the checker had ever seen. So a retrieval step pulls the sections of this client's spec that apply to this job and puts them in front of the model with the photo. A rooftop small cell and a macro tower pull different documents; nothing hard-coded.
Input
A photo, and the job it belongs to — client, region, job type
↓
Retrieve
Pull the sections of that client's specs that apply to this job
↓ specs go to the model with the photo
Check
The model reads the photo against those specs
Why retrieve instead of fine-tune per client
Onboarding a client becomes adding documents, not retraining a model — which matters when you're onboarding continuously. And their specs are read at check time and never trained on: the only version their security teams would sign.
3 · Fields get checked against each other
A real climber name and a real, current certificate both passed on their own — but the name on the certificate belonged to someone else, borrowed to cover a crew short a qualified climber.
Nothing checked the relationship between fields, because no single field owns that rule. So now the name entered, the name read off the certificate, and the crew roster are checked as one thing. Change one field mid-submission and the whole cluster re-checks, not just the edited one.
Illustrative — fields valid alone, fraudulent together
FIELD · climber name✓ valid
"John Doe" — a real, active technician
FIELD · certification upload✓ valid
A real, current climber license — issued to "James Smith"
✕ cross-field mismatchthe name entered doesn't match the name on the certificate
Each field is valid. The problem is the relationship between them — the one thing nothing was looking at.
4 · Provenance, without a model
Whether a photo was taken at the right place and time isn't a judgment call — the answer's already in the file. Three plain checks run in front of the AI:
Timestamp outside the job window → reject
Duplicate of an image already submitted, to this job or any other → flag
Location doesn't match the assigned site → reject
Why the order matters
Running these first means spoofed evidence never reaches the model, so there's nothing for it to be talked past — and we don't spend model time on submissions already disqualified. That's what kept cost flat as the checks piled up.
The constraints that shaped it
Two decisions had nothing to do with model quality:
Data sovereignty. This runs on infrastructure for US carriers. Some offshore models — DeepSeek among them — reasoned well and I ruled them out anyway: a model our clients' security teams won't approve is worth nothing, whatever it scores. We went with OpenAI's. Small performance gap; decisive approval gap.
Who pays. A check under $1 against a $337 trip is 337×. Strong enough to take the cost off our books entirely and make it a line the client pays — reasonably, since the client had been funding the repeat visits all along.
<$1.00
one check at the moment of capture
vs.
$337
the repeat trip it prevents
=
337×
billed to the client rather than absorbed by us
Outcome
What changed, and what I'll only claim carefully
The check moved from a desk two days later to the tower, in the moment. The one number I trust most is the rejection rate, because it's measured the same way on both sides of the change.
Before
After
Submissions sent back for rework
18%
under 2%
Time to find out a photo was bad
2–3 days
while still on the tower
Cost of fixing one bad photo
$337 and a second climb
under $1, ten seconds
What I won't pretend to know
The $7.1M is what the problem cost over three years — not what we recovered. Repeat-visit change orders fell sharply after launch, since they're a direct consequence of rejections, but I'd be guessing if I attached a first-year dollar figure. I'd rather leave it as the rate.
The layered checks don't have that clean before-and-after — they went in gradually, one at a time. So instead of a number I don't trust, here's what they now catch that nothing caught before:
A part that doesn't match the client's specification
A certificate belonging to someone who wasn't on site
A photo taken three weeks earlier, somewhere else
All three used to land on a reviewer's desk — or get approved.
Two things came out of it that weren't on the plan.
Reviewers stopped being the first line of defence. The obvious rejections — blur, wrong angle, missing shot — don't reach them any more, so what's left in the queue is the genuinely ambiguous: an install that looks unusual, a spec that doesn't quite match the site. That's the work that actually needs a person.
And people stopped climbing 200-foot towers to retake a photograph. That one has no number attached, and it's the one I care about most.
What I'd take to the next one
Shipping is when you learn what was actually wrong. The readable-photo fix worked — and the failures it cleared away were sitting on top of a second set underneath. If I'd stopped when the rejection rate dropped, the wrong-part, wrong-person, and recycled-photo checks would all still be missing.
Not everything wants a model. Of the fixes here, one needed the model to read a spec, one needed two fields compared, and one just needed a timestamp. Working out which is which — and running the cheap, certain checks first — was most of the design.
