A Completed Race Photo Batch Does Not Automatically Mean Every Exception Was Resolved

A race-photo batch may reach the end of routine processing and still contain unresolved work.

Clear BIB numbers may have been entered. Standard tagging may be complete. The output file may already look organized.

But what happened to the exceptions?

Routine Completion and Exception Resolution Are Different States

A batch can contain several types of work at the same time.

What Counts as an Exception in Race Photo Processing?

An exception is a record that does not fit the project's routine processing path.

Depending on the workflow, that can include:

“Open” Does Not Always Mean “Failed”

Not every exception can or should be forced into a resolved state.

Sometimes the source image simply does not provide enough information to determine a complete participant reference.

In that case, a valid final status may be:

• unresolved
• review completed — insufficient basis
• waiting for client input
• excluded under an agreed rule

The important control is that the state is explicit.

Exception Review Needs a Defined Final Disposition

An exception should not remain in an undefined state indefinitely.

For the partial-reference side of this process, see Why Partial BIB Numbers Should Go to Exception Review .

A Batch Can Be Complete With Unresolved Exceptions — If Their Status Is Clear

“Resolved” and “accounted for” are not always the same thing.

Suppose an image shows only 12?4.

After review, there may still be no reliable basis to complete the missing digit.

The record can still reach a final disposition such as:

• exception reviewed
• participant reference remains partial
• no supported resolution available
• final status recorded

In that case, the record is not “resolved” into a complete BIB, but it is no longer an unexplained open item.

Exception Status Should Stay Connected to the Source Image

The final exception outcome is more useful when it remains traceable to the source image that created the issue.

A structured exception record may include:

• source image ID
• visible participant reference
• exception category
• event / batch reference
• review status
• final disposition

This makes the final state easier to review later.

See Race Photo Data Traceability for more on source-to-output linkage.

Exception Closure Should Not Mean Hiding the Record

Closing an exception should not require deleting its history or making it look like a routine record.

Depending on project requirements, the final output may retain:

• the final participant reference
• review-required status
• exception type
• resolution state
• source image key

The exact output should follow the client-defined data model.

Multiple-BIB Images Can Produce Mixed Final States

One image may contain several participant references.

For example:

• BIB 1284 — mapped
• BIB 2417 — mapped
• BIB 30?6 — review completed, remains partial

The image itself therefore contains both resolved and unresolved participant-reference states.

This is why batch completion should not be reduced to a simple yes-or-no status at image level.

See Multiple BIB Numbers in One Race Photo .

Metadata Exceptions Need Final Disposition Too

Exceptions are not limited to BIB numbers.

Metadata and indexing can also contain review conditions such as:

• event field missing
• photo zone unclear
• batch reference inconsistent
• required keyword unavailable
• participant-reference mapping unresolved

These items should also be accounted for where they are part of the agreed processing scope.

See our Race Photo Metadata Guide .

Final Review Should Ask More Than “Is the Queue Empty?”

An empty routine queue can be misleading if exceptions have been moved elsewhere and never reviewed.

A stronger final review can check:

Larger Batches Make Exception Closure More Important

In a small project, unresolved records may be easy to notice manually.

In a larger or recurring workflow, exceptions can become separated from routine production unless they have a defined queue and final state.

This is why larger workloads benefit from:

• exception categories
• review queues
• status visibility
• source traceability
• final disposition
• batch reconciliation

For larger scoped workloads, see Bulk Race Photo Processing Services .

Queue Control Should Distinguish Open Exceptions From Completed Work

Queue management is most useful when routine work, blocked records and exception review are visible separately.

Otherwise, a batch can look complete simply because the difficult records were moved out of the main queue.

See Bulk Race Photo Processing: Why Queue Control Matters .

Reconciliation Is the Final Check on Exception Status

Reconciliation should account for both routine and non-routine work.

It asks:

• Which records completed normally?
• Which exceptions were resolved?
• Which exceptions remain unresolved?
• Which items are blocked?
• Which items were excluded under agreed rules?
• Does every source record have an explainable state?

See Why Race Photo Processing Reconciliation Matters .

A completed race-photo batch should not mean:

“The easy records are finished.”

It should mean the full workload can be explained.