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.
How every change is checked before it goes live introduces the three steps every change runs through: plan, apply, and check (Reqursor Platform calls the last one reconcile). This page goes one level deeper: what actually goes into each step, what each one guarantees, and what happens when something doesn't go as expected.
Plan: deciding, without doing anything yet
A plan is worked out before a single real change happens. Given the same starting point, Reqursor Platform always produces the exact same plan: nothing about when it runs, which server creates it, or what happened in earlier runs changes the result.
| What goes into a plan | What deliberately doesn't |
|---|---|
| The store's current recorded setup | The current time or date |
| A fresh check of what's actually running right now | Which machine happens to create the plan |
| The rules that fit your store platform (see How Reqursor works with your store platform) | Anything left over from a previous run |
| Reqursor Platform's own operating rules (retry behavior, keeping stores separate) | Whether a person or the AI proposed the change |
The output is an exact, ordered list of every individual step needed to close the gap between what's running and what's intended. Some steps depend on others (a store's private network has to exist before anything can connect to it, for example), and that order is worked out as part of the plan, not improvised later.
Nothing changes yet
A plan is a preview: a complete, reviewable list of what's about to happen, saved before any real change begins.
Apply: doing exactly what was planned
Apply's job is narrow on purpose: carry out the plan, and nothing but the plan.
- Does only what's in the plan. No step is added, removed, or reordered on the fly, no matter what it notices along the way.
- Follows the plan's order. A step never starts before every step it depends on has finished successfully.
- Checks before and after every step. Before a step runs, Reqursor Platform confirms that whatever it depends on is actually in place. After it runs, Reqursor Platform verifies the step achieved what it was supposed to: a step can run without error and still not produce the expected result, and Reqursor Platform catches that difference too.
- Records the outcome of every step. Success, failure, or skipped: every step's result is recorded. Nothing disappears silently.
- Stops rather than improvises. If a step fails, the default is to halt the rest of the change rather than push ahead into a half-changed store. The steps that already succeeded stay as they are; nothing is left partly done without a record of exactly where it stopped.
Check: confirming the result
Once apply is done (or on its own, for a routine check), the check step compares the real store against how it is supposed to be set up and reports whether they match. See How Reqursor confirms a store is set up as intended for exactly what "matches" means, area by area.
The check reports, it doesn't fix
If the check finds a mismatch, that's the end of its job: it produces evidence, not a fix. Acting on that evidence (applying the change again, or something else) is a new step that you confirm separately.
Why this matters for your agency
- No surprises mid-change. Every step was decided before anything happened; apply never makes a judgment call you didn't already see coming.
- Failures are visible, not silent. You'll know exactly which step didn't work, and why, rather than being left to guess.
- The same three steps run every time, for a brand-new store or the five-hundredth change to an existing one.
Where to go next
How every change is checked before it goes live
How these three steps fit into Reqursor Platform's larger safety approach.
How Reqursor confirms a store is set up as intended
The exact conditions the check uses to decide whether a store matches its intended setup.
How Reqursor works with your store platform
Where the platform-specific steps inside a plan actually come from.
Six ways your store's setup gets written
Building a new store, moving one over, changing a live one, fixing a problem, editing by hand, and using a template are six ways a store's setup gets written, and all are treated the same once you confirm.
How Reqursor confirms a store is set up as intended
The exact conditions, across every area, under which a store matches its intended setup.