Location observations
Record what the hardware observed, when it was observed, and what quality or confidence information is available. Missing observations remain missing.
Location Hardware & Routing Research
Two connected parts, with distinct evidence.
Location hardware supplies observations. The routing engine evaluates them alongside a building model and reported conditions. Integration is in development; current routing experiments use simulated inputs and do not establish emergency performance.
From observations to candidate routes
Tags and antennas provide observations with a source and timestamp. The intended integration maps those observations to a building model while preserving their freshness, quality and uncertainty. Doorway closures and other conditions must come from defined reports; a location signal alone does not establish that a path is usable.
Building model and conditions
Represent rooms, junctions, doors, corridors and exits as connected points and paths. Apply reported availability before comparing candidate routes.
Explicit outcomes
Report a candidate path when the available inputs support it. Distinguish known disconnection from insufficient information caused by stale, conflicting or missing reports.
The public research demonstration illustrates this graph policy with fictional data. It does not connect to live hardware, run a crowd model, or provide emergency instructions.
Infrastructure layer and Valkor layer
Indoor location infrastructure may provide tags, antennas, position estimates, area observations and device health information. The software layer is being developed to turn supported observations into reviewable context. Available fields and behavior depend on the integration and must be checked rather than assumed.
Infrastructure Layer
Tags / badges
Anchors / base stations
Positioning engine
Area / region data
Attendance primitives
Roll call data
Alarm primitives
Historical tracks
Device-health signals
Valkor Operations Layer
School zone mapping
Confidence and freshness
Pass accountability
Attendance reconciliation
Incident lifecycle
Staff response
Audit logs
Pilot reports
Privacy controls
The lists describe integration areas under consideration. They are not a verified list of capabilities provided by the current hardware setup.
How Valkor works
The planned integration would normalize supported vendor observations for authorized staff review. Each link in the chain needs its own reliability, uncertainty and failure checks.
Approved Badges
School RTLS / Anchor Infrastructure
Parser + Vendor Adapter
Valkor Canonical Event Contract
Valkor Event Engine
Confidence + Freshness Layer
Incidents, Attendance, Passes, Staff Response
Pilot Proof Report
Plain-language integration terms
RTLS
Real-Time Location System. Indoor positioning infrastructure used to locate approved badges or assets inside buildings.
Tags / Badges
School-issued or school-approved wearable devices that broadcast or communicate wireless signals.
Anchors / Base Stations
Fixed devices that receive badge signals and help the positioning engine estimate area or zone.
Gateway
A backhaul device or network path that moves local hardware data into the server/platform.
Parser
Decodes raw incoming data into usable fields such as tag ID, zone, timestamp, battery, event type, and confidence.
Adapter
Converts vendor-specific data into Valkor's internal standard format.
Canonical Event Contract
A shared internal format for observations. Each provider still needs a separately tested adapter; a common format does not establish that an integration works.
Hardware supplies observations, not ground truth. Location estimates and candidate routes need clear limits and independent evaluation.
Request a limited pilot review.
Pilot reviews cover operational pain points, privacy and governance boundaries, infrastructure readiness, pilot scope, reliability expectations, success metrics, and end-of-pilot reporting.