Corridor & area reports.

Design v0.1 · Draft · 2026-08-30 · Report type not yet enabled in the app UI

A single pothole is a point. The entire quarter-mile of Beacon Street between 3rd and 4th Avenues, where five different residents have filed nine reports over three months for potholes, faded crosswalk paint, a broken streetlight, and a dead street tree — that’s what actually needs a paving contract, a corridor-level accessibility audit, and a line item in the next budget. Cities respond to segments, not GPS pins. Fault Line has been treating every hazard as a point. That gap is the reason a real, obvious, systemic problem often gets treated by the municipality as ten unrelated tickets, each closed in isolation.

1. Why corridors and areas matter

Municipal work orders operate on segments. A DPW crew doesn’t patch one pothole; they mill and repave a block. A traffic engineer doesn’t retime one signal; they retime the corridor. A neighborhood accessibility audit doesn’t evaluate one curb cut; it evaluates the walk network. Reports that arrive as isolated points force the recipient to reconstruct the segment-level pattern themselves — work that most departments don’t have staffing to do consistently.

Three concrete problems point-only reporting creates:

• Response fragmentation. Ten reports on the same block get treated as ten tickets. Each gets closed when its individual defect is patched, without addressing the fact that the underlying road surface is failing everywhere along the segment.
• Accountability arbitrage. A department can “close” ten point reports at 100% closure rate while the underlying corridor is still visibly failing. The Shame Index calculation, correctly configured, should notice this — but only if the corridor is represented as a first-class object, not as a computed inference over points.
• Grant-application weakness. Federal infrastructure funding (BRIC, Safe Streets and Roads for All, USDOT Reconnecting Communities) is awarded to segments and networks, not points. Cities applying with a bag of GPS pins are less competitive than cities applying with well-documented corridor-level need analyses. Fault Line data should be usable in the application.

2. Three report types

The default report flow stays point-first — the 10-second submission model does not change. Corridor and area reports are separate flows in the reporting UI, opt-in from a longer-form path or from an aggregation suggestion (see §3).

3. Two paths a corridor / area report gets created

Path A: Auto-suggested from clustered points

When point reports concentrate along a linear or polygonal feature (5+ reports within a 500 ft corridor over 60 days, or 8+ reports within a defined neighborhood boundary over 60 days), Fault Line surfaces a suggestion to the community: “These 7 reports look like they’re part of the same problem. Convert them into a corridor report?”

Any nearby community member can accept the suggestion. Accepting creates a new corridor report, links the underlying point reports to it, and starts a fresh community-verification cycle at the corridor level. Original point reports stay open independently until resolved — the corridor report is an aggregation, not a replacement.

Path B: Resident-initiated

A resident who wants to file a corridor or area report directly can do so through a longer-form flow: draw the segment on a map, describe the pattern of failures, attach photos taken at multiple points along the corridor, categorize the primary and secondary hazard types. This path is for residents who see the systemic problem from the start — a neighborhood association, a block captain, a resident who commutes the segment every day.

Resident-initiated corridor reports enter the same community-verification pipeline: 3 additional reporters must confirm at least 2 points along the corridor before it’s community-verified.

4. Community verification thresholds

Point reports verify at 3 independent reports. Corridor and area reports need a slightly higher standard because they claim more:

• Corridor report: 5+ independent reporters confirming issues at ≥ 3 distinct points along the corridor.
• Area report: 8+ independent reporters confirming issues at ≥ 5 distinct points within the boundary.
• Geographic distinctness: confirmations must be at least 100 ft apart within the corridor / 200 ft apart within the area. One reporter cannot verify a corridor by submitting five reports at the same intersection.

Higher thresholds are not gatekeeping — they’re calibrated to the higher factual claim. A corridor report says “this whole segment is bad,” and needs geographic evidence to that effect.

5. Escalation and demand-letter differences

Corridor reports change the letter template. A point-report demand letter cites a specific GPS coordinate and one hazard; a corridor demand letter cites:

