How it works

One store's signals, joined to the outside world's, on one clock. Every step is a checkable fact rather than a model's impression.

1. The store sends counts, not records. Every fifteen minutes the plugin sends orders by status per hour, order-note reason codes drawn from a fixed list of nine, gateway availability, webhook success and failure counts, scheduler backlog, and which components changed. The note TEXT is discarded on the store; only the label travels.
2. Signals become observations. A count becomes an observation only when it is outside this store's own range — a shop that always has some pending orders is not reported for having some.
3. One clock. Changes, symptoms, errors, webhook failures and scheduler backlog go on a single timeline. "The webhook started failing four hours after that update" is a fact about ordering, not a correlation someone eyeballed.
4. The outside world agrees, or does not. When one component changed before the symptom, it is named, and public release and issue evidence for that component is looked up. A GitHub issue and the forum thread quoting it are one witness, not two.
5. Confidence is a floor, never an average. Two signal families and one strong signal reach medium. Only independent public agreement reaches high — one store's data cannot tell a bug apart from a local misconfiguration. Aging data lowers it. Nothing strong and nothing public is not "low confidence", it is an abstention.

Why abstaining matters more than answering

A confident wrong answer during an outage costs more than no answer: it sends a merchant to roll back the wrong plugin while the real fault keeps running. So a stale snapshot, a single signal family, or a real drop with nothing to explain it all produce a stated refusal with the reason attached.

See the evidence methodology for the exact rules.