How Reqursor confirms a store is set up as intended
The exact conditions, across every area, under which a store matches its intended setup.
Reqursor Platform has one specific, checkable state in mind (it calls it "converged"): a store matches how it is supposed to be set up, exactly. Not roughly, not mostly: exactly, across every area Reqursor Platform is able to check. This page defines what that means in practice.
A matching store, precisely defined
A store matches when the engine's check step (reconcile) finds zero differences between how the store is supposed to be set up and what's actually running, across every area it checks. If even one area disagrees, the store doesn't match: an unexpected change has happened, and the gap is reported rather than hidden.
This is deliberately all or nothing. There's no "90% matching." A store either matches its setup in full, or it doesn't.
The areas that all have to match
Reqursor Platform checks six independent areas. Every one has to pass for the store as a whole to count as matching:
| Area | What has to match |
|---|---|
| The systems behind the store | Every piece the store needs exists and is running, and nothing extra is running in its place. |
| Software versions | Every piece of software is running the exact, verified version recorded in the setup (see how versions are locked). |
| Settings & features | Every setting and feature switch matches what was set up. |
| The live store | Checks against the running store (is the homepage the right color, does checkout respond, is the right theme active) all pass. |
| Resources | The store has exactly the computing power it was assigned: no less, which puts performance at risk; no more, which wastes capacity. |
| Separation from other stores | The store's network separation matches exactly what was set up: nothing shared with another store, nothing missing. |
If any one of these areas disagrees with the intended setup, that area is reported as having an unexpected change. See How every change is checked before it goes live for what happens next.
Matching doesn't mean 'well set up'
Matching only means the store matches its own intended setup, not that the setup itself is a good one. A store set up with too little memory will match faithfully while being under-resourced. This check is about accuracy, not a judgment about quality.
What you'll see as an agency operator
This check feeds directly into the health status you see for each store; see How store health is checked for exactly how each one is worked out:
| Status | What it means |
|---|---|
| Healthy | The store matches its setup, and every check against the live store is passing. |
| Degraded | The store matches its setup, but a check against the live store is raising a warning worth a look. |
| Drifting | The store doesn't match: something about it no longer matches its setup (an unexpected change). |
| Failing | A check against the live store is failing, or something that should be running isn't. |
| Unknown | Reqursor Platform couldn't get a clear read this time. It will check again automatically. |
A match isn't permanent
A store that matches today won't necessarily match forever. Someone might change a setting by hand outside Reqursor Platform, a certificate might expire, or something in the systems behind the store might fail: any of these can move a store from matching to not matching. That's expected, not a failure of the platform: it's exactly why Reqursor Platform checks continuously rather than once, and why diagnosing and fixing unexpected changes is its own kind of AI work.
Why this matters for your agency
- A single, clear target. "Matches its setup" means the same precise thing every time, not a vague sense that things look fine.
- Nothing hides in a gray area. Any area that doesn't match is reported specifically, not folded into an overall "mostly fine."
- Trustworthy across all your stores. Because the check works the same way for every store, a status across 100 stores means exactly what it means for one.
Where to go next
How a change is planned, made and checked
The check step that decides whether a store matches, and what happens when it doesn't.
How store health is checked
How the check actually works out the status you see for each store.
Core concepts
Definitions for unexpected changes, separate stores, and the rest of the vocabulary used on this page.
How a change is planned, made and checked
A closer look at the three steps every change goes through: what each one guarantees, and why every change is safe to repeat.
Understanding unexpected changes
How Reqursor spots changes nobody asked for in your stores, automatically, on a schedule, and across all your stores.