What our verification does not prove
We sell evidence, so the limits of that evidence are part of the product. A green live-tested badge is a narrow, specific claim. This page is the boundary of it, written down in one place so you do not have to infer it from what we happened not to say.
The exact claim a live test makes
This module was applied to a real cloud account, asserted against, and destroyed, with the teardown confirmed. One account. One day. One set of inputs, which are the ones in the module's own test fixture. That is the whole claim, and 116 of 183 modules carry it.
What that leaves open
It does not prove the module is right for your environment.
The fixture uses defaults chosen to exercise the module, not to match your compliance posture, your network layout or your naming policy. A module that applies cleanly can still be the wrong shape for you.
It does not prove it works with your inputs.
Terraform modules branch on their variables. The live test walks one path through that branching. A combination the fixture never sets can still fail at apply, and the more configurable the module, the more of its surface a single test leaves untouched.
It does not prove it is still true today.
Providers ship breaking changes. A test that passed in June was true in June. The receipt carries the date it ran precisely so you can judge how stale it is, rather than reading a badge with no time attached to it.
It is not a security audit.
Security scanning is a separate axis and a separate claim. Today 132 modules pass a Checkov scan, 50 have no policy that applies to them, and 1fail. A scan is a policy engine reading configuration, not a person reasoning about your threat model, and “no applicable policy” is an absence of coverage rather than a clean result. The catalogue keeps those two apart everywhere it reports them.
It does not prove the composition works.
A module passing alone says nothing about it wired to five others. That is a different claim, and where we have earned it we say so separately: a reference architecture can carry a root live test, meaning the whole composition was applied as one unit. Running the landing zones that way found three real wiring bugs in modules that had each passed on their own.
It does not prove your cloud will behave the same.
Quotas, organisation policies, service control policies and region availability all differ per account. Our account is not yours, and a module that applies in ours can be refused in yours for reasons that have nothing to do with the code.
What is still yours to do
Read the plan before you apply. That is the single highest-value step and no amount of upstream testing replaces it, because only you know what the target account is supposed to contain. Check the module's inputs against your own policy rather than trusting defaults. And check the freshness date on the evidence against how fast your provider moves.
If you want the evidence enforced rather than merely published, Vizier checks a module against an evidence floor you set and refuses to run one that does not clear it. That turns this page from advice into a control.
Why this page exists
Any vendor can put a green tick on a page. The tick is worth something only if the thing it stands for is written down, narrow, and checkable. Publishing the limits alongside the claim is the same discipline as publishing the receipt: it lets you disagree with us using our own data.
The receipts are public and need no account. Start with choosing a module by its evidence or read the verification ladder in full.