# SonitorOne Vector™ Documentation

This folder is the documentation for SonitorOne Vector. It has two halves:

| If you want to… | Read |
| :--- | :--- |
| **Use the app**: find equipment, read the map, run the morning report, manage users | [User Guide](user-guide/) |
| **Understand how it works**: what problem it solves, how predictions are made, how data flows, how it is secured | [Engineering Guide](engineering/) |

Every page describes what the app **actually does today**, checked against the code. Where the app's own wording promises more than the code does, the page says so in a **"How it really works"** or **"Current limitation"** note. We would rather you trust these pages than be surprised in front of a customer.

---

## User Guide

| # | Page | What it covers |
| :--- | :--- | :--- |
| 0 | [Introduction](user-guide/00-introduction.md) | What Vector is, who it is for, and the five ideas you need to know |
| 1 | [Getting Started](user-guide/01-getting-started.md) | Signing in, roles, the screen layout, your first session |
| 2 | [Loading Data](user-guide/02-loading-data.md) | Facility model, tag CSVs, the live feed, and the Clear/Purge buttons |
| 3 | [Predictive Locator](user-guide/03-predictive-locator.md) | Searching and filtering equipment, reading certainty, exporting |
| 4 | [Floor Map](user-guide/04-floor-map.md) | Floor plans, layers, and what each dot means |
| 5 | [RF Mesh Tracer](user-guide/05-rf-mesh-tracer.md) | The per-tag signal graph |
| 6 | [Fleet Telemetry](user-guide/06-fleet-telemetry.md) | Fleet totals and the live feed inspector |
| 7 | [Morning Report](user-guide/07-morning-report.md) | The daily diagnostic brief and shift checklist |
| 8 | [Field Notes](user-guide/08-field-notes.md) | Recording where equipment was really found |
| 9 | [Admin](user-guide/09-admin.md) | Users, roles, and the live feed settings |
| 10 | [Security & PHI](user-guide/10-security-and-phi.md) | The policy switches and audit log |
| 11 | [Docs & Support](user-guide/11-docs-and-support.md) | The in-app reference tab |
| 12 | [Glossary](user-guide/12-glossary.md) | Every term in one place |
| 13 | [Troubleshooting & FAQ](user-guide/13-troubleshooting-faq.md) | Common questions and fixes |

## Engineering Guide

| # | Page | What it covers |
| :--- | :--- | :--- |
| 1 | [Vector in Plain English](engineering/01-vector-in-plain-english.md) | The whole story in one read: the problem, the idea, the limits |
| 2 | [RTLS Primer](engineering/02-rtls-primer.md) | Ultrasound, USIDs, Wi-Fi fallback, floor association, Keep-Location |
| 3 | [How Prediction Works](engineering/03-how-prediction-works.md) | Fingerprints, scoring, anchor consensus, confidence, with a worked example |
| 4 | [Architecture](engineering/04-architecture.md) | The pieces: browser app, serverless functions, storage, daemon |
| 5 | [Data Flows](engineering/05-data-flows.md) | Step by step: model import, CSV import, live feed, persistence, purges |
| 6 | [Security Model](engineering/06-security-model.md) | Sign-in, tokens, roles, passwords, ingest key, browser policy, data handling |
| 7 | [Daemon & Infrastructure Health](engineering/07-daemon-and-infrastructure-health.md) | The on-server collector and the planned infrastructure module |
| 8 | [Testing & Verification](engineering/08-testing-and-verification.md) | Test suites and how we verify numbers |
| 9 | [Known Limitations & Accuracy Notes](engineering/09-known-limitations.md) | Everything we know is incomplete or overstated, in one list |
| 10 | [Roadmap](engineering/10-roadmap.md) | What is coming next |

---

## Adding documentation for a new feature

Vector will keep growing. When a feature ships:

1. Copy [`user-guide/_feature-template.md`](user-guide/_feature-template.md) to a new numbered page, e.g. `user-guide/14-infrastructure-health.md`.
2. Fill in every section. Describe what the feature does **in the code today**, and put anything planned under "Coming later".
3. Add a row to the User Guide table above.
4. If the feature changes how data flows or how predictions are made, update the matching Engineering page too.
5. If the in-app wording overstates what the feature does, add it to [Known Limitations](engineering/09-known-limitations.md) until the wording is fixed.

**House rules for these docs**
- Plain English first. Put formulas after the explanation, never instead of it.
- Terminology: **ULE Precise Tag**, **ULE Precise Location**, **Wi-Fi Fallback Asset**. Do not use "ground truth" or "predictor tag".
- Wi-Fi predictions are **room-level estimates**, not sub-meter positions.
- Never put real customer data, credentials or keys in these pages. Use made-up examples.

*Last reviewed against the code: 25 September 2026 (`main` @ `9b6810b`).*