We will be undergoing planned maintenance on Oct 7th 6:00AM UTC / Oct 7th 2:00AM ET

EveryWay

EveryWay is a live digital twin that senses changes in physical spaces and reroutes people in real time based on their mobility, sensory, and situational needs.

Comment

Inspiration

Accessibility isn't static. That's basically the entire reason we built EveryWay.

A normal map can tell you that a ramp exists, that a building has an elevator, or that a path is technically accessible. What it usually cannot tell you is whether that ramp is blocked right now, whether the elevator is down, whether a hallway is packed, or whether that route even makes sense for the person using it.

And accessibility isn't limited to a permanent medical condition either.

While we were talking to people at HackGT, one of the examples that stuck with us was someone carrying a massive Pelican case around Virginia Tech. There was nothing medically preventing him from taking a certain route, but in that moment stairs, narrow paths, distance, and crowding suddenly mattered a lot more.

The same thing can apply to someone pushing a stroller, pulling luggage, moving equipment, dealing with an injury, avoiding loud environments, or simply being under a serious time constraint.

So over the past two sleepless nights, we built EveryWay: a system that models the physical world as it actually exists right now, then figures out the best way through it based on what you need right now.

What it does

EveryWay is a live digital-twin navigation platform.

Instead of treating accessibility like a checkbox, EveryWay combines live information about the physical environment with functional and situational constraints from the user.

That can include things like:

  • needing a step-free route
  • avoiding steep slopes
  • preferring wider paths
  • avoiding dense crowds
  • avoiding excessive noise
  • carrying something heavy or bulky
  • needing spoken or visual navigation
  • simply wanting the fastest viable route under the conditions around you

The important distinction is that we don't need to reduce somebody to a diagnosis. We care about what actually changes the route.

For our HackGT demo, we built a physical miniature environment with multiple possible paths through it.

A user begins with a route through the North Ramp. We then physically place an obstruction in that path.

Our time-of-flight sensor detects that something has changed.

That observation flows into EveryWay's backend, the state of the digital twin changes, the old route becomes invalid, and the user is rerouted through the East Path.

No refresh button, and no manually changing the map. The physical world changes, and EveryWay reacts.

At the same time, that single event can be seen from three completely different perspectives:

  • on a phone, the traveler gets a new route and an explanation of why it changed
  • on iPad, the environment exists as an interactive 3D digital twin that can be rotated and inspected
  • on an operator dashboard, the venue can see how that obstruction affected access through the space

How we built it

We ended up building EveryWay as a six-repository system because the project made a lot more sense once each piece had one actual job.

Beacon — the physical world

Beacon is our sensing layer.

For the physical demo, we use an ESP32-C3 SuperMini connected to a VL53L1X time-of-flight distance sensor.

Beacon does not try to make high-level accessibility decisions itself. It reports what it actually observes: for example, the measured distance to an object.

That distinction ended up being really important. The sensor should say, essentially, "something is 84 millimeters away." It should not decide by itself that "this path is inaccessible."

Conduit — communication

Conduit is the nervous system.

It ingests readings from Beacon, validates them, maps devices into the physical environment, and moves live state between the different parts of EveryWay using HTTP, WebSockets, and our realtime event system.

It is also what lets the phone, digital twin, and operator interface all stay synchronized without needing to refresh.

Atlas — the world

Atlas is our live representation of the physical world.

It stores the graph of the environment: buildings, paths, ramps, stairs, widths, slopes, entrances, and other properties.

On top of that static geometry, Atlas maintains the live state of the environment: obstructions, crowding, noise, confidence, timestamps, and provenance.

In other words, Atlas doesn't just know that a ramp exists.

It knows what is happening to that ramp right now.

Enigma — the brain

Enigma takes the current world from Atlas and asks what that world means for this particular person.

The actual routing core is deterministic. If someone requires a step-free path, an edge with stairs is eliminated. If a path is blocked, it is eliminated. Preferences like crowding and noise can then change which of the remaining routes is preferred.

Around that deterministic core, we built our intelligence layer for interpreting user context, explaining decisions, and connecting our AI integrations.

The goal is not to let an LLM randomly choose where somebody should walk. The goal is to use AI where it actually helps while keeping the safety-critical routing logic fast and understandable.

