Civic Pulse

Civic Pulse is a low-cost emergency routing desk for nonprofits. It turns incoming community needs and live provider capacity into explainable referrals so people are sent to help to the right place.

Comment

Inspiration

During emergencies, help often exists but coordination breaks down. A cooling center may have seats in the morning and be full by noon. A food pantry may still be listed online but out of boxes. A caseworker may know someone needs help now, but not which provider can actually take the handoff.

We wanted Civic Pulse to focus on that operational gap: not discovering services in the abstract, but routing real people to help that is actually available at the moment a referral is made.

What it does

Civic Pulse is an incident routing desk for nonprofit and civic response teams. Coordinators can see incoming community needs, live provider capacity, referral queues, routing decisions, and audit history in one workspace.

The core workflow is simple: select an incoming need, review ranked provider recommendations, inspect the reasons behind the recommendation, and route the referral. When a referral is routed, Civic Pulse updates the need status, writes a referral, stores the routing decision, adjusts provider capacity, and adds an audit event.

The app also includes a simulation control that adds realistic incoming requests through the same database-backed workflow, which makes it easy to demo how the system behaves during an active incident.

How we built it

We built Civic Pulse with Next.js, React, TypeScript, and CSS modules, deployed on Vercel. Aurora DSQL is the source of truth for providers, service capacity, incoming needs, referrals, routing decisions, provider updates, and neighborhood signals.

State-changing workflows are implemented with Next.js server actions. Database access uses Drizzle ORM and the postgres client. The deployed app uses AWS credentials in Vercel to generate fresh Aurora DSQL auth tokens at runtime with the AWS DSQL signer.

The routing engine is deterministic and explainable. It scores providers by service match, available capacity, provider status, neighborhood fit, urgency, and constraints such as no vehicle. Each recommendation includes reason codes that are displayed in the UI and persisted when the referral is routed.

The current data is synthetic for the hackathon, but it is stored and handled like production data. Real sources such as 211 exports, SMS intake, Google Forms, shelters, or provider portals could feed the same incoming_needs table.

Challenges we ran into

The biggest challenge was making the app feel like a real operational workflow instead of a static dashboard. Our first version had useful panels and working capacity updates, but the experience still felt too much like a mock UI. We reworked the product around an active incident routing desk so the user could see work moving through the system.

Aurora DSQL auth also required care. Static DSQL auth tokens expire, which caused production to fail during testing. We fixed this by moving Vercel to runtime token generation through AWS credentials and the DSQL signer.

Another challenge was keeping the design useful without making the architecture expensive. For nonprofit use, we did not want always-on workers, paid model calls, vector databases, or third-party APIs just to make the demo feel impressive. The routing logic had to stay transparent, cheap, and auditable.

Accomplishments that we're proud of

We are proud that the core workflow is real. Routing a need is not a visual trick: it writes records to Aurora DSQL, changes the incoming need status, creates a referral, stores a routing decision, updates provider capacity, and records an audit event.

We are also proud of the explainable routing model. Instead of hiding decisions behind a black box, Civic Pulse shows why a provider was recommended and leaves a trail that a coordinator can review later.

Finally, we are proud that the system is designed with cost and operational realism in mind. It is serverless, database-backed, and intentionally avoids unnecessary infrastructure.

What we learned

We learned that civic tech demos need more than data on a dashboard. They need to show a real workflow, a clear user, and a moment where the product makes a decision easier.

We also learned that synthetic data can feel real when it moves through real product mechanics. Incoming needs, routing decisions, referrals, and capacity updates are all structured as records that could be swapped with real integrations later.

On the technical side, we learned how Aurora DSQL token-based auth works in local and deployed environments, and why runtime token generation is safer than relying on a long-lived static token.

What's next for Civic Pulse

Next, Civic Pulse could add real intake integrations from SMS, 211 exports, shelter forms, or provider check-ins. It could also add role-based access for partner organizations, provider-facing capacity updates, and configurable routing rules for different incident types.

We would also like to add optional AI-assisted intake parsing. The core routing should remain deterministic and auditable, but AI could help turn messy intake text into structured fields such as need type, urgency, location, and constraints.

Longer term, Civic Pulse could become a lightweight coordination layer for nonprofits and city partners during heat emergencies, floods, food distribution surges, shelter overflow, and other moments where routing people to the wrong place has real consequences.

Feature checklist

  • Tracks incoming needs during an active incident.
  • Shows live provider capacity and freshness.
  • Recommends providers with explainable deterministic scoring.
  • Creates referrals from selected incoming needs.
  • Records routing decisions and audit events in Aurora DSQL.
  • Updates provider capacity after a handoff.
  • Simulates new incoming requests through the same database-backed workflow.

Technical summary

Civic Pulse is a Next.js app deployed on Vercel. The UI is built around a live incident routing desk, provider capacity board, referral queue, neighborhood signal map, and audit trail.

The backend uses Next.js server actions for state-changing workflows. Aurora DSQL is the source of truth for providers, service capacities, incoming needs, referrals, routing decisions, provider updates, and neighborhood signals. Drizzle ORM and the postgres client handle database access, with AWS DSQL token support for secure connections.

The routing engine is a TypeScript module that ranks providers by need match, capacity, status, neighborhood, urgency, and constraints. Every recommendation includes reason codes that are shown in the UI and persisted when a referral is routed.

Built With

Share this project:

Updates