Stock Safety
PullPush is built for operational commerce sync where a wrong write is worse than a delayed one. The core rule:
Unknown stock is never delivered as 0.
Pushing zero for “we could not read this location / SKU” would wipe channel inventory and cause oversells, account penalties, and lost trust. Missing data is skipped (UNKNOWN_STOCK_SKIP), not invented.
What “unknown” means
A source snapshot or poll may return:
| Signal | Meaning | Delivery |
|---|---|---|
0 |
Real empty stock at that location | Delivered as zero |
null / missing / unreadable |
No trustworthy quantity | Skipped — destination unchanged |
| Positive integer | Known on-hand | Delivered |
Connectors such as Linnworks encode this explicitly (e.g. extractLinnworksLevel returns null when the location level is not present).
Trust journey (default path)
- Connect source and destination (credentials envelope-encrypted per tenant).
- Shadow — flow starts read-only; nothing writes to the destination.
- Preview — structured source-vs-destination diff (drifted quantities, unmatched SKUs, already-in-sync rows).
- Reconcile — snapshot baselines catch ongoing drift after you understand the map.
- Cut over — promote shadow → live only when ops trusts the numbers.
- Operate — ordering, idempotency, circuit breaker, and dead-letter queue keep failures recoverable.
Shadow-first is enforced server-side. Agents on MCP cannot “accidentally” go live by prompt alone.
Why this matters vs generic iPaaS / automation
Recipe tools will happily map a null field to 0 if that is how the scenario was built. PullPush treats stock safety as a runtime invariant, not a documentation suggestion.