A detection threshold is the boundary value that decides which category a measured breath alcohol result falls into. After changing this value, safety managers and quality or technical staff end up comparing monthly lockout rates, result distributions by device, and trends before and after the change. Because the same reading can be recorded under a different result depending on the threshold in force, the numbers or the pass/lockout flags alone cannot explain what happened in the past.
DATECH's official information on the AF-i1 describes managing and downloading log events and configuring operating behavior through dedicated software, and states that test results and vehicle-related events are stored with date and time information. However, the fact that a date and time were recorded does not automatically tell you which threshold was in effect at that moment. To reinterpret past results after a threshold change, you have to keep the original device result separate from any after-the-fact analysis.
A result is not produced by the reading alone
A recorded pass or lockout result is the product of two things: the reading and the detection threshold in effect at the time. If you apply today's threshold to old records and change past results, the record of what the device actually did and an analysis from today's perspective end up mixed in a single field. This is also why you cannot immediately conclude that a past result was wrong.
In particular, if a record shows only a pass/lockout flag with no reading, there is not enough basis to reclassify it under the new threshold. You can tell that it was flagged as a lockout at the time, but not whether it would still be a lockout under the new threshold. It is more sound to preserve such records as original results under the settings of the time, and to mark them as "cannot be reclassified" in any comparison totals based on the new threshold.
Where the reading was retained, an analysis that applies the new threshold may be possible. Even so, that output is not a corrected version of the device's past result; it is a value recalculated under a specific analysis rule. If an analysis screen or report shows both results under the same label, anyone looking at it later will struggle to tell which one is the original record.
Separate the approval date from the effective time
The date a threshold change was approved, the date the setting change was requested, and the date and time the setting actually took effect on the device can all differ. If you split the before and after periods using only the date on the approval document, results that were actually measured under the old setting can land in the new-setting period. The reverse can also happen, with results already produced under the new setting left in the earlier period.
The official AF-i1 information describes an operating behavior configuration feature, but that information alone does not tell you how a specific setting is recorded or who is authorized to change it. Rather than basing the analysis on an assumed settings screen or menu structure, you need to link the result records to evidence showing which value took effect on each device and from when.
| Information to keep together | Why it is needed | How to handle it in analysis |
|---|---|---|
| Device result and reading at the time | To preserve what the device displayed or did at the time | Keep the original result unchanged |
| Threshold applied and display unit | To explain where the decision boundary was | Group only records with the same unit and same threshold |
| Actual date and time the setting took effect | To split before and after results correctly | Mark unconfirmed periods as a separate segment |
| Post-hoc analysis rule and analysis date | To identify values that were reclassified later | Keep them in an analysis column or total separate from the original result |
This information is not just an administrative note. If the lockout rate changed after a threshold change, the first thing to review is the effect of the shifted decision boundary. A trend chart with no marker for the setting change can make it look as though user condition, test conditions, or device performance changed.
Reclassification does not correct the original record
Reclassifying past readings under a new threshold can be used to examine the impact of an operational change. For example, you can analyze what share of past records would fall into a different category under the new threshold. But this analysis applies today's rule to past numbers, and it does not replace the result the device actually produced at that point in time.
Consider a hypothetical example. Suppose the threshold change was approved on the morning of June 15, and the time the setting took effect varied by device, from that afternoon to the next morning. The observation that lockout results in June rose compared with May is not, on its own, enough to interpret a change in user behavior or a device fault. That is because the threshold change itself is part of the June totals.
In this case, the first things to look at are when the setting actually took effect on each device, whether each record has a reading, and the share of records that carry only a result with no reading. Records with readings can go into a separate analysis total that applies the new threshold. Records without readings are left as "cannot be reclassified," without arbitrarily filling in a result under the new threshold.
A possible action is to place the original device-result totals and the new-threshold analysis totals side by side, clearly stating the threshold and the period covered for each. The completion criterion is a state where the records make it plain that the two totals answer different questions. One should show how the device handled results at the time; the other should show how past readings would be classified under the new threshold.
Unconfirmed periods are part of the results
If the time a setting actually took effect cannot be confirmed, or if it differs across devices, it is hard to treat results from that period as a single set of data under identical conditions. Rather than deleting those records or lumping them all into the before or after threshold, it reduces interpretation errors to mark them as a period with an unconfirmed setting effective time. Holding off on comparison does not mean the data is useless; it means the conditions under which it was produced cannot be pinned down.
The AF-i1 is described as storing about 500,000 test results and operating events, with date and time information saved for every result and event. This time information is the starting point for finding the order in which results occurred and the candidate before and after periods. However, the time a result occurred is not evidence of the setting itself, so you can only fix a comparison boundary once it can be linked to records confirming when the setting took effect.
If the setting took effect at different times on different devices, it may be more appropriate to first split each device's before and after periods rather than total by month. Only then, by comparing lockout rates or reading distributions across periods with the same threshold, can you avoid mixing the effect of the threshold change with other sources of change.
How to preserve the meaning of past results
When reinterpreting past results after a threshold change, the key is not to overwrite old records with the current threshold. Keeping the device result at the time, the threshold applied at the time, the actual effective time, and the post-hoc analysis rule as separate items lets you maintain both the original operating record and any reclassification done for analysis.
With this separation in place, increases or decreases in lockout results can be interpreted in the right order. You first examine the difference the threshold change made to the totals, and only then review changes in test conditions or in how the records are composed. A record of detection threshold changes is not reference information appended to a results table; it is the interpretive condition that determines what past results mean.
