What units are PSL_paise and price_paise in?

Both are integers, in paise (1 INR = 100 paise). All money math in Q-Radar is computed in paise to avoid floating-point rounding errors on aggregate. UIs render in INR ₹X,XXX format; raw API responses include both paise and INR-formatted strings.

How is OOS_window_days computed when an SKU bounces in and out of stock?

Each consecutive run of in-stock or OOS observations on a given (SKU × dark-store) tuple forms an interval. PSL is computed per OOS interval. A short stockout followed by a restock and another stockout produces two PSL rows — each with its own velocity input, its own price snapshot, and its own audit row. The Leak Ledger aggregates them; the per-row drill-down keeps them separate.

What if a dark store has zero pre-OOS velocity? Is PSL zero?

Yes — when expected_units evaluates to zero (velocity × stores_with_OOS × OOS_window_days = 0), lost_units = max(0, 0 − observed_units) = 0, and PSL = 0. The row is still written to the ledger with PSL = 0 for completeness; the drill-down explains the zero by showing the velocity source as 0. Brands sometimes use this to identify dark stores where the SKU was never stocked in the first place.

How does the sensitivity-analysis toggle work?

On the in-app PSL drill-down, every row exposes a small slider / step control that lets the viewer override the velocity assumption for that row to a test value (e.g. 10 / 15 / 20 u/store/day). The recomputed PSL is shown live next to the baseline. The override is local to the drill-down view — it does not modify the ledger row or the audit chain. Customers use this to bound the upper edge of uncertainty for finance reviews.

Why is the scrape-inferred velocity fallback 5 u/store/day specifically?

Conservative default chosen from the early Royal Canin + Dr Odin cohorts. We benchmarked across categories and 5 u/store/day was inside the 25th percentile across pet, FMCG, beauty and specialty-tea — i.e. it under-estimates rather than over-estimates leakage for most SKUs. It is environment-overridable per deployment, and customers are encouraged to enter tenant overrides for hero SKUs so the scrape-inferred fallback only applies to long-tail SKUs.

Is the audit chain reset between tenants?

Yes — every tenant maintains its own independent hash chain. A new tenant's first PSL row uses a chain-genesis hash (SHA-256 of an empty string). Tenants cannot read each other's chains; the chain hash for tenant A says nothing about tenant B's data and vice versa. Cross-tenant aggregate analytics never touch the audit sink.

Can a customer challenge a PSL number?

Yes. Every drill-down row exposes the exact inputs (velocity source, OOS window timestamps, price source, dark-store ID, scrape batch ID, audit row ID). Customers who disagree can override velocity (raising the precedence to tenant-config), submit a price-correction request (audited separately), or dispute the OOS window (we re-scrape and append a correction row, hash-chained, leaving the original row intact for chain continuity). The system is designed to be argued with — that's a feature, not a bug.

Q-Radar / Glass-Box PSL Methodology

Public methodology

The Glass-Box PSL methodology, in full.

GobbleCube talks about "spotting leaks" without quantifying INR. Dcluttr names "PSL" but never shows methodology. Both keep the inputs opaque. We do the opposite — publish the formula, expose every input on per-row drill-down, prove tamper-evident continuity through a hash-chained audit ledger. This page is the public companion to the in-app per-row drill-down. Read it before you trust a single PSL number from anyone.

Back to Q-Radar Book a walkthrough

The formula

One line of math, expanded.

Predicted Sales Loss

PSL_paise = lost_units × price_paise

  where:
    lost_units      = max(0, expected_units − observed_units)
    expected_units  = velocity × stores_with_OOS × OOS_window_days
    price_paise     = MRP from market_price_snapshots at OOS-window start
    OOS_window_days = exact OOS interval from market_stock_snapshots

Inputs

velocity (u/store/day, source-tagged)
stores_with_OOS (count of dark stores in the OOS interval)
OOS_window_days (precise interval duration)
MRP from market_price_snapshots @ window start
observed_units (real sales in the window, when available)

Outputs

PSL_paise (integer, in paise)
PSL_inr (₹ formatted for display)
velocity source tag (tenant / admin / scrape-inferred)
audit row chain hash (SHA-256)
calculation breakdown (every term, expanded)

Velocity resolution

The lookup order, with source tags

velocity is the single biggest source of methodology disagreement in any PSL system. We resolve it in a strict, source-tagged order — and surface the tag on every row.

1. Tenant or admin override

tenant-configadmin-config

The brand enters per-SKU per-channel velocity directly, based on internal sell-through reports. Admin can override per-tenant from KAM conversations. Highest precedence — used whenever present.

2. Scrape-inferred fallback constant

scrape-inferred

5 units / store / day, environment-overridable. Conservative; ensures the formula has a deterministic default for every PSL row even when no tenant override exists. Source-tagged so reviewers know it was the fallback.

Cross-module eVanik velocity bridge: tenants subscribed to both Q-Radar and eVanik can opt into a bridge worker that imports velocity from real settled orders into the qradar_velocity_overrides collection with source tag imported and provenance evanik-bridge:<runDate>. Q-Radar reads the same collection — it does not know or care where the override came from.

Sensitivity analysis

Honest about uncertainty

Every PSL row exposes a sensitivity toggle so reviewers can bound the upper edge of the estimate without modifying the ledger.

Velocity assumption	Resulting PSL (relative)
`5 u/store/day`	Baseline (scrape-inferred)
`10 u/store/day`	2× baseline
`15 u/store/day`	3× baseline
`20 u/store/day`	4× baseline

