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:
- Delete the incorrect passing.
- 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.