This page explains what the “Verified” badge in the Marketplace means, how a module earns it, and, just as important, what it does not mean.
1.1 “Verified” means: a maintainer reviewed one specific version of a module, identified by a pinned commit, on a specific date, following the process on this page. That reviewed version was snapshotted into our vault, and its sha256 hash was published in the public catalog.
1.2 “Reviewed snapshot” means the archive we built from that exact pinned commit. When you one-click install a verified module, you get exactly those reviewed bytes, even if the author’s repository changes later.
1.3 “The catalog” means the public index in the community-modules repository. It lists every module, its tier, and, for verified modules, the pinned commit and the snapshot hash. All of it is public data anyone can check or fork.
2.1 Verification is a point-in-time review of one version. We check that:
2.2 When it passes, we pin the reviewed commit in the catalog, build the snapshot from it (a clean archive: no .git, no symlinks, size-capped), store it in the vault, and write the snapshot’s sha256 back into the public catalog entry. Anyone can verify that what the vault serves is what the catalog says was reviewed.
Before a human looks at anything, every candidate version goes through an automated gate:
The scanner is published as a public GitHub Action in the module template, so authors run the exact same gate before submitting. It is transparent, not a black box.
A scanner is a filter, not a guarantee. Passing the scan means the module cleared a set of automated checks on that day, nothing more. That is why the human review stays.
This is the part that matters most, so here it is plainly:
4.1 Verified is not a warranty. Not an endorsement. Not a security audit. Not a certification. Not a guarantee that the module is safe, secure, bug-free, or fit for your purpose.
4.2 Verified applies to one version at one point in time. It says nothing about earlier or later versions, about the author’s other work, or about what the module will do in your specific environment.
4.3 We review honestly and carefully, but a determined, skilled attacker can hide things from any review of this depth. Treat verified modules the way you treat any third-party software: with sensible caution and current backups.
4.4 Verified modules are third-party software unless the author is Data Universal Limited. The license you get comes from the author. Our review does not make us the author, and it does not create any warranty from us.
5.1 Verification never carries forward automatically. When an author releases a new version, they pin the new commit in a pull request, a maintainer reviews the diff against the previously reviewed version, and only then do we build and publish a new snapshot with its own hash.
5.2 Until the new version is reviewed, the vault keeps serving the last reviewed one. Updates are never pushed to your instance; you choose when to install them.
Review is best effort, with a target of one week from a complete submission (scanner passing, disclosures in order). The automated gate exists to keep the human queue short. Complex modules or busy weeks can take longer; we will not rush a review to hit a date.
7.1 We can revoke a module’s Verified status or delist it at any time, at our discretion, for example if it turns out to be malicious, misrepresented, broken, or abandoned, or if we receive a credible legal or security complaint. For security or legal risk we act first and explain after.
7.2 Delisting stops new installs and sales. It does not reach into your machine: a module you already installed stays in your own modules folder and your backups, and any license you already bought remains yours (it is granted by the author, not by us).
7.3 The permanent promise, whatever happens to a listing or a license: a lapsed or removed module never removes your access to your own data. Your data lives in your own database and stays exportable with the Software’s standard tools, always.
Verification reviews are performed by our maintainers.
To report a security issue in a verified module, contact the module’s author first (the support contact is on the listing), and tell us too at security@celerp.com. If we confirm a problem, we can pull the snapshot and the badge within hours.