# 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.
* **Edit Participant View**\
  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 (Participant Edit)**     | 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.