PathPulse

Inspiration

This project started with someone close to us who is blind/visually impaired. Seeing how much navigating unfamiliar spaces can depend on reliable information made us realize that accessibility isn't just about whether a building has an elevator or accessible entrance. It's about whether that infrastructure is actually usable right now.

A map might say an elevator exists, but what happens when it's broken? What if an accessible entrance is temporarily closed? What if the information online hasn't been updated in weeks?

That led us to a simple idea: what if accessibility information worked more like a live network than a static map?

We built PathPulse to answer that question.

What it does

PathPulse is a live accessibility agent that users can interact with through Relay. Users can ask questions like:

"What's the most accessible route to this building?"
"Is the elevator working?"
"Where is the nearest accessible entrance?"
"Reroute me if there's a broken elevator."

PathPulse combines a live shared world model with autonomous verification. SpacetimeDB maintains the real-time state of paths, elevators, entrances, and accessibility conditions. When information becomes stale or uncertain, Fetch.ai agents can independently scout and verify it. Relay provides the conversational interface through which users interact with PathPulse.

Instead of simply returning a route, PathPulse can explain why it chose that route and automatically adapt when conditions change.

How we built it

We designed PathPulse around a live accessibility graph where paths and infrastructure have changing states and confidence levels.

SpacetimeDB acts as the real-time source of truth, allowing route changes and accessibility reports to propagate immediately. We built the routing and confidence logic so that fresh reports can reinforce existing information, while stale or conflicting reports reduce confidence over time.

Relay powers the conversational agent experience, allowing users to interact with PathPulse naturally rather than navigating a complicated accessibility interface.

Fetch.ai provides the verification layer. When PathPulse encounters information that may be stale or uncertain, autonomous scout agents can investigate and return evidence that updates the shared world state.

We also built a live dashboard to visualize the accessibility network, evidence behind reports, agent activity, and route changes.

We used Cursor extensively throughout development to help us iterate quickly across the Next.js frontend, TypeScript backend, SpacetimeDB module, agent runtime, and Fetch.ai integration. We still had to design the architecture, reason through the routing and confidence models, debug integrations, and test the resulting system end-to-end.

Challenges we ran into

One of our biggest challenges was designing the confidence system. We needed PathPulse to avoid treating every report as absolute truth while still responding quickly when something changes. We developed a temporal confidence model where information becomes less reliable over time and corroborating or contradicting reports can change that confidence.

Another challenge was coordinating multiple systems with different roles. SpacetimeDB needed to maintain a consistent live state, Fetch.ai agents needed to verify uncertain information, and Relay needed to make the entire system feel like one simple conversational experience.

We also had to think carefully about uncertainty and safety. PathPulse should never pretend that an unverified report is fact. If the system cannot confirm something, it communicates that uncertainty instead of fabricating an answer.

Accomplishments that we're proud of

We're especially proud that we built more than a chatbot or a static accessibility map. PathPulse is a living system where information can change, become uncertain, trigger autonomous verification, and affect routing in real time.

We're also proud of how the three sponsor technologies fit together:

Relay makes the accessibility network conversational.
SpacetimeDB makes it live and synchronized.
Fetch.ai makes it capable of autonomously verifying information.

Most importantly, we're proud that the project started from a real accessibility problem and turned that problem into a technical challenge: how do you build navigation that can reason about a world that changes?

What we learned

The biggest thing we learned was that real-time information is only useful if you can trust it. It isn't enough to collect reports; the system needs to understand when information is old, conflicting, or uncertain.

We also learned how powerful it can be to treat accessibility as a dynamic network rather than a static property of a place. A building isn't simply "accessible" or "inaccessible." Its accessibility can change minute by minute.

Finally, we learned a lot about building with multiple emerging technologies at once. Connecting an agent interface, real-time database, autonomous agents, routing logic, and a visual dashboard forced us to think carefully about how each component should communicate and where responsibility for each decision should live.

What's next for PathPulse

We want PathPulse to eventually work across entire campuses and cities rather than a single demo environment. Future versions could integrate building sensors, staff reports, crowdsourced accessibility updates, and computer vision to continuously improve the accessibility graph.

We also want to expand beyond mobility. PathPulse could eventually support people with different accessibility needs, including low-vision navigation, automatic-door requirements, crowd avoidance, and other personalized route preferences.

Our long-term vision is simple: accessibility information should be as alive as the world it describes.