Post-incident report (FICTION): 412 potholes that were fixed on paper

FICTION / SCENARIO. This is an imagined incident report set in 2027. The city, companies, people and numbers in the report are invented. The systems named in the final section ("What would have cut the chain") are real and described as they exist today.

INC-2027-0314: Road repair work orders closed without repairs

City of Port Alder, Department of Streets (fictional)
Status: Closed. Severity: 2 (public safety, financial loss). Report date: April 2, 2027.

Summary

Between February 8 and March 12, 2027, the city's payment agent approved 412 pothole repair work orders submitted by a contractor's dispatch agent. An internal sample later found that about 260 of them had not been repaired. The city paid $74,160 (412 × $180) under its per-repair contract. On March 14, a food delivery rider crashed on Linden Avenue in a pothole that the system had shown as repaired since February 21. He broke his wrist.

Nobody lied in the usual sense. Each agent did what it was built to do. The failure was that every step trusted another system's claim that physical work had happened, and no step could check the street itself.

Parties

• City of Port Alder, Department of Streets: runs the 311 service and the payment agent that settles contractor invoices.
• Brightway Paving LLC: contractor paid per completed repair. It uses a dispatch agent that closes work orders from crew data.
• Crews: two-person trucks with GPS trackers and a phone app for photos.
• The rider: a gig worker injured on March 14.

How the system was supposed to work

1. A resident reports a pothole through 311. A work order is created with GPS coordinates.
2. Brightway's dispatch agent assigns it to a crew.
3. When the crew finishes, the dispatch agent closes the order if two signals agree: the truck's GPS stayed within 30 meters of the location for at least 10 minutes, and a completion photo is attached.
4. The city's payment agent pays any order closed with both signals. A human auditor reviews a 2% sample each quarter.

Timeline

• Feb 1: Brightway's dispatch agent is updated to "fill missing completion photos with the closest matching photo from the same crew's shift", to stop orders getting stuck when the app fails to upload.
• Feb 8: Cold weather causes a spike in reports. The crews start parking at a central asphalt plant on Linden Avenue between jobs.
• Feb 8 to Mar 12: Trucks waiting at the plant sit within 30 meters of several open work orders on the same street for more than 10 minutes. The dispatch agent sees GPS dwell + a photo (filled in from another job) and closes those orders. 412 orders are closed this way in total. Some were real repairs, many were not.
• Feb 21: Work order #88231 (Linden Ave, outside No. 214) is closed. No crew left the truck.
• Mar 3: The payment agent settles the February invoice: $41,400 for 230 orders.
• Mar 12: The payment agent settles the March batch: $32,760 for 182 orders.
• Mar 14, 18:40: The rider hits the pothole at #88231 and falls.
• Mar 15: The 311 agent rejects two new reports for the same spot as "duplicate of a resolved order".
• Mar 17: A council member forwards a resident's photo. The auditor pulls 50 closed orders and finds 32 with no repair.

Impact

• Money: $74,160 paid. An estimated $46,800 (about 260 orders) was for repairs that did not happen.
• Safety: one injury, plus 14 claims for tire and rim damage.
• Service: 39 new resident reports were auto-rejected as duplicates of "resolved" orders.
• Trust: the contract was suspended while the remaining orders were checked by hand.

Root cause

The system treated a location signal plus a photo as proof that work was done. Neither proved it. GPS dwell proved a truck was near the spot, not that anyone repaired anything. The completion photo was not tied to the place or the time it claimed to show. After the February 1 update, it could come from a different job entirely.

The payment agent never looked at evidence. It read the dispatch agent's status field, which was itself a summary of two weak signals.

Contributing factors

1. Payment per closed order rewarded closing orders, and nothing in the loop checked the street.
2. The photo fallback was added to fix an upload bug, and nobody re-checked what it did to the meaning of "evidence".
3. A 2% quarterly audit was far too slow for a five-week failure.
4. Duplicate suppression in the 311 agent trusted the closed status, hiding the strongest signal (residents reporting the same hole again).

Remediation (taken)

• The photo fallback was removed. An order without its own photo stays open.
• GPS dwell was dropped as evidence. It is now used only for routing.
• Re-reports of a "resolved" location now reopen the order instead of being suppressed.
• Payment is held for 14 days, and a sample of orders is checked in person each week.

What would have cut the chain (real systems, today)

Each step above trusted a claim. Three things that exist today could have turned those claims into evidence that can be checked:

1. Content Credentials (the C2PA standard). The Coalition for Content Provenance and Authenticity publishes an open standard for attaching a cryptographically signed record (a "manifest") to a photo, including when and with what device it was captured and how it was edited afterwards. Some cameras and phone apps can sign photos at capture. If the crew app had required a signed photo, a picture borrowed from another job would show a different capture time and location. Source: c2pa.org.
2. An independent AI verification step with on-chain results, such as Verdikta. Verdikta runs a panel of AI arbiters that each commit a hidden answer and then reveal it, so they can't copy each other, and the result is written on-chain (on Base). Paired with before/after photos and the work order, a panel could answer a narrow question: "Does the after photo show the same pothole, now filled?" The payment agent would act on that verdict instead of the dispatch agent's status field. Source: bounties.verdikta.org.
3. Ethereum Attestation Service (EAS). EAS is an open-source protocol for making signed attestations, on-chain or off-chain, against registered schemas. It is deployed on Ethereum and on networks such as Base. A "repair verified" attestation, issued only after steps 1 and 2 pass, would give the payment agent one checkable record to rely on. Source: attest.org.

What this would still not have caught:

• A bad repair: a signed photo of a filled hole says nothing about depth or compaction. The patch can fail in a week.
• A staged photo: a real, signed picture of a different pothole, or of the right one taken before the crew drove off without working.
• A wrong question: if the verification asks "is there asphalt in this photo?" instead of "is this the same hole, now filled?", it will confidently approve the wrong thing.
• Incentives: payment per closed order still rewards closing orders. Verification makes cheating harder, not pointless.

The lesson is boring, which is the point: an agent's claim that something happened in the physical world is not evidence. The fix is not to trust the agents more. It is to make every step pass along evidence that someone else can check.