When a scheduled report stops answering the question it was built for

A schedule is a captured definition, not a live link

When you schedule a report in Assisty, the schedule captures that report exactly — breakdown, time range, filters, columns — including the reports you built by asking Atlas. That capture is the whole point. It's why this week's file has the same shape as last week's, why the columns land in the same order, why a downstream sheet or a Flow trigger doesn't break on a cadence you set months ago.

The same property has a second face. A captured definition is a description of your store written on a particular day — these vendors, these locations, these product handles, this window. Your store doesn't hold still afterward. So the schedule keeps executing a description that is slowly becoming a description of a store you used to have.

What makes this hard to catch is that nothing fails. The run completes. The email arrives at the hour you picked, in your store's timezone, with a CSV attached, exactly as configured. Monitoring — any monitoring — generally watches whether the job succeeded, not whether the contents still mean what they meant. On-time arrival is evidence the schedule ran. It is not evidence the numbers are still answering your question.

What moves underneath a report: the catalog, the locations, the vendors

Catalog churn is structural, not an incident. It's what a growing store looks like. But a filter written as an explicit list cannot include something created after it was written — a variant added last month isn't in a list assembled the month before, and the filter doesn't complain, because from its side nothing is wrong.

The rest of the moves are just as ordinary. A SKU renamed mid-period splits its own history: historical orders keep the old SKU, future orders carry the new one, and a report grouped by SKU shows two partial rows where you expect one. A product retired or deleted stops contributing — Shopify's own guidance is to archive rather than delete, precisely because deletion removes the product's data from analytics. Shopify also permits duplicate SKUs across variants, so a "units sold by SKU" view collapses them silently. A location opened or closed changes what an inventory breakdown even covers. A product reassigned to a different vendor moves from one recipient's report to another's.

None of it produces an error row — a file with roughly the number of lines you expect reads as normal, not as a warning.

Diff last month's file against this week's

There's nothing in the schedule that compares runs for you, flags a changed row count, or marks a definition stale. What Assisty does give you is the raw material to check by hand: every run is kept in history — with the file it sent, re-downloadable any time. Past runs show as Done with their CSV; the next one shows as Upcoming. So the comparison is a person opening two dated files side by side, one pulled from a month ago and one from this week.

Compare in a fixed order, cheapest signal first. Row count — a big move tells you something changed; a flat count tells you nothing either way, which is why it's the first check and not the only one. The filter-bounded set — are the products, vendors, or locations you'd expect actually present, and has anything new in the catalog failed to appear? The column list — same columns, same order, same meanings. The time range endpoints — does the window still start and end where you think it does? Shopify's Help Center documentation on inventory reports is worth knowing here too: historical data for inventory-based metrics goes back only to October 1, 2023.

Semantic drift is the industry name for this — the same metric quietly diverging as filters and time logic fork across copies. The governance answer isn't tooling, it's ownership: someone owns each definition and reviews it on a cadence. After you change anything, Run now sends a test delivery the moment you save, which gives you a fresh, dated baseline to diff against next time.

Override the schedule, or rebuild the report

The diff tells you what moved; it doesn't tell you which of two repairs you need. Ask whether the definition is wrong for one recipient or wrong for everyone.

Wrong for one recipient means the report is fine and the delivery isn't — the warehouse lead wants fewer columns, one vendor's buyer wants only their products. That's an override: edit a schedule's columns and filters without touching the report itself. The source report stays canonical for everyone else.

Wrong for everyone means the definition itself has aged out, and patching a schedule only hides it. Rebuild upstream. Ask for what you actually need now in plain English — sales, inventory, forecasting, replenishment, lost-revenue, or stock-availability, by product, variant, category, vendor, location, customer, or over time — and Atlas answers with a live table from your synced store data. Refine it by talking: "Add gross profit." "Show the last 90 days." "Just the top 20." Atlas changes only what you asked for and keeps the rest intact, every filter showing as a chip you can remove. Save it and it joins My Reports beside your custom reports, then schedule the corrected report the way you'd schedule any other.