• The segment identifier (street name, from-to intersections)
• The pattern of failures (categories, count, distribution)
• The specific applicable statute at the corridor scale (still MA c. 84 § 15 or equivalents, but framed around the segment)
• A suggested municipal work-order response scope (mill-and-repave, corridor-wide sidewalk audit, signal retiming, etc.)

The letter still says “you send this yourself” — corridor reports don’t change the user-sends posture, only the scope of the notice.

6. Sample corridor report

7. How this integrates with existing methodology

• Shame Index: corridor and area reports are weighted heavier in the underlying calculation because they represent higher-confidence, geographically-distributed evidence. A single corridor report equivalent to ~3 severity-weighted point reports on the Shame Index inputs. Prevents the accountability-arbitrage failure where 10 point closures paper over an ongoing corridor failure.
• Rapid Response Roll: corridor-level resolutions (e.g., a full mill-and-repave documented by community re-photo at multiple points) count as high-value qualifying resolutions. Rank calculation gives them more weight.
• Access & Equity aggregation: area reports that identify a neighborhood-level accessibility failure integrate with Group G environmental-justice aggregation. Both operate at the census-tract or user-drawn polygon scale.
• Briefing packets: corridor reports get their own section in council-member briefings. A three-block corridor with 47 days past deadline is a story worth surfacing separately from the “9 sidewalk defects” count.

8. Guardrails

1. Boundaries must be verifiable. A corridor is defined by a real, mappable segment (street name + intersection endpoints). An area is defined by a census tract or a user-drawn polygon with a maximum size limit (roughly a 0.5-mile radius, or a defined-neighborhood boundary). Nobody can file a corridor report for “my entire town.”
2. Aggregation is community-approved. The auto-suggestion in Path A is a suggestion. Community members convert clustered points into a corridor; the algorithm does not auto-promote clusters into corridor reports without a human accepting the aggregation.
3. Corridors shrink and grow with data. If part of a corridor is resolved (e.g., three of six potholes filled), the corridor report’s active segment is updated. If a corridor grows to include additional points reported after the corridor was created, the boundary can extend. Fault Line tracks both the current state and the corridor’s edit history.
4. Not a substitute for point reports. Residents who see a specific pothole should still be able to file a point report in 10 seconds. Corridor is an aggregation layer, not a replacement.
5. Corridor severity does not dilute point severity. A corridor report cannot be used to claim an individual point is less severe than it actually is (“this pothole is fine because the whole street is bad”). Each underlying point retains its own severity classification.
6. Cross-jurisdiction corridors are split. A corridor that crosses a municipal boundary is automatically split into per-jurisdiction sub-corridors. Fault Line does not attribute one jurisdiction’s failure to another.

9. What still needs to happen before this ships

1. Report schema extension: add report_type enum (point / corridor / area), plus PostGIS linestring and polygon columns to reports table.
2. Auto-suggestion algorithm: nightly job that scans point-report clusters and produces suggested corridor / area aggregations. Suggestion surfaces in the app UI, not in escalation directly.
3. Reporting UI: longer-form flow with map-drawing for resident-initiated corridor / area reports. Uses the existing Leaflet infrastructure in fault-line-web/.
4. Demand-letter template extensions: corridor-scale letter templates that describe segment-level failure and cite the aggregated evidence base.
5. Shame Index weight adjustment: corridor reports weighted at ~3x point reports (calibration determined empirically once the first pilot city has enough data).

Full engineering scope in DEFERRED.md #28.

10. Grant relevance

Corridor and area reports directly enable federal infrastructure grant applications. USDOT Safe Streets and Roads for All (SS4A) awards to segments; FEMA BRIC awards to defined hazard areas; USDOT Reconnecting Communities awards to corridors and neighborhoods. Cities that use Fault Line-generated corridor data in their applications have quantified need analyses that most other applicants can’t produce. See GRANTS.md §4 Tier C.

Not legal advice. Corridor and area demand letters cite the same underlying statutes as point letters, but at segment scale. For a live claim against a municipality, consult a licensed attorney in your state.