Boolean Stock vs. Exact Quantity: What the Data Actually Proves

An "available" status only proves that a source presents the item as orderable at the moment observed; it does not give the number of units. An exact quantity, say 27, provides more precise information, but guarantees neither a reservation, nor the absence of competing orders, nor delivery. So keep the raw value, its type, its source, and its timestamp. Never convert InStock into 1 or an assumed quantity. To purchase, apply the minimum and the order increment to a recent numeric quantity, and request confirmation if the stakes exceed what the data actually proves.

Five forms of stock that must not be merged

Catalogs use very different vocabularies. A field named stock might contain an integer, true, a text like "within 5 days," a threshold class, or a restocking date. Before any calculation, assign a proof category.

Schema.org defines ItemAvailability as a list of possible states associated with an offer, including InStock, OutOfStock, BackOrder, or PreOrder. The InStock page simply indicates that the item is in stock. It does not specify a quantity. This convention is useful for interpreting public structured data, but it does not constitute a commercial guarantee from the supplier.

An exact quantity remains an observation, not a promise

Even when a supplier exposes stock_quantity=27, three questions remain open: at what time was the quantity calculated, for which warehouse, and how much is already reserved? The same number could be global, local, available for sale, or physical stock before commitments. The documentation must give the scope.

Keep distinct fields: stock_raw, stock_type, stock_quantity, availability, warehouse_scope, source_generated_at, and observed_at. If the source provides an exact quantity but no warehouse scope, don't fill in that scope with a guess. Incomplete information can remain usable with a warning; invented information cannot.

The price and stock freshness policy must be applied before any use. An old quantity does not become boolean: it stays a historical quantity, marked stale for actions requiring a recent observation.

Purchasable quantity, MOQ, and order increment

Stock and purchasable quantity are not the same thing. Suppose, as a purely hypothetical example, that a source shows 27 units, a minimum order of 10, and an increment of 5. The compliant quantities would then be 10, 15, 20, or 25, within the limit of the observed stock. A request for 12 does not respect the increment, and 30 exceeds the displayed stock. This logic depends on the contractual definition of the MOQ and increment; it must not be inferred from a title or a photo.

Add the packaging: a carton announced as six units could mean that stock_quantity=27 counts cartons or units. As long as the unit of the quantity is undocumented, the purchase calculation should stay blocked. Reading the columns of a wholesale catalog helps surface these dependencies before import.

A safe rule follows this order:

1. Identify the sales unit. 2. Verify the packaging contents against structured or contractual proof. 3. Read the MOQ and increment as separate fields. 4. Classify stock by its proof level. 5. Apply freshness to the observation. 6. Calculate compliant quantities only if the units are compatible. 7. Confirm with the supplier just before ordering.

Empty, zero, and negative values

0 can reasonably represent an absence of quantity if the field's documentation confirms it. An empty cell is not equivalent: it may mean unavailable information, an unmanaged product, or an error. Treat null, empty string, and absent field as distinct states during diagnosis, then map them only based on documentation.

A negative quantity may represent a remainder in an internal system, but it is not a quantity available for sale. Reject it from the usable stock_quantity field and keep it in the raw value with a reason. Likewise, a decimal for a product sold by the unit should be placed in review; for a product measured by weight, it can be legitimate. The unit's context decides.

Never mask a problem by replacing every anomaly with zero. That practice confuses the absence of proof with a certain stockout and skews source diagnostics.

Verifying stock on a canary batch

A supplier canary batch should include at least a variety of states: available product, stockout, empty value, low quantity, possible restock, and several variants. The goal is not to exhaust the catalog, but to confront the parser with the cases that change the decision.

For each row, compare the raw response, the authorized official listing, and the normalized field. Wait for a planned update or make a new observation at the allowed cadence to verify that transitions are handled. A product moving from InStock to OutOfStock must not retain a quantity from a previous collection.

Stock proof checklist

• ☐ The raw value is preserved.
• ☐ Boolean, quantity, threshold, lead time, and unknown are separated.
• ☐ The quantity's unit is documented.
• ☐ The warehouse or scope is stated if provided.
• ☐ The source timestamp is not confused with the script's run time.
• ☐ An empty value is not turned into zero.
• ☐ MOQ, order increment, and packaging are distinct.
• ☐ A stale quantity does not trigger a silent decision.
• ☐ An availability transition clears incompatible derived values.
• ☐ Availability is confirmed before purchase.

What ArbitragePro+ can automate / what the seller must verify

The proposed controle-stock specification could type each value, prevent converting a boolean into a quantity, apply freshness rules, and flag inconsistencies with MOQ, increment, or packaging. The report should always show the raw proof.

The seller must confirm the contractual meaning of the stock, the unit, the warehouse scope, any reservations, and the quantity actually accepted at the time of ordering.

Check the health of a stock data source

Open source health to review the available availability and collection information.

Official sources

• Schema.org, «ItemAvailability», https://schema.org/ItemAvailability — accessed 2026-08-17.
• Schema.org, «InStock», https://schema.org/InStock — accessed 2026-08-17.
• IETF, RFC 9110, «HTTP Semantics», https://www.rfc-editor.org/rfc/rfc9110.html — accessed 2026-08-17.