Neighborhood Fixer

Neighbors combine evidence in one Strands-assisted civic case, approve one exact report, and verify whether the repair really happened.

Comment

Report once. Follow through together.

Neighborhood Fixer is a consent-driven neighborhood case manager that turns scattered reports about damaged curb ramps, potholes, and blocked walkways into one accountable shared case.

The problem we’re solving

Reporting a public-space maintenance issue is rarely just one form. Residents must document what happened, avoid duplicate reports, determine which agency may be responsible, preserve evidence, and follow the case after it is filed. Existing workflows usually treat every person and every report as an isolated transaction, so neighbors cannot easily combine observations, approval can drift away from the exact report a resident reviewed, and an agency’s administrative closure can be mistaken for a physical repair.

Who it’s for

Neighborhood Fixer is for residents and neighborhood groups who need a clearer way to coordinate around shared public-space problems. It is especially relevant to people who depend on accessible sidewalks and curb ramps—including people using wheelchairs, mobility aids, or strollers—and to neighbors who have each observed the same issue but do not want to create disconnected duplicate reports.

Why it matters

Neighborhood infrastructure is shared, but the burden of reporting and following through is usually fragmented. One trustworthy case can reduce duplicate effort, preserve a clearer evidence trail, keep consequential actions under human control, and show both the agency’s status and whether residents believe the problem was actually fixed.

How it works

Residents contribute a description, confirmed location, and reviewed photo. Restricted agents separate observable facts from claims and unknowns, compare nearby incidents, and propose a registry-grounded route. The resident decides whether to link an observation to an existing incident or create a distinct case.

Multiple residents can follow one canonical incident while keeping private evidence and contact details isolated. Before any external action, the report owner reviews an immutable revision containing the exact recipient, wording, fields, contacts, and attachment hashes. A deterministic browser executor may act only after that explicit approval. If a write may have succeeded but its receipt is lost, the workflow reconciles the original attempt instead of blindly sending another report.

Agency status and physical resolution remain separate: a closed ticket requests resident verification rather than declaring the issue fixed.

AI architecture

Neighborhood Fixer treats AI as a constrained reasoning layer—not as the authority that approves or executes a civic report.

Request and orchestration path

The React/Vite client authenticates residents with Clerk and sends typed commands to FastAPI. The backend validates the resident, session, and server-owned workspace before any reasoning begins. In AWS, API Gateway and Lambda persist case state with DynamoDB conditional transactions and private encrypted S3 storage. Step Functions Standard owns the durable workflow and invokes Amazon Bedrock AgentCore Runtime, where a fresh case-scoped Strands graph uses Amazon Bedrock for each reasoning phase. The default budget is 120 seconds, 8 model turns, and 16 tool calls.

Specialized agents

  • Issue Analyst: Reads only authorized, sanitized evidence; verifies each photo against its SHA-256 hash; separates visible facts, resident claims, and unknowns; and checks the permitted nearby-case set before proposing possible matches.
  • Routing Specialist: Uses required jurisdiction, ownership, and versioned-registry tools. It can select only exact agency names, capabilities, review dates, and source references from the pinned registry. Unsupported or unconfirmed cases become clarification or assisted handoff—not an invented destination.
  • Case Coordinator: Rechecks routing, preserves the resident-confirmed category, and proposes exact report wording or another bounded next action. It can prepare an approval request, follow-up, or verification prompt, but it cannot approve, send, publish, escalate, or change the recipient.

Guardrails and deterministic validation

Agent responses must satisfy strict Pydantic schemas; extra fields are rejected. Required-tool gates prevent a model from finishing without reading the evidence or registry needed for its role. Workspace and evidence ownership are checked before tools run, evidence hashes are checked before image analysis, and every routing proposal is revalidated against coverage, category support, resident-confirmed location, public-space status, and automation authorization. Photos, resident text, registry content, and portal pages are all treated as untrusted data rather than instructions. Sanitized activity records capture tool name, timestamp, outcome, and provider—not prompts, private arguments, private content, or model reasoning.

Human approval and execution boundary

AI output remains a proposal. The deterministic domain layer creates an immutable report revision containing the exact recipient, wording, fields, contacts, payload hash, attachment hashes, approver, and expiry. Only the reporting resident can approve that exact revision. After approval, an atomic reservation admits one execution, and a deterministic allowlisted browser worker may submit only the frozen payload to the fictional portal. If a write may have succeeded but its receipt is lost, the case enters OUTCOME_UNKNOWN and performs receipt lookup only; it does not blindly resubmit. Agency ticket status and resident-confirmed physical resolution remain separate.

Verified boundary

The deployed AWS path has completed real private-photo analysis through S3, Step Functions, AgentCore Runtime, and Bedrock/Strands. Two residents were validated through analysis, canonical case linking, registry-grounded routing, and one unchanged immutable shared draft with owner-only evidence and draft access. Signed AgentCore Browser CDP connections currently return HTTP 404 before navigation, so the cloud approval-to-receipt leg—and any cloud agency write or receipt—is not claimed. The complete fictional flow passes locally with real Chromium and visibly labeled deterministic simulated AI. Real municipal submission remains disabled.

Key features

  • Evidence-aware reporting: Explicit unknowns and reviewed previews.
  • Neighbor-confirmed linking: One canonical incident instead of duplicate reports.
  • Immutable human approval: Bound to the exact payload and attachment hashes.
  • Durable browser workflow: Idempotent execution with ambiguous-outcome reconciliation.
  • Honest resolution tracking: Agency status remains separate from resident-confirmed physical resolution.
  • Owner-scoped privacy: Evidence and consent controls remain independent.
  • Local and AWS modes: React/FastAPI locally, plus an AWS serverless deployment.

Scope note: The current integration uses only a fictional Demo Borough portal; real municipal submission is disabled.

Built With

Share this project:

Updates

Submission history