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