ElanoryaJewelry AI
Why the tool list can change without an app update
You did not update, reinstall or change a setting, and the set of tools you can use is not the same as it was. That is the expected behaviour of a decision that is held on the server: it can change over time, on its own schedule, while your copy of the app stays exactly as it is.
The decision is not in your copy of the app
Every tool in the app has a record on the server, and that record — not the build on your phone — carries whether the tool can be used. The code that defines those records says it plainly: it is the server source of truth for tool visibility and availability, and the mobile app must not trust visibility on its own. The app is a client of that answer.
That is why the change you noticed has no explanation on the device. Your app version did not change, your account did not change, and there is no user-facing switch for tools to have been flipped. What changed, changed on the other side, and it changed for the deployment rather than for your particular phone.
The app does settle some things on its own — whether a picked file is in an accepted format, for example, is decided on the device before any upload begins — but tool availability is not one of them.
What actually has to be true for a tool to be usable
Four facts, all of them read from the code that defines the tool records. Everything else on this page follows from them.
- The records are server-side, and the app is told so.
- The definition is annotated as the server source of truth for tool visibility and availability, with an explicit instruction that the mobile side must not trust visibility alone.
- Two things, not one, are needed to turn a tool on.
- The availability value on the tool's record is flipped, and a cost record is seeded for that tool. Both, or the request that creates a generation refuses it.
- Neither of those two steps is an app release.
- This is the whole of the answer to "but I did not update". The change reaches you without anything being installed, because nothing about it was ever in the install.
- Two tools are bound to a deployment flag as well.
- background-remove and image-edit are tied in code to named environment flags, BACKGROUND_REMOVE_ENABLED and IMAGE_EDIT_ENABLED. That binding is a fact about the code; what the flags read in a deployment is not.
The sequence a tool goes through to become usable
This is the mechanism, in the order the code applies it. It is written here so you can see where your phone appears in it — it does not.
The availability value on the tool's record is set.
The record is the one the server holds. Setting the value is a server-side change and does not travel to you as an app build.
A cost record is seeded for that same tool.
This is the second half of the pair. A tool marked available with no cost record seeded for it is not a usable tool — the request that starts a generation refuses rather than proceeds. The check closes toward refusal, not toward allowing.
If the tool is bound to a deployment flag, the flag is read too.
For a flag-bound tool, the availability check reads the environment flag as well as the record. Unless it reads exactly "true", the tool is off, and the check never falls back to treating it as available.
Your app asks, and reports what it is told.
The app holds no part of this. It does not cache an entitlement it can be talked out of and it does not decide on its own; the instruction in the code is that it must not trust visibility alone. Which is why the answer can be different tomorrow with the same app installed.
Each condition, and what follows from it
Read this as the shape of the mechanism. It is not a statement about the state of any tool in any deployment.
| Condition on the server side | What follows |
|---|---|
| Record marked available, cost record seeded for that tool | The tool can be requested |
| Record marked available, no cost record seeded | The request that creates a generation is refused |
| Tool bound to a deployment flag, flag reads anything other than exactly "true" | The tool is off, and the check never falls back to available |
| Anything at all changed on your phone | No effect — the phone is not an input to this |
Where this catches a working seller out
The mechanism is simple. The trouble comes from acting on the assumption that the phone decides.
Time spent on the device — reinstalling, factory-resetting, trying a second phone — after a tool stops being available.
None of it is an input. The record is server-side and the app is instructed not to trust its own view of visibility, so a clean install asks the same question and gets the same answer.
A delivery date promised to a client on the assumption that a tool will still be available on the day.
Check on the day, not on the day you promised. The answer is read at the moment of asking, and it can differ from the one you got when you made the commitment.
Hunting for a setting that would explain it, and concluding the account is broken when none turns up.
There is no user-facing switch for tools. Nothing turns up because there is nothing to find, and the absence is not a sign of an account problem.
Treating a tool that becomes newly available as a sign that the app updated itself behind your back.
It did not. Both conditions that make a tool usable are server-side, so the set of tools can widen while the build on your phone stays exactly as installed.
What this page does not settle
Stated so you do not read an answer into silence. Each of these is a thing the code does not record.
- Whether any particular tool is available in the deployment you are using. The flag value cannot be read from the code and is not guessed.
- When a tool that is off will be on. No date and no ordering is recorded, so none is offered.
- How the app presents a tool that is not available to you. That is not part of the mechanism described here.
- Why a particular generation of yours failed to start, or how credit is handled around a refused request. Those are separate matters with their own answers.
- What a tool does once it is available to you. This page is only about the decision that puts it in front of you.
Questions
Will reinstalling the app bring back a tool that disappeared?
No. The record that decides availability is held on the server, and the app is written not to trust its own view of it. A reinstalled app asks the same question and is given the same answer, so the only thing the reinstall costs you is the time.
Is there a setting somewhere that turns tools on and off?
There is no user-facing switch for tools. Nothing you can reach in the app, and nothing about your device, takes part in the decision.
Can a tool become available without me updating the app?
Yes. Turning a tool on means flipping the availability value on its server record and seeding a cost record for it — both server-side. Neither one is delivered as an app build, so the set of tools you can use can change while your installed version stays the same.
You mention BACKGROUND_REMOVE_ENABLED and IMAGE_EDIT_ENABLED — does that tell me those tools are off?
No. What is recorded is only that those two tools are bound in code to those named deployment flags, in addition to their records. What a flag reads in a running deployment cannot be determined from the code, so this page makes no claim about it in either direction. What is recorded about the check itself is that it does not fall back to available: unless the flag reads exactly "true", the tool is off.