- 01Find
- 02Understand
- 03Edit
- 04Recheck
- 05Repeat
Less repetitive catalog work.
Find catalog problems and fix them without repeating unnecessary steps.
PROVEN identifies problems it can observe and shows why they were flagged. For supported, safe fixes, it uses repeatable rules. When interpretation is needed, you decide manually or review an AI proposal. Supported changes can be verified after application.
- 01Detect
- 02Explain
- 03Review
- 04Fix
- 05Verify
12 stores in the estimator dataset3,481 products analyzedTry PROVEN does not modify the store
What PROVEN changes for you
Less repetitive work, without giving up control.
Problems with safe, established rules do not need a fresh decision for every product. PROVEN keeps the evidence and decisions in one workflow; you step in when context calls for a choice.
Stop starting from scratch
For supported fixes, the same safe rule can be reused without reconsidering every product from the beginning.
Decide where it matters
See why a problem was flagged and review changes that need context. AI may propose, but it does not decide for you.
Verify what changed
For supported changes, PROVEN can read the result back after application instead of only displaying a proposal.
AI can propose. It should not decide what is true.
AI can help. Publishing without checking is the risk.
The risk starts when AI-generated text is published as verified fact without adequate checks.
Generate → assume it is correct → publish
Detect → evidence → rule or proposal → validate → review where required → apply → verify
Controlled workflow
Detect. Evidence. Fix. Verify.
Instead of repeating the same reasoning product by product, PROVEN keeps the problem, evidence, decision, and result in one workflow. Review remains where context requires it.
- 01
Detect
Find observable problems in catalog data.
- 02
Evidence
Connect the problem to the observed data and the reason it was flagged.
- 03
Decide
Separate what can be computed from what needs review or a proposal.
- 04
Fix
Edit manually or use a supported PROVEN method.
- 05
Verify
For supported changes, PROVEN reads the result back after application.
- 06
Monitor / recover
The catalog can be checked again over time, with restoration available where it is safely supported.
Before → PROVEN → After
See the difference between a safe rule, a merchant decision, and an AI proposal.
PROVEN does not force every problem through the same method. The path depends on what can actually be established from the catalog.
Language / diacritics
- Before
- “fata”
- PROVEN
- Detects that the form may be ambiguous and does not invent the intended meaning.
- Merchant
- Chooses “fată” or “față” when context does not provide a safe answer.
- After
- “fată” / “față” — according to the merchant decision.
HTML / structure
- Before
- Redundant markup, empty blocks, or detectable inline styles.
- PROVEN
- Uses a deterministic transformation only when a supported rule is safe.
- Merchant
- Can review the change before publishing.
- After
- The resulting structure stays connected to post-change verification where that verification is supported.
Title / SEO that needs writing
- Before
- The value needs interpretation or writing, not just an exact transformation.
- PROVEN
- AI can generate a proposal for supported fields without automatically replacing the existing value.
- Merchant
- Reviews the proposal and decides whether it enters the change.
- After
- Only the approved value continues through the apply workflow.
Operational evidence
The estimate starts from real checks, not a demonstration catalog.
The estimator uses the latest eligible result from each distinct store, so repeated checks of the same store do not count more than once.
What we observed in the estimator dataset
distinct stores
Each store contributes one eligible sample to the distribution used by the estimator.
products analyzed
Calculations use products actually analyzed in eligible runs, not the number initially requested for a scan.
observed findings
The aggregate volume shows how different issue profiles can be across catalogs; it is not presented as a market average.
What the product can verify
- 67 public catalog checks are published in the current capability set.
- For supported changes, PROVEN can read the result back and verify it after application.
- The boundaries and availability of each capability remain published separately in Capabilities.
The estimator includes one completed check and 11 partial checks. These figures describe what was observed, not a market average or a promise for any particular store.
See the documented image case studyCatalog estimator
What could it cost to fix your catalog?
Tell us how many products you have and the primary language. Get an instant indicative range for issues, automatic fixes and Fix Credits — without scanning your store or entering a domain.
Change the number at any time. The estimate updates instantly.
For Romanian we also include observed orthography issues. For other languages we estimate only language-independent issues.
Where issues usually show up
- Text and formatting
- ≈ 384
- HTML et balisage
- ≈ 182
- Duplicate content
- ≈ 30
What that could mean for your budget
Loading current public rates for the cost estimate.
How is this estimate calculated?
The data is aggregated and anonymized. We use the latest eligible result per store so repeated checks of the same storefront do not influence the estimate more than once.
The range represents the central observed band across stores (P25–P75), while the typical value is the median (P50). Most source checks were partial and the calculation uses only products actually analyzed. This is an indicative estimate, not a promise for your store.
Romanian currently has enough operational evidence to include orthography fixes. For English, French and mixed catalogs, that language-specific component is not estimated yet.
Platforms and languages
The same PROVEN model, with clear boundaries for each integration.
Shopify has the deepest integration. WooCommerce is already an active integration, but it is not presented as having full Shopify parity.
The complete PROVEN workflow is most mature on Shopify.
It includes catalog checks, controlled fixes, batch actions, catalog monitoring, restoring supported changes, image operations, agency tools, billing, Sidekick, and audit.
On Shopify, one batch action can include up to 200 findings. This is not unlimited fixing.
PROVEN already runs against WooCommerce catalogs.
The WooCommerce product view compares the title, description, and ALT text before and after each proposed change for approval. Batch fixes for up to 10 items and controlled restoration are in limited rollout. Image-file optimization is separate from ALT editing and is not yet available to everyone.
WooCommerce billing and the same webhook notifications and monitoring coverage as Shopify are not publicly available. Restoring changes and optimizing images have separate rollout limits; WooCommerce does not yet offer every Shopify feature.
Romanian and French are already part of the checking engine.
PROVEN includes dedicated checks for Romanian and French language cases, including potentially missing diacritics, without turning ambiguous cases into automatic corrections.
Dedicated checks for forms that may need diacritics, separating clear candidates from ambiguous cases.
Dedicated checks for potentially missing diacritics; identified cases remain for review when a correction is not safe.
For the exact boundaries of each integration and language, Capabilities remains the public source of detail.
Start with your store
See which problems PROVEN can find in your store.
Start with a free check of a public Shopify store. Try PROVEN uses only public information it can observe, does not access Shopify Admin, and does not modify the store. See the problems observed and the limits of the check, then request access to PROVEN if you want to continue.
Request access to PROVEN The app is not yet in the Shopify App Store. A request is not an installation or subscription.