> For the complete documentation index, see [llms.txt](https://help.runonrufus.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.runonrufus.com/rufus-race-manager/checkpoints/checkpoint-promotion-and-granularity.md).

# 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.