The toggle is a local recompute — the ledger row is not modified, the audit chain is not broken. Customers use the toggle on internal reviews ("what if Q-Com velocity were 3× what scrape-inferred says") to defend the lower-bound PSL claim with their finance team.

Audit chain of custody

From PSL row to tamper-evident evidence pack

The audit sink is what turns a PSL number into a CFO claim. Here is exactly how it works, end-to-end.

Append-only PSL row

Every PSL computation writes a row to qradar_psl_ledger keyed by (tenantId, masterProductId, channelCode, scrapeBatchId, oosWindowId). ULIDs are chronological + idempotent — re-runs do not duplicate rows.

SHA-256 of (prev_hash + canonical_row_json)

Each row carries chainHash computed as SHA-256(prevRowChainHash || JSON.stringify(rowFieldsCanonical)). Field ordering and serialization are fixed so the hash is reproducible by any reader holding the row data.

Mirror to S3 Compliance-mode bucket

Audit sink is an S3 bucket configured with Object Lock in COMPLIANCE retention mode. Once written, rows cannot be deleted or modified by anyone — including Zobrx engineers, including AWS account root — for the retention window.

Verifier script in the evidence pack

Customer evidence packs ship with a standalone Node.js verifier (~80 lines, no external deps) that walks the chain, recomputes every hash, and reports any break. Auditors run it against the downloaded pack without Zobrx access.

The audit sink is SOC 2 + DPDP aligned, S3 Object Lock in COMPLIANCE retention. Even Zobrx engineers cannot delete or modify written rows for the retention window — finance teams can verify the chain independently of the platform. See /security for the broader audit-sink architecture and compliance posture.

Where we are honest

What Glass-Box PSL does NOT claim.

Methodology transparency cuts both ways. We name the things this approach cannot do.

We do not claim PSL equals actual lost sales

Actual lost sales is unobservable — it is the counterfactual where no OOS happened, which never existed. PSL is an estimate calibrated to give brands a defensible INR figure, with the velocity assumption disclosed. We err conservative on the fallback (5 u/store/day) so the unobserved upside, if any, lives in the tenant override.

We do not claim hash-chained audit prevents data corruption upstream

The chain proves continuity of the ledger after rows are written. It cannot prove that the scrape that produced the row was correct, or that the SKU master mapping was right. We harden those upstream pipelines separately (idempotent ULID keys, scrape-batch dedup, master-mapping versioning) but the audit chain is downstream of all that.

We do not claim every Q-Com platform shares the same velocity profile

5 u/store/day is a deliberately conservative default across the catalog. Real velocities on Blinkit vs Zepto vs Instamart for the same SKU can diverge 2–3× because of platform-specific shelf position, app surface area and replenishment cadence. Tenant overrides per-channel are how brands close this gap; the scrape-inferred fallback is only the floor.

We do not claim PSL replaces internal financial reporting

PSL is a forward-looking operational signal — it tells the brand team where to act. It is not GAAP-compliant lost revenue and does not flow into the brand's financial books. Some customers do use the Leak Ledger evidence pack as supporting documentation for KAM negotiations with Q-Com platforms; that is up to them.

Versioning policy

When the methodology changes

Methodology version pinning

Today: v1

Every PSL row records the methodology version that produced it. When we ship a v2 (planned: dual-track shelf-PSL + consumer-PSL on every row), v1 rows continue to be valid — the per-row version pin means CFO evidence packs already shared with customers stay defensible. We do not retroactively edit ledger rows; v2 starts a new chain at the v1→v2 boundary and the boundary itself is hash-chained.

Material changes to v1 between minor revisions (e.g. the scrape-inferred fallback constant) require a release-note entry on this page and a methodology-bulletin email to every Q-Radar tenant. Velocity-source-tag definitions are stable — a tag means the same thing forever.

Methodology FAQ

Questions about the formula

Three reasons. (1) Transparency is the moat — copying the formula does not reproduce the scrape pipeline, the integrated workflow, the CFO-grade hash-chained audit chain, or the cross-module ad / Brand-Score / attribution wiring. (2) CFOs and legal teams cannot trust a number whose derivation is opaque; PSL must be defensible before it is useful. (3) Our customers ask: 'show me how the number was computed.' If we cannot answer, they cannot board the leak claim with their finance team. Publishing the formula is table stakes for the audience.

Where to go from here

Q-Radar product page

The full Q-Radar product — capabilities, OSA lenses, audit flow, design partners.

What is Quick Commerce OSA?

The category-defining pillar guide for Q-Com On-Shelf Availability in India.

Q-Radar vs GobbleCube vs Dcluttr

Side-by-side comparison of the three named Q-Com shelf intelligence tools.

Security & audit-sink architecture

How the SOC 2 / DPDP-aligned audit sink works across all Zobrx surfaces.

Brand Score™

Q-Radar's availability feeds the Brand Score availability lever.

Talk to engineering

Have a methodology question this page does not answer? Email mayank@evanik.ai.

Get started

See Q-Radar's PSL drill-down on your data.

The methodology page above is the public version. The in-app version expands every term, surfaces the velocity source tag, hosts the sensitivity toggle, and links to the audit row hash. Book a walkthrough to see it on your SKUs.

Book a walkthrough Back to Q-Radar

✓ 14-day free trial
✓ No credit card
✓ Cancel anytime

GA4