Read the scan
before explaining it.

A chain, a ring and a repeated tag.

A count starts from the selected store’s available-at-start roster. That frozen roster supports up to five hundred expected item identities. It is not every piece in custody, a component count or a statement that the shop owns everything on the list.

Imagine five recorded observations. The first chain tag matches an expected identity. The same tag appears again. A ring’s old tag still matches its captured identity. A locally available pendant was outside the original roster. Another code cannot be matched. The event history lets you read those differences rather than explaining every exception as missing stock.

Repeated unexpected-local and unmatched observations remain events too. They are not deduplicated into a physical quantity. Expected coverage counts each expected identity once, while the observation history retains deliberate repeated scans.

Fifty events per page, one reviewed ceiling.

A supported session can hold up to one thousand observations. The history reader makes the complete recorded sequence reachable in fifty-event pages, newest first. Older and newer navigation replace the visible page; they do not append an ever-growing screen or create another observation.

The initial check pins an upper accepted event number and recorded head for that viewing window. Suppose it starts at event 125. The first page contains 125 back to 76, the next 75 back to 26 and the last 25 back to 1. Returning to the first page keeps that same ceiling.

If a colleague later appends event 126, it belongs to a new window. It does not slip into the older pages you were reviewing. Request a new window explicitly when you want the latest accepted observations. Paging is not a fresh scan or an acceptance of a new count basis.

Current progress and the viewed events are different references.

A pinned event window can remain useful while the session progresses. The separate current-session information may indicate a newer observation or that a manager has closed the count. That newer progress does not replace the event ceiling or reinterpret the old page as a current summary.

Closing after the initial history check leaves the viewed observations unchanged. The recorded closure still has its own observation cutoff and review meaning. A page from an earlier window must not be mistaken for every event included in that later closure.

Reading history keeps the typed scan, closing note and any uncertain original count request separate. It does not change the closing form’s checked head or mark its review complete. Before a new close, use the existing count workflow to refresh and explicitly review current evidence.

Keep the old label readable after the stock record changes.

The observation retains the exact recorded code, operator, time, classification and captured identity context. A later SKU rename or movement does not substitute a new title or destination’s current facts into the old event. An unavailable local context stays unavailable.

A stored item link is evidence of the submitted code, not permission to open or fetch it. History does not follow scan URLs, query a remote website or look up a foreign store’s item to explain an unmatched event. Read the captured text through the authorized recording-store view.

For physical labels, use the separate identity-label workflow. A prepared label, an observed code and a current inventory record answer different questions; none automatically changes the others.

Use the sequence to ask better questions.

1. Find the accepted observation.

   Read its code and classification. An original request check and a new deliberate repeated scan are different operations.

2. Compare it with the frozen roster.

   A not-observed expected identity means it was not covered by that cutoff. It is not a recorded loss, write-off or proof of absence from the building.

3. Keep the follow-up separate.

   Investigate through the shop’s approved process. Reading another page does not adjust stock, remove a reservation, approve a discrepancy or establish ownership.

These are review steps, not new app assignments or independent approval. The available-at-start scope, original count commands and saved closure remain unchanged.

A readable history must not skip an inconsistent event.

The supported complete baseline, observation chain and closure evidence are checked before returning a page. Unsupported or inconsistent evidence makes history unavailable; the reader does not hide one bad event, repair a classification or return an apparently complete partial chain.

Bring an interrupted scan, an old label and a colleague’s later observation to a walkthrough. Check the pinned window, current-progress notice and original-request recovery without making a stock change.