# Checkpoint Promotion and Granularity

Checkpoints in **RUFUS Race Manager (RRM)** are designed to be flexible and intelligent. They not only record passings at specific points on the course but also adapt dynamically when conditions change, giving race organizers maximum control and reliability.

## Promotion of Passings

If a checkpoint in the race plan is **closed**, RRM does not simply discard passings that occur at that point. Instead, it automatically **moves them forward** to the next available checkpoint in the participant’s race plan.

<figure><img src="/files/jqBu7cBIBLXIUNXmQcYf" alt=""><figcaption><p>Checkpoint Promotion Diagram</p></figcaption></figure>

* Example: A passing is recorded at the *Start* checkpoint after it has been closed. The system assigns it to the next open checkpoint (e.g., *Finish*).
* This ensures that participants’ race continuity is preserved, even if certain checkpoints are no longer active.
* The internal service may mark this step as **PROMOTED**, but what timers see in the UI is the resulting **VALID** passing at the new checkpoint.

This behavior maintains fairness and accuracy while reducing the chance of lost data.

## Logical vs Physical Checkpoints

In real-world races, the **Start** and **Finish** lines are often at the same physical location. In RRM, however, it is best practice to configure them as **separate checkpoints**.

This approach gives timers more granularity and control:

* **Close Start independently** → Once all participants have started, you can close the *Start* checkpoint while keeping the *Finish* checkpoint open.
* **Manage notifications separately** → You can silence notifications for *Start* (to avoid overload during a mass start) while still allowing *Finish* notifications.
* **Handle race plan progression correctly** → With separate checkpoints, RRM can shift passings through the plan without ambiguity.

Even though the two checkpoints may share the same physical mat, treating them separately in the software provides significant operational benefits.

## Best Practices

* Always configure **Start** and **Finish** as distinct checkpoints, even if they share the same location.
* Use checkpoint **closing** to reduce noise once a phase of the race is complete.
* Adjust **notifications** per checkpoint to match operational needs.
* Monitor the **Event Control View** to confirm how passings are applied.

## Summary

By combining **promotion through the race plan** with the ability to define **logical checkpoints**, RRM ensures that passings are always handled consistently and that race organizers have full control over timing operations.

This flexibility is especially valuable when the same physical location acts as both the start and finish line.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://help.runonrufus.com/rufus-race-manager/checkpoints/checkpoint-promotion-and-granularity.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.