ADR-0003: Result import does not transition UNFIT_FOR_SERVICE
| Status |
Accepted |
| Date |
2026-04-24 |
| Deciders | |
| Related |
1. Context
A RaceNumber can be flagged UNFIT_FOR_SERVICE by an admin when physical inspection reveals damage (broken chip, delaminated tag, cracked substrate, etc.). The flag is a location-agnostic assertion about fitness — the number may still be held by a person, may still be in stock, may still be registered for a future event.
Occasionally, a result row arrives for a number that is currently flagged UNFIT. Possible real-world causes:
-
Used despite the flag. The participant was handed the broken number at the desk and ran with it anyway (maybe nothing else was available; maybe the damage was cosmetic). The result is real.
-
Timing picked up a damaged tag. The tag is technically working enough to get captured as the participant crosses the mat, even though the number itself is flagged for retirement. The result is real, but the fitness verdict stands.
-
Premature flag. Someone flagged the number before the event, and it turned out to be fine. The result is real, and the flag should be cleared.
-
Wrong number in the CSV. Timing recorded the wrong bib. The result is not for this number; it’s a data error.
The system cannot distinguish these four cases from the data. Only an operator can.
2. Decision
When recordResultImport encounters a RaceNumber in state UNFIT_FOR_SERVICE:
-
Do not transition the state. The number stays
UNFIT_FOR_SERVICE. -
Stamp
last_used = eventDate(subject to the monotone rule in ADR-0004). -
Write a
RESULTlog entry with the noteUNFIT_FOR_SERVICE at time of result import. -
Emit a WARN to the service log so the anomaly is visible in operational dashboards.
Admin must resolve the situation manually — by clearing the flag (if the number was fine), by running the return workflow with a disposal note (if the flag stands), or by correcting the data (if the wrong bib was recorded).
3. Consequences
3.1. Positive
-
The fitness verdict is preserved. A damaged number does not become "fit" because it crossed a finish line — a result row is evidence of activity, not of integrity.
-
Admin retains agency. The four real-world causes have four different resolutions, and the system defers to a human rather than guessing.
-
The WARN creates a visible signal that something about this number needs attention; it cannot be silently overwritten by the next import.
-
The
last_usedstamp keeps pick-list and timing-feed queries (WS1b) honest even in the anomaly path — the number was demonstrably used, so it should not resurface as "stale in stock".
3.2. Negative
-
A number flagged prematurely stays flagged until an admin clears it. Minor operational overhead in the "false positive flag" case.
-
The anomaly surfaces after the fact. If UNFIT numbers appear on results with regularity, it’s either a desk-discipline problem or a flagging-criteria problem, and the signal is downstream of where the decision was made.
4. Alternatives Considered
4.1. Alternative A: Auto-clear UNFIT on result encounter
Treat a result as re-fitness — if it works well enough to race, it’s fit. Rejected because "used" and "fit" are different properties. A participant finishing on a partly-broken board generates a valid result but should not clear the admin’s decision to retire the number.