# Floating Passings

Floating passings are manual passings that are not tied to any physical checkpoint. Instead, they use the **entire race plan** as their scope. This means the system determines the correct checkpoint automatically, based on the participant’s progress and the event’s passing logic.

They are particularly useful when handling missed detections, busy race operations, or device outages.

### When to Use Floating Passings

* **Missed detections**\
  The timing system does not capture a participant, but their crossing is verified.
* **Quick manual input**\
  During a fast-moving event, operators can add a passing without worrying about selecting a checkpoint.
* **Device outage**\
  If a timing device fails, floating passings can substitute the missing checkpoint reads.

### How Floating Passings Work

1. In the **Event Control View**, the operator adds a floating passing for a participant’s bib.
2. The passing is compared against the **full race plan** (all checkpoints in sequence).
3. The system infers the next expected checkpoint and applies the standard logic:
   * **Synthetic start** may be created if no valid start exists (depending on policy).
   * If a checkpoint is closed, the passing may be **promoted** to the next open one.
   * **Bounce rules** still apply (checkpoint/device windows).
4. The passing is assigned with the correct lap and status (e.g., VALID, BLOCKED, PROMOTED).

Floating passings appear in the grid with **Type = Floating**, making them easy to identify.

### Example

A runner in a marathon is expected at the 20 km checkpoint. The timing mat fails to capture their chip, but the operator confirms their crossing. By adding a floating passing for the runner’s bib:

* The system checks the full race plan.
* It determines the runner’s next expected checkpoint is **20 km**.
* The floating passing is assigned there automatically, preserving race continuity.

### Visual Comparison

<figure><img src="/files/vDd9qkZ4QvKK7DVx5wCj" alt=""><figcaption><p>Floating Passing Diagram</p></figcaption></figure>

#### Participant Race Plan (Full Scope)

* Start → 5k → 10k → 15k → 20k → 25k → 30k → 35k → 40k → Finish

#### Device Race Plan (Limited Scope)

* A 10k device only sees **10k**.
* A start/finish device only sees **Start** and **Finish**.

#### Floating Passing (Full Scope)

* Instead of being tied to a device slice, the floating passing looks at the **entire plan**.
* The system places the passing at the correct checkpoint in sequence (e.g., 20k in this example).

👉 Think of floating passings as “free agents”: they don’t belong to a specific device but still respect the race plan’s rules.

### Best Practices

* Confirm the participant before adding a floating passing to avoid incorrect placements.
* Use sparingly and only when there is evidence (video, referee confirmation, etc.).
* Remember they follow the same race policies as normal passings, ensuring fairness and consistency.


---

# 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/collecting-and-managing-timing-data/floating-passings.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.