# Editing Timing Data

In **RUFUS Race Manager (RRM)**, captured passings cannot be directly edited to preserve data integrity. Instead, operators have several tools to manage, correct, or override passings when necessary.

## Managing Passings

* **Deleting passings**\
  Passings can be deleted if they are incorrect or irrelevant (e.g., a stray chip read).
* **Validating or invalidating passings**\
  Passings can be manually set to **VALIDATED\_BY\_USER** or **INVALIDATED\_BY\_USER**.
  * Use validation to confirm a passing that should count, even if it was flagged otherwise.
  * Use invalidation to exclude a passing from results, without deleting its record.

These actions give operators fine control over which passings contribute to classifications and rankings.

## Correcting Incorrect Time Entries

If a passing has the wrong timestamp, it cannot be directly changed. To correct it:

1. Delete the incorrect passing.
2. Add a new passing with the correct timestamp.

This ensures the correction is transparent while maintaining a clear audit trail.

## Adding Missing Times

When a participant’s passing is missing, it can be manually added in different ways:

* **Checkpoint-Race View**\
  The passing goes through the **full race processing logic**, including checkpoint matching, bounce validation, and status assignment.
* **Manual Passing (Add New)**\
  The passing is inserted directly into the participant’s record for a specific checkpoint, skipping the full logic.
* **Floating Passings**\
  A passing can be added without assigning a checkpoint. The system infers the correct next checkpoint from the full race plan. See Floating Passings for details.

## Approving or Rejecting Passings

Operators can review passings and decide their final validity:

* **VALIDATED\_BY\_USER** → Manually confirmed as valid.
* **INVALIDATED\_BY\_USER** → Manually excluded from results.

This allows timers to ensure fairness and accuracy when automatic logic is not enough.

## Comparison of Actions

| **Action**                         | **Effect**                                                   | **When to Use**                                                                  |
| ---------------------------------- | ------------------------------------------------------------ | -------------------------------------------------------------------------------- |
| **Delete Passing**                 | Removes the passing entirely                                 | Stray chip reads, duplicate reads, incorrect timestamp to be replaced            |
| **Validate Passing**               | Marks a passing as accepted, even if initially blocked       | Judge confirms a disputed crossing, or a passing bypassed by rules should count  |
| **Invalidate Passing**             | Excludes a passing from results but keeps it in the record   | Duplicate detections, false positives, disputed crossings you don’t want deleted |
| **Add New (Checkpoint-Race View)** | Adds a passing with full race logic applied                  | Adding missing times during the race, ensuring processing consistency            |
| **Add New (Manual Passing)**       | Adds a passing directly to a participant                     | Post-race targeted correction for a single athlete                               |
| **Floating Passing**               | Adds a passing without a checkpoint; system infers placement | Busy race operations, quick corrections, or when unsure of the checkpoint        |

## Best Practices

* Use **deletion** sparingly — prefer invalidation to keep an audit trail.
* Use **validation** for disputed cases where the passing should still count.
* Prefer **Checkpoint-Race View** for corrections during the race, and **Participant Edit** for post-race clean-up.
* Use **floating passings** for fast corrections when speed and flexibility are needed.


---

# 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/editing-timing-data.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.