# Inventory cutoff, lot replay and protocol continuity

## Stocktake Movement Cutoff Bridge

Bridge stocktake counts to one common movement cutoff. Supply an opaque source revision, a shared nonnegative sequence clock, exact item-location stock keys with declared units, one count per stock key and signed movement deltas. Counted and expected quantities are nonnegative safe integers; adjustments, normalized quantities and variances may be signed. No unit conversion is inferred. A count at sequence S describes stock after all movements at S. For a later cutoff C, add movements in (S,C]; for an earlier cutoff C, subtract movements in (C,S]. A count already at the cutoff has no supporting movements or adjustment. Supporting movement IDs are reported in ascending sequence order, and movements for another item or location never enter the bridge. Each row reports the exact adjustment, normalized quantity and normalized-minus-expected cutoff variance. Negative reconstructions remain visible and receive a warning. This calculation cannot establish whether the supplied movements are complete or the physical count is correct; it does not freeze count sessions or replace a cycle-count review. Duplicate stock item-location keys, count keys, record IDs or movement sequences, unknown stock references and unsafe arithmetic reject the whole input during preflight. Up to 128 stock keys, 128 counts and 256 movements are supported within the shared 36,000-byte, 6,000-node and depth-24 input profile and 500,000-byte output guard. These are workload bounds. W3C OWL-Time supplies general interval vocabulary; the sequence convention above defines this calculation. Use authorized, non-sensitive data. The report describes supplied records and does not change external systems.

[Request example](stocktake-movement-cutoff-bridge.request.example.json) · [Input schema](stocktake-movement-cutoff-bridge.input.schema.json) · [Result schema](stocktake-movement-cutoff-bridge.result.schema.json)

## Lot Split and Merge Balance Replay

Replay lot splits and merges with exact quantity conservation. Supply one product, one unit, an opaque source revision, initial lots and atomic events on a shared nonnegative sequence clock. Initial quantities are nonnegative safe integers; every consumed or produced leg is a positive safe integer. Events run in ascending unique sequence order, regardless of input array order. Each input lot must already exist with sufficient balance. Partial consumption leaves the remainder on that lot. Each output lot ID must be globally fresh across initial lots and all events, even if a previous lot is exhausted. Every event must consume and produce exactly the same total quantity. All request validation and replay occur during preflight before a quote; any invalid event rejects the whole request. No lot state survives between calls. The report retains every lot, including exhausted lots, in initial-lot order followed by event output order. Replayed events show exact consumed and produced legs, and event-level ancestry links identify parents and children. Those links do not allocate a particular parent quantity to a particular child or infer material composition, provenance authenticity or serial genealogy. This is quantity replay, distinct from a graph-only recall reachability review. Duplicate lot legs, record IDs or sequences, reused outputs, unknown or future input lots, overspending, imbalance and unsafe sums reject the input. Up to 128 initial lots, 64 events and 16 input and output legs per event are supported within the shared 36,000-byte, 6,000-node and depth-24 input profile and 500,000-byte output guard. These are workload bounds. W3C PROV-O supplies general derivation vocabulary; this profile defines exact-unit conservation. Use authorized, non-sensitive data. The report describes supplied records and does not change external systems.

[Request example](lot-split-merge-balance-replay.request.example.json) · [Input schema](lot-split-merge-balance-replay.input.schema.json) · [Result schema](lot-split-merge-balance-replay.result.schema.json)

## HTTP Retry-After Compliance Audit API

Audit supplied Retry-After header occurrences against exact received and follow-up observations. Preserve every field occurrence in retryAfterValues; use an empty array only when the field was absent. Observations use whole-second YYYY-MM-DDTHH:mm:ssZ UTC in years 0001–9999. One nonnegative decimal seconds value, including leading zeroes, or a strict IMF-fixdate resolves an exact earliest follow-up time. Surrounding HTTP optional space or tab is ignored only for interpretation. Multiple occurrences are ambiguous; a present empty field is invalid. A past date requires zero remaining wait from receipt. The observed wait remains signed when follow-up precedes receipt, which is too early for any resolved instruction. Obsolete RFC850/asctime dates, leap seconds and exact results beyond year 9999 are unsupported-profile, rather than claims of invalid historical HTTP-date syntax. IMF-fixdate weekday and calendar values are checked. This bounded RFC 9110 sections 10.2.3 and 5.6.7 profile does not execute retries, choose retry policy, contact a server, parse wire messages or establish full historical HTTP-date conformance. Use authorized, non-sensitive data. The report describes supplied records and does not change external systems.

[Request example](http-retry-after-audit.request.example.json) · [Input schema](http-retry-after-audit.input.schema.json) · [Result schema](http-retry-after-audit.result.schema.json)

## WebSocket Fragment Continuity Audit API

Reconstruct supplied ordered WebSocket data fragments for one sender, starting at a known message boundary. Supply unique frame identifiers, continuation/text/binary/ping/pong opcodes, FIN booleans and even-length hexadecimal unmasked payload bytes. Message records preserve frame indices and identifiers, initial text or binary type, total bytes and reassembled payload; complete text is decoded with strict UTF-8 only after all fragments arrive. Ping and pong may interleave without joining data messages, but require FIN and at most 125 bytes. An unfinished message at sample end is incomplete evidence and remains pending. After an orphan continuation or overlapping text/binary start, completed prefix messages remain available, the interrupted partial message is retained, and later data reconstruction stops conservatively while control-frame checks continue. A completed invalid UTF-8 message has validUtf8 false and decodedText null; it cannot be reported as valid text. The assessment covers only supplied observations under RFC 6455 sections 5.4 and 5.5. Close frames, wire parsing, masking direction, reserved bits, compression, extensions, interleaved senders and connection validity are outside this profile; no socket is opened or control action executed. Use authorized, non-sensitive data. The report describes supplied records and does not change external systems.

[Request example](websocket-fragment-continuity-audit.request.example.json) · [Input schema](websocket-fragment-continuity-audit.input.schema.json) · [Result schema](websocket-fragment-continuity-audit.result.schema.json)

One-time job. See the exact service price before checkout. Save your private JSON result within its 30-day access period.
Requests accept at most 36,000 UTF-8 input bytes. Send only authorized, non-sensitive records.

For a known hosted offer, read current checkout and wallet availability with `GET https://gatewayinformationgroup.com/api/catalog/v1/search?id=PRODUCT_ID`. Then use the input schema and request example above.

Use the existing [agent checkout guide](https://gatewayinformationgroup.com/developers) to prepare a quote, pay and retrieve the private result.