A clear account of what has been checked, what exists in software, and what still needs evidence. This update describes development status as reviewed on October 21, 2026; it is not a hardware performance report.
Valkor is in development. Hardware checks and synthetic routing experiments are separate workstreams. Dynamic emergency routing is not deployed as an active school safety system.
Development progress · reviewed October 21, 2026
Hardware checks, simulation features and future evaluation each answer different questions. Progress in one area does not establish performance in another.
Completed checks
Development hardware and test tags have been acquired, flashed and configured. Informal tests with one antenna and one tag explored directional reception at different distances and through walls.
These recorded observations establish initial reception only. They do not establish positioning accuracy, reliable room detection or school readiness.
Existing software
The research prototype supports building graphs, shortest path search, scheduled closures and reopenings, alternative exits, and separate simulation truth and reported observations. Comparison tools preserve a baseline while changing a selected connection.
Explicit outcomes include unreachable destinations and insufficient information. These are implemented simulation features, separate from a validated hardware connection or operational deployment.
Evaluation underway
Current simulation work examines doorway flow, congestion, controller behavior and incomplete runs. Evaluation must show where the model fails as well as where a route can be found.
Hardware evidence remains limited to the recorded initial checks. We are not reporting a completed multi antenna evaluation, measured positioning accuracy or a successful school pilot.
Future milestones
Next milestones are documented testing with multiple antennas and tags, integration of observations with freshness and confidence, and independent review of the methods. A school evaluation would need its own agreed scope and success criteria.
No dates or outcomes are promised. Hardware reliability, staff usefulness and any future routing evaluation need separate evidence.
For hardware, a useful report needs known test positions, an independent reference, timestamps, device configuration and the conditions of each run. Accuracy, latency and packet loss should be reported only when the measurements support them; unavailable measurements should stay unavailable.
For simulation, a useful comparison preserves the starting population, layout and random seed, changes one condition, and reports both completed and unfinished trips. Graph reachability and movement completion are different outcomes. If occupants remain unfinished at the observation horizon, the run must be reported as incomplete rather than assigned a clearance time.
Independent technical review and a separately agreed school evaluation remain future milestones. Passing software checks does not establish reliable school observations or emergency readiness.
How the work connects
Valkor brings together two connected development efforts: indoor location hardware that supplies observations, and a routing engine that evaluates a building model and reported conditions. Their integration is a development milestone; the routing experiments currently use simulated inputs.
Tags and antennas provide observations about a device’s presence or direction. An observation needs a source and timestamp, with quality and confidence where available. A missing signal leaves a gap in the evidence; a badge detection alone does not prove who is present or whether a doorway is usable.
Rooms, junctions and exits form a graph connected by doors and corridors. The engine combines that model with reported closures and available observations to find candidate paths. A closure must be supplied by a defined source; location hardware does not automatically detect hazards or blocked doors.
The output should explain the route, the inputs used, and whether the evidence supports a result. Known closures can make an exit unreachable; stale or conflicting reports can leave insufficient information. Any future operational use would require validation and established staff and responder procedures.
A connected path is a statement about the model and its inputs. It does not establish that a route is safe, accessible to a particular person, or suitable for an emergency.