EveryWay — what the user actually sees

The EveryWay repository contains the human-facing product.

We built separate interfaces for the different ways someone interacts with the system:

  • a mobile navigation experience for the traveler
  • an interactive 3D digital twin for the iPad
  • an operator dashboard for larger screens

The 3D twin is built with Three.js and React Three Fiber and directly reflects the state coming from the backend.

So when our physical sensor detects an obstruction, the thing you see change in 3D is not an isolated animation. It is the visualization of the same state that caused Enigma to recompute the route on the phone.

Harbor — keeping the world current

The last piece is Harbor, our community verification layer.

Not every part of the physical world will have a sensor on it, and even sensor data can become stale.

Our idea is that when EveryWay needs updated information about a location, nearby users can receive a small verification job. They can go to the location, submit evidence about its current condition, and help update Atlas.

We designed Harbor so those contributions can also be rewarded, including through Solana-based incentives.

That gives EveryWay a path toward keeping a large digital twin current even when perfect sensor coverage is impossible.

The physical demo

For us, the most important part of the project was making this more than a maps mockup.

Our breadboard uses an ESP32-C3 and a VL53L1X time-of-flight sensor to observe the physical model.

That measurement enters the exact same data pipeline that the rest of the platform uses.

So the full loop is:

physical world → Beacon → Conduit → Atlas → Enigma → EveryWay

Place an obstruction in the physical environment and the digital environment changes with it.

The route changes with it.

And the interfaces around that environment all change with it.

That is the central idea behind EveryWay.

Challenges we ran into

The hardest problem was not really the 3D model, the sensor, or even the routing algorithm independently.

It was getting all of them to agree about the same world at the same time.

We had to deal with duplicate and out-of-order sensor readings, reconnecting WebSockets, route sessions shared between multiple devices, stale state, resets, hardware failure cases, and keeping several repositories from independently inventing slightly different versions of the same contract.

At one point we had a phone interface reporting one navigation profile while another interface was affecting the same shared session differently. That kind of bug taught us very quickly that a realtime system cannot have five different sources of truth.

Eventually we locked the architecture down so Atlas owns world state, Enigma owns routing decisions, and the frontend only presents what the backend actually decided.

That made everything much more reliable.

What we're proud of

We're proud that EveryWay stopped being a collection of mockups and became one connected system.

The same real-world event can move through the entire stack:

sensor reading → world-state change → route recalculation → 3D update → mobile reroute → operator impact

And it happens without refreshing the page.

We're also proud that the project grew beyond our original understanding of accessibility.

We started thinking primarily about physical disability. By the end, we were thinking much more generally about the mismatch between a person's current constraints and an environment that was designed around some assumed "default" person.

Those constraints can be permanent, temporary, medical, situational, sensory, physical, or simply practical.

What we learned

The biggest thing we learned is that accessibility is not binary.

A route can technically be "accessible" while still adding five minutes, forcing somebody through a crowded space, requiring a much longer walk, or being completely unreasonable for what that person is carrying.

The interesting problem isn't just asking:

"Is this place accessible?"

It is asking:

"Accessible for whom, under what conditions, and right now?"

We also learned how important it is to separate observations from conclusions.

A sensor measures distance.

Atlas maintains what is known about the world.

Enigma reasons about what that world means for a person.

Keeping those concepts separate is what allowed us to make the system modular instead of building one giant application that could only work for our HackGT table.

What's next

The HackGT model is obviously a small representation of a much bigger idea.

In a real deployment, EveryWay could combine dedicated sensors with infrastructure that already exists: cameras, occupancy systems, building data, elevator telemetry, community reports, and other sources of live environmental information.

We also want to expand the digital-twin side into richer point-cloud and multi-sensor representations so Atlas can construct and continuously update environments rather than requiring everything to be modeled manually.

From there, the same system could work across campuses, airports, convention centers, hospitals, transit systems, malls, warehouses, and cities.

The end goal is pretty simple:

Physical spaces are usually designed around an assumed default person.

EveryWay lets the environment adapt to the person instead.

Use EveryWay, every day.

Built With

Share this project:

Updates

Submission history