How PeptideBenchmark Classifies Testing Transparency

What we mean by public verification, public docs, provider-authored vendor-domain reports, and gated certificate depth in the PeptideBenchmark trust system.

---

PeptideBenchmark now has a more structured trust system than a plain vendor list.

That is useful.

It also creates a new problem:

readers can easily assume that every testing signal means roughly the same thing.

It does not.

This guide explains the four main testing-transparency buckets we now use across:

• /vendors/transparency
• /vendors/compare
• /testing/compare
• and /testing/bridge

Why we separate the categories

The peptide world tends to flatten very different situations into one phrase:

• “lab tested”
• “COA available”
• “verified”
• “third-party tested”

But those phrases can point to very different evidence surfaces.

A vendor that sends readers into a live third-party verification page is not showing the same thing as:

• a vendor-hosted PDF archive
• a provider-authored report image on the vendor domain
• or a storefront where the real certificate layer only appears after login

If we treat all of those as interchangeable, the site becomes noisier and less honest.

1. Public Verification

This is the strongest open pattern in the current system.

We use Public Verification when a vendor publicly routes readers into:

• third-party report pages
• third-party verification pages
• or another directly inspectable public verification surface

The key feature is that the verification path is openly inspectable without login and lives on a provider-side surface rather than only inside vendor-hosted files.

Current flagship example:

• EZ Peptides -> repeated public Janoshik and verify.janoshik.com result paths

What this is good for:

• readers can inspect real linked report surfaces directly
• the vendor is doing more than posting a generic screenshot
• the relationship between vendor and provider is easier to audit publicly

What it does not prove:

• that every current lot matches every linked report
• that every product has the same depth of evidence
• that the chain of custody behind the sample was ideal

2. Public Docs

We use Public Docs when evidence is openly inspectable but the main surface is still:

• vendor-hosted
• or provider-authored while living on the vendor domain

This bucket includes several different patterns, such as:

• public COA archives
• product-page document grids
• downloadable PDFs
• provider-authored files hosted on the vendor’s own site

This is still meaningful.

It is just different from a live third-party verification workflow.

Current flagship example:

• Peptide Partners -> unusually deep public multi-lab archive across purity, endotoxin, heavy metals, and sterility files

Other examples can look narrower:

• product-page COA buttons
• public image/document layers
• named outside-lab files hosted on the vendor domain

What this is good for:

• it creates real public traceability
• readers can inspect more than marketing copy
• it often reveals named outside labs and broader batch history

What it does not prove:

• that the provider itself runs a public verification portal
• that all documents are equally current
• that vendor-hosted files carry the same trust weight as a provider-side verify page

3. Provider-Authored Reports on Vendor Domain

This is really a sub-type inside Public Docs, but it matters enough to call out separately.

Sometimes a vendor hosts documents that appear to be authored by a real outside lab or provider, even though the file itself still lives on the vendor domain.

That is stronger than vague “tested” language.

But it is still weaker than a direct provider-side verification path.

Why we track it separately:

• it preserves credit for real outside-lab attribution
• without overstating the openness of the evidence surface

This pattern matters a lot for providers like:

• TrustPointe Analytics
• Freedom Diagnostics
• and similar recurring names that often show up through vendor-hosted documentation

4. Gated COA / Gated Depth

We use Gated COA when the storefront’s real certificate depth only becomes visible after login.

That does not mean the vendor is hiding fraud.

It means the public-facing experience and the authenticated experience are materially different, and we should describe that honestly.

Current flagship examples:

• Polaris Peptides
• Elite Research USA
• Peptide Supply Co

What this is good for:

• it can reveal much deeper batch/certificate coverage than the public storefront suggests
• it helps us avoid underrating vendors whose open site looks thinner than their real customer-facing certificate layer

What it does not justify:

• showing gated URLs as if they were public evidence
• treating authenticated review as equivalent to anonymous public verification

That is why PeptideBenchmark keeps gated internal-review findings separate from public evidence blocks.

Why this matters on the compare pages

The compare pages are designed to make these differences visible quickly:

• /vendors/compare
• /testing/compare
• /testing/bridge

Without the taxonomy, those pages would collapse into one noisy bucket of “has COAs.”

With the taxonomy, readers can ask better questions:

• Is this vendor strongest at public verification?
• Is it strongest at public archive depth?
• Does it only show real depth after login?
• Is this provider important because it runs verification directly, or because it recurs across vendor-hosted documents?

That is a much healthier way to read the ecosystem.

Why we still use caution even in the strongest bucket

Even the strongest transparency pattern should not be over-read.

Public verification is better than a screenshot.

Public multi-lab archives are better than vague claims.

Named provider-authored files are better than generic marketing language.

Gated depth can still be meaningful editorially.

But none of those, by themselves, proves:

• product safety
• FDA approval
• suitability for human use
• or universal batch consistency across a vendor catalog

The site is trying to help readers separate:

• stronger trust signals
• from stronger claims than the evidence can actually support

The bottom line

The point of this taxonomy is not to make the system more complicated.

It is to make it more honest.

The four practical questions are:

1. Is the evidence public or gated?
2. Is it provider-side or vendor-hosted?
3. Is it a verification path, a document archive, or just a stated relationship?
4. What does that evidence still leave unresolved?

If readers keep those distinctions clear, the rest of the PeptideBenchmark trust system becomes much easier to use well.