> For the complete documentation index, see [llms.txt](https://docs.racemap.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.racemap.com/glossary.md). # Glossary Common terms used across Racemap live tracking — with their synonyms. This list is intended to help users find documentation no matter which term they search for, and to guide AI-assisted documentation tooling toward the preferred vocabulary. *** ## Read **Preferred term:** read\ **Synonyms:** detection, passing, ping, trackping, timestamp\ **Context:** prediction feature, timing integrations A single data point recorded when a participant is observed by a timing reader or GPS device. In the prediction and timing context, **read** is the preferred term. The word **detection** is common in integrations with external timing systems (e.g. ChronoTrack, RACE RESULT). **Passing** appears in some timing-system UIs and older documentation. **Ping** and **Trackping** are RACE RESULT specific for Mobile Trackbox detections. *** ## Auto-pausation **Preferred term:** auto-pausation\ **Synonyms:** auto-deactivation, automatic shutdown, automatic pause The automatic pausing of the Data Feed API module that occurs on the first API request arriving more than 2 hours after an event's end time. Auto-pausation prevents unexpected billing costs when a feed is left active after the event finishes. Repeating (live loop) events are excluded. See [Auto-pausation](/api/auto-pausation.md). *** ## Billing cycle **Preferred term:** billing cycle\ **Synonyms:** event cycle, billing period\ **Context:** billing A 7-day period that live tracking is billed against. A cycle is counted in **whole UTC calendar days** and is anchored to the first UTC day the event is active; it covers that day plus the following 6 UTC dates and is billed once. Because days are counted in UTC — not local time — a long event that starts shortly before 00:00 UTC can touch an 8th UTC date and roll into a second cycle. See [Billing cycles](/billing.md) and the related [Auto-pausation](#auto-pausation). *** ## Mapping **Preferred term:** mapping\ **Synonyms:** auto-mapping, position on track, placing\ **Context:** prediction feature One candidate position on the shadowtrack for a single [read](#read). A read can produce several mappings — for example when a reader stands where the course passes itself in laps. The prediction judges mappings, never the read itself, and accepts at most one mapping per read. Every mapping ends in one of three outcomes: * **accepted** — the position the prediction uses for that read. * **rejected** — tested and dropped, with a reason: too fast or too slow for the sections in between, too close to the previous accepted read, outside every section, and others. * **not examined** — never tested, because another mapping of the read was accepted first, or the read was dropped before its mappings were judged. On a course without loops a read has at most one mapping, so read and mapping look the same. They differ as soon as the course passes a reader twice. *** ## Rejected read **Preferred term:** rejected read\ **Synonyms:** dropped read, filtered read\ **Context:** prediction feature A [read](#read) the prediction did not use. That happens in two ways: * A filter drops the read before any of its mappings is judged: it lies outside the event's time window, its signal strength is below the RSSI threshold, or no point of the track lies within the maximum distance. * None of its [mappings](#mapping) is accepted. The read then carries the reasons of its rejected mappings. A read with an accepted mapping is an **accepted read**, even when some of its other mappings were rejected. The Analyse tab of the prediction dashboard lists every read with all its mappings and the reason for each rejection. *** ## Timekeeping Point **Preferred term:** timekeeping point\ **Synonyms:** split, checkpoint, geofence, virtual checkpoint, timing point A virtual location defined on the course at which reads are recorded for timing or ranking purposes. The API field name is `timekeepings` (plural). In the UI and documentation the terms *split*, *checkpoint*, and *geofence* appear interchangeably — all refer to the same concept. *** ## Reader Location **Preferred term:** reader location\ **Synonyms:** hardware position, reader position Where the hardware of a timing system without GPS stands. Reads of its reader IDs that arrive without coordinates are placed there. One location can hold several reader IDs; one reader ID can only be at one location. Set under Prediction → Status → Timing System. Not a [timekeeping point](#timekeeping-point): a reader location places reads, a timekeeping point measures times. *** ## Timing Reader **Preferred term:** reader\ **Synonyms:** decoder, timing system, Track Box, antenna Hardware or software positioned along the course that records reads as participants pass. Different vendors use different names: RACE RESULT uses *decoder*, Racemap's own hardware is the *Track Box*, and the general abstraction in the API and documentation is *reader*. *** ## Data Feed **Preferred term:** Data Feed\ **Synonyms:** Data API, live API, datafeed, data feed module The real-time HTTP API that serves current event data — participant locations, ranks, times — to external consumers such as TV graphics, custom dashboards, or result systems. Enabled per event via the Data API settings. See [Data API overview](/api.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.racemap.com/glossary.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.