Work
What we build, what runs today, and what is still being designed. Every line here carries its own status.
Five pieces
Guidance through a journey needs five things, whatever the journey is. A hospital corridor, a railway platform, and a treatment plan that continues at home all use the same five.
- Places
- Levels, rooms, entrances, lifts, and the connectors between them.
- Sequence
- The order of steps, including which ones depend on which.
- Time
- How long each step takes, and how long the queue in front of it runs.
- Handoff
- Who owns the next step, and what they need when you arrive.
- Guidance
- The surface that tells one person what to do now.
What runs today
| Capability | Status |
|---|---|
| Multi-level routing across floors and connected wings | Live |
| Wall avoidance, door punches, and turn penalties so routes read naturally | Live |
| Cross-level connectors for lifts, stairs, and bridges | Live |
| QR anchoring at entrances and junctions | Live |
| Manual anchoring for anybody who starts mid-route | Live |
| Shareable links per destination | Live |
| Operations console with venue controls | Live |
| Multi-venue data pipeline, from CAD to routable map | Live |
| Journey view with ordered steps and durations | In design |
| Queue estimate from observed service rate | In design |
| Departure time calculated from walk time | In design |
| Procedure checklists authored by a department | In design |
| Hospital information system and appointment feeds | Exploring |
| Crowd forecasting from historical movement | Exploring |
The map layer
A building arrives as CAD files and floor plans. The pipeline turns those into a routable graph: coordinates, pathways, doors, and the vertical connections between levels. Routing combines a grid search with a pathway graph, applies wall avoidance and door punches, and penalises unnecessary turns so the directions match the way a person would give them.
Anchoring is how a route knows where it starts. A code at an entrance fixes a position, and manual anchoring covers everybody who begins somewhere else. Once a position is known, every instruction after it is measured from there.
The journey layer
This is the layer being built into the pilots. A journey is an ordered list of steps with durations, dependencies, and an owner for each one. The map supplies walk times. The queue estimate supplies the time to start walking. The sequence supplies the order, and re-plans when a step slips.
The queue estimate is the piece worth explaining, because it decides whether the layer works without any hospital system. The first version reads the current token from staff entry or from the counter board, measures how fast the counter has been serving, and subtracts the walk time. That produces the sentence a person needs: leave now, you will arrive three minutes early. Reading tokens directly from a hospital information system makes the estimate exact, and that work depends on per-vendor integration.
The operations side
The same map that guides a visitor shows the venue where people stall. Which entrances get used, where people stop and ask, how long a counter takes to serve, and which corridors carry the most traffic at nine in the morning. For a hospital, that is a throughput conversation. For a mall, it is a foot flow conversation. The console that publishes status and controls a venue runs today.
How we work with a venue
We build from floor plans, deploy in one area, watch what happens for four weeks, and publish what we found. If a wider deployment makes sense, we price it before the pilot ends. If it does not, we say so. The pilot programs describe the details.
Where this is going
The five pieces stay the same as venues change. Adding an airport, a campus, or a convention centre means new map data and a new journey, which is a data exercise rather than a rebuild. The harder work sits in time and sequence: better queue estimates, crowd forecasting, and re-planning that holds up on a bad day.