What Arvio Won't Touch
Giving an AI write access to your product catalog is not a feeling you talk yourself into. It is a question about mechanics: what does it say it's going to do before it does it, and can you put things back afterward?
Three things carry the weight. Before any write, a confirmation card names the scope of that specific run. After the write, a result card restates what changed and tells you it can be undone. And every change lands in Shopify Admin, where you can look at it without asking us anything.
That's the whole answer, and it is worth being exact about its shape. The limits below are per-run and mechanical — the scope of a change is named before it happens, and it is reversible after — rather than a standing list of operations Arvio will never perform. If you came here for that list, the next section is the honest version of why there isn't one. The rest of this piece is the part most vendor pages skip: what we do not have, and how to verify the rest for yourself.
First, what we don't have
We do not publish a formal document that lists, operation by operation, the things Arvio will never do. No signed schedule of forbidden actions, no permanent rule you could hold us to in writing.
We could write one. We haven't. A list like that is only as good as the enforcement behind it, and the enforcement we have today is not a document — it's the two cards described below, plus Shopify's own record of every change.
So read the rest of this as a description of how the product behaves in the runs we've recorded, not as a promise about every run forever. Those are different kinds of statements.
Before anything is written, the card names the scope
Arvio doesn't ask for permission in the abstract. It asks about one specific pending change, and it says out loud how far that change reaches.
In the run we recorded on our own demo store, the confirmation card carried this line:
Only this product will be updated — all others left untouched.
Next to the card's heading sat one more word in parentheses: (reversible).
That sentence is a receipt for that run's scope, not a statement about what Arvio is capable of. The prompt driving that particular task said, in so many words, to leave every other product untouched — and the card was confirming it had understood the boundary it was given. Read it as "here is the scope of the thing I'm about to do," not as "I don't touch other products." Arvio absolutely can work across more than one product. That's largely the point of it.
The App Store listing says the same thing from the other direction:
One product, a batch you pick, or all of them — you choose the scope
That's the actual boundary: not a rule we wrote down, but a decision you make each time, printed back at you before the write happens. If you want to see what a finished change looks like when it lands, we walked through one in what it actually looks like when Arvio writes the fix.
The undo path
The second thing holding up write access is that the writes come apart again.
From the listing's feature list:
Approve or reject each change one by one; undo any edit in one click
And from the product description on the same listing:
You approve or reject them one by one, and any edit undoes in one click.
After a change goes through, the result card repeats the scope and then adds the exit:
All other products left untouched.
This action can be undone. Let me know if you'd like to revert it.
Approval is per change, not per batch. You are not handed a pile of edits and asked to bless the pile. Each one stands or falls on its own, and a reverted edit doesn't drag the others back with it.
A rule tells you what someone intends. An undo tells you what you can do when the intent and the outcome part ways.
How to check it yourself
You don't have to take the cards at their word.
Follow the Admin link. Every result card ends with an exit into Shopify:
View in Shopify Admin →
That drops you on the product in your own admin, where the change is just a change — visible, editable, and revertible by you, with or without us. Shopify's own edit history is the record here, not ours.
Start with one product. The scope control exists so you can use it. Point Arvio at a single product you know well, read the confirmation card, let it write, then compare. One product tells you most of what a hundred would.
Compare the catalog before and after. On our demo store we took the whole catalog on either side of a run. Sixty-eight products going in, sixty-eight coming out — nothing created, nothing deleted. One of them was different: an Acacia Round Tray, whose description went from 62 characters to 364. That is one run, on a store we own, from a prompt we wrote ourselves — it demonstrates that the check works and what a clean result looks like, and it is not evidence about how Arvio behaves on catalogues we have never seen. The point of putting it here is that you can run the same comparison on yours, where the result is about your store rather than ours.
One product changed out of sixty-eight, because that run's scope was one product. That's the shape of evidence you can generate yourself on any store, with no cooperation from us: export before, export after, diff the two.
We prefer this to a policy document for a reason that has nothing to do with modesty. A policy document is a claim. A catalog diff is a measurement, and you can take it yourself.
It can be wrong, and it says so
There's a line sitting at the bottom of the interface the whole time you're using it:
Arvio is AI and can make mistakes — please verify before acting
That's the operating assumption the rest of the design is built on. The per-change approval flow, the undo, the Admin link — those only make sense if you assume some changes will be wrong and you need a cheap way to catch and reverse them. A product that believed its own output was always right wouldn't need any of that machinery.
The sequencing follows from the same assumption. Arvio writes first and asks second, which sounds backwards until you've reviewed a report. From the listing:
You shouldn't have to know what's broken. Arvio reads every product nightly and writes each fix.
A report hands the work back to you. A written draft hands you a decision. We made that case at more length in why we write the fix instead of reporting the problem — and the reason that trade is acceptable at all is everything above: the draft is scoped, it's approved one at a time, and it comes apart in one click.
We'll say it: you might not need us
The last line of our own App Store description says this:
If your catalog is small and rarely changes, you don't need us.
We left it there on purpose.
If you run a small catalog and you touch it yourself every few weeks, you already have what Arvio provides. You know your catalog. You'd spot the gap faster than any nightly pass would, and you'd fix it in the time it takes to read a confirmation card. Installing us would add a review queue to a job that didn't have one.
The math changes at scale and at churn. A catalog you inherited, or one that turns over faster than you can keep up with, and the bottleneck stops being knowing what's wrong and becomes someone actually doing them. That's the gap Arvio fills. If that's not your gap, we'd rather you found that out from us than from a month of paying for a queue you don't read.
Arvio: AI Store Operator — install it on the Shopify App Store. It writes the change, then waits for you.
FAQ
The card says "all others left untouched." Does that mean Arvio never touches other products?
No — and this is the single most important clarification in this article. That line is the scope receipt for that particular run, which had been asked to work on one product and leave the rest alone. It confirms the boundary Arvio was given, not a standing limit on what it does. Arvio works across a batch you pick or the whole catalog when that's the scope you set. Read each card as a statement about that run.
Is there a document listing the operations Arvio will never perform?
No. We don't publish one. What we have instead is per-run scope stated on the card before the write, per-change approval, one-click undo, and Shopify Admin as the independent record. If you need a written boundary for a procurement process, ask us rather than assuming the page you're reading is one.
What happens if a change is wrong?
You reject it at the approval step, or undo it afterward. The listing puts it as: any edit undoes in one click. The result card says the same: This action can be undone. And the interface carries a standing reminder that Arvio is AI and can make mistakes and you should verify before acting — the review step exists because that's true.
Can I try it on one product before letting it near the catalog?
Yes, and we'd suggest it. The listing describes the scope choice as one product, a batch you pick, or all of them. Start at one, read the confirmation card, approve, then look at the result in Admin. You'll learn more from that than from any description we could write.
How do I independently verify nothing else changed?
Export your catalog before a run and after it, and diff them. On our demo store that comparison showed sixty-eight products before and sixty-eight after, with one product different — the Acacia Round Tray, description 62 characters to 364. Nothing created, nothing removed. You can run that check on your own store without us being involved.
Does Arvio need access to my theme or storefront code?
Arvio is an AI Store Operator working on your product catalog — it reads your products and writes changes to them, which you approve one by one. We are not going to make a permanent claim here about every surface in your store; what we'll tell you is that the permissions Shopify grants an app are visible to you in Admin before you install, and you should read that screen rather than take a blog post's word for it.
What if I'd rather it just told me what's wrong?
Then you want a report, and there are plenty of those. Our position is that a list of problems moves the work back to you, which is the same place it was stuck. Arvio writes the change and then waits, so the thing you're deciding on is a finished draft rather than a task.