Shadow mode: how to trust automation with your stores

The four stages

Every automation that touches your stores should climb the same four steps, and earn each one.

Each automation climbs on its own. One reaching autonomous says nothing about the others.

Stage 1: Read-only

Start every connection with read access only. This stage proves the basics: it can reach your systems, it reads the right stores, and it understands your data the way you do.

Test it against things you already know. Pick a week you remember well and see whether its numbers match yours. Look for the boring mistakes: a closed store still counted, a renamed menu item treated as new, an employee who transferred counted at both stores.

Stage 2: Shadow

Shadow is the most valuable stage, and the one most often skipped.

In shadow, the automation runs on its real schedule, on real data, and writes down exactly what it would have done: "would have texted the manager about two open shifts," "would have set this out time to 10:40 p.m." Nothing is sent and nothing changes.

Review the disagreements

On a regular rhythm, compare the shadow log with what actually happened. Each disagreement is one of three things:

• The automation was wrong. Fix the rule before it moves up.
• Your people were wrong. That's a useful finding on its own.
• Both were defensible. Decide which you want, and write it down.

Prove shadow is actually silent

A shadow run has to write nothing: no edits, no texts, no emails, and no saved state that another job will act on later. "We turned off the send step" is not proof. Run it, then check every place it could have touched and confirm nothing changed.

How long to stay

Long enough to see the cases that matter to you: a busy weekend, a holiday, a payroll week, a store that closed early. Whether it has handled your unusual days matters more than how many days have passed.

Stage 3: Ask-first

Now it proposes and a person decides. Each proposal shows what it wants to do, why, and the evidence, with a clear approve, edit or reject.

Watch for approval fatigue. If someone gets twenty prompts a day, they start tapping approve without reading. Batch proposals into one digest per run, and only ask about things that need a person.

Track what happens to each proposal. Lots of edits means the rule needs work. Steady approval as-is means it may be ready for the next step.

Stage 4: Autonomous, inside limits

Autonomous doesn't mean unlimited. Write down the envelope: which stores, which actions, how large a change, what hours. Anything outside it drops back to ask-first automatically.

Some decisions shouldn't go autonomous at all. A sensible default list:

• Approving payroll
• Moving money
• Contacting guests
• Terminating anyone
• Anything you couldn't comfortably explain to an employee afterward

Kill switches

Every automation needs its own off switch, and someone non-technical needs to be able to use it.

• One per automation. A single master switch gets used too late, because nobody wants to stop everything to fix one thing.
• Fast. Flipping it should stop the next run, not the one next week.
• Fails closed. If the switch can't be read, the automation shouldn't run.
• Tested. Flip it once on purpose, on a calm day, and confirm the next run does nothing.
• A dial, not only a switch. The same control should step an automation back down: autonomous to ask-first, ask-first to shadow.

Read-back verification

"No error" is not "done." Systems accept a request and then drop it, save it to the wrong day, or get overwritten by a sync an hour later.

Done means that after the change, the automation re-reads the source system and sees the new value. A text counts as sent when it shows delivered, not when the send command finished. A timecard counts as fixed when the timecard shows the new time. If a change can't be read back, the log should say so plainly instead of reporting success.

Keep a log of every write: who or what asked for it, what changed, and what the read-back showed. That log is how you answer "why did this change?" months later.

Common failure modes

• Skipping shadow because it's "simple." Simple automations run most often, so their mistakes multiply fastest.
• Shadow that never ends. Without a review habit and a rule for moving up, shadow turns into a log nobody reads.
• A dry run that isn't dry. Disabling one step isn't a dry run if another step still writes.
• Promoting everything at once. Each automation earns its own stage.
• Approval fatigue. Too many prompts and ask-first becomes a rubber stamp.
• Scope creep. The autonomous envelope grows one exception at a time until nobody remembers the limits.
• Success without proof. Reporting "done" because nothing errored.

What to measure

• Shadow agreement: how often its would-have-done matched what your people did
• Ask-first outcomes: share approved as-is, edited, and rejected
• Read-back failures: changes that didn't stick
• Step-downs and kill-switch uses, and the reason for each
• Manager time returned, in hours per week

Before you move an automation up a stage

• It has its own kill switch, and you've tested it
• Its shadow run was proven silent
• You've reviewed every shadow disagreement
• It has handled your unusual days: weekend, holiday, payroll week, early close
• Ask-first proposals are mostly approved unchanged
• Every write is read back and logged
• The autonomous envelope is written down

How we roll out

This ladder is how Poros Ops rolls out every automation: read-only first, shadow until you've seen it handle your stores, ask-first for anything that changes data, and autonomous only where you've decided it has earned it. Every automation has its own switch, and payroll approval and money moves always stay with a person.