🔒 100% private — runs in your browser, nothing is uploaded

How the Trust Checkers Judge — Methodology

The public rulebook for verystep’s four trust tools: what each one reads, how its three signal levels work, what it refuses to claim, and the limits printed on the tin.

Most “AI detector” and “scam checker” products sell certainty: a score, a percentage, a red or green badge. That certainty is manufactured — the underlying evidence (text patterns, address structure, metadata records) cannot support it, and presenting it anyway is how a checker becomes part of the problem. The four trust tools on this site were built under the opposite constraint, and this page is where the constraint is published so it can be checked: three signal levels at most, a fixed disclosure sentence on every tool, and a methodology that names what is never examined.

The sentence every trust tool on this site carries, verbatim: “This tool cannot prove a message is safe.” It is not boilerplate. It is the design constraint the four tools were built under — they report signals, in three levels at most, and they never issue the verdict (“safe”, “scam”, “genuine”, “fake”) that a signal list cannot support.

The cluster rules

Per-tool methods

Scam Message Checker

What it reads

The pasted message text, an optional sender field, and any links inside the text (which are extracted and read structurally, the way the Suspicious Link Checker reads them). Thirty-one patterns in five families — pressure, impersonation, rule-breaking payment and credential requests, story templates, and link forensics — each pattern a documented tactic with a plain-English explanation of why scammers use it.

Signal levels

  • Strong warning signs — high-weight patterns are present (a verification-code or gift-card demand, the safe-account script, an impersonation mismatch). The advice is behavioural: do not act through the message.
  • Some warning signs — lower-weight patterns only (urgency, a link, a callback push). Worth the verification detour before any action.
  • No warning signs found — none of the 31 patterns matched. This level is labelled, everywhere it appears, as the absence of known signals — not as safety.

Limits

Pattern matching cannot read a novel script, a well-forged thread inside a real conversation, or anything about the sender’s actual identity. A clean result on a message that still feels wrong should be treated as an unanswered question, not a reassurance.

Open the Scam Message Checker →

Suspicious Link Checker

What it reads

The address itself — never the page behind it. Sixteen structural checks: scheme tricks (data:, javascript:), the @ sign that hides the real host, IP addresses in dotted, decimal or hexadecimal form, punycode and non-Latin look-alike characters, the registrable domain compared against a built-in table of commonly impersonated brands and their official domains (including names parked in subdomains or doing decorative work in the path), shorteners, stacked subdomains, throwaway top-level domains, hyphen-stuffed names, non-standard ports, bait vocabulary, length and encoding, and a second full address hidden in a redirect parameter.

Signal levels

  • Red rows — structural tricks whose legitimate uses are rare enough that the advice is simply: do not open it from the message.
  • Amber rows — properties shared by many scams and some honest sites (shorteners, cheap TLDs) — a nudge to verify by another route.
  • Clean rows — the check ran and found nothing; the table prints them so the coverage is visible.

Limits

Domain age, blacklist status and the destination page’s behaviour are not checked, by design (see the cluster rules). A freshly registered, structurally ordinary domain hosting a perfect fake passes this tool clean — which is why the result text says so.

Open the Suspicious Link Checker →

C2PA Content Credentials Verifier

What it reads

The file’s embedded C2PA manifest store, parsed and validated locally with the official c2pa-js SDK: hashes recomputed over the file’s data, the claim signature validated against the signer’s certificate chain. The details view shows the signer, signing time, claim generator, declared source type and recorded actions, plus the full assertion list, signature algorithm, certificate serial, every validation status code the SDK reports, and the manifest count. Remote-manifest fetching and live revocation (OCSP) lookups are disabled, so the file triggers no network request.

Signal levels

  • Credentials verified — a manifest is present and validation passes: the record is untampered. Note the boundary printed with the result: a valid signature vouches for the record, not for the truth of what the content shows.
  • Credentials present, validation failed — the file was signed but its signed history no longer matches its content, or the manifest is damaged.
  • No credentials found — the normal state of most files today; it proves nothing in either direction.

Limits

Credentials that live only in a remote (cloud) manifest, and certificates revoked after signing, will not be caught with the network lookups disabled — the trade the privacy rule imposes, stated on the tool itself.

Open the C2PA Verifier →

AI Image Signals Checker

What it reads

Every origin record inside the file, signed or not: a C2PA manifest store (presence and declared source type; the signature itself is the Verifier’s job), the IPTC Digital Source Type in XMP, generator names in EXIF/XMP Software and CreatorTool fields, generator working files saved into PNGs (Automatic1111 “parameters”, ComfyUI “prompt” and “workflow”), JPEG comment segments, and the EXIF metadata layer — camera make and model, capture and file times, and the presence of a GPS block (reported as present; coordinates are not displayed). It also lists the record types it looked for and did not find.

Signal levels

None — deliberately. This tool publishes an inventory, not a level: each record found is listed with where it lives, what it says, and what it does and does not mean. Records are claims by the software that saved the file: usually honest, occasionally absent, removable in seconds. A screenshot of an AI image carries none of them. An inventory is the honest output, so an inventory is what you get — no score, no percentage, no verdict.

Limits

Absence of records is the weakest possible evidence: most pipelines strip metadata, and any record can be forged by the same software that writes honest ones. The tool’s value is positive findings — a generator’s own working notes inside a file are hard to argue with — not negative ones.

Open the AI Image Signals Checker →

The patterns behind the two message-side tools are documented case by case in the Scam Case Library, sourced to FTC and FBI IC3 alerts. When those bodies publish a genuinely new pattern, the pattern lists are extended and this page’s counts are updated in the same change.

⚠️ This page documents methods, not outcomes for any specific file or message. No tool on this site can prove a message is safe, a link is honest, or an image is genuine — the methodology below exists to keep that boundary visible rather than to soften it.

Quick answers

Why don’t the trust checkers just say whether something is a scam?

Because the evidence they can see — text patterns, address structure, metadata records — cannot prove intent or truth. A message with no known scam patterns can still be a scam in a new pattern; a validly signed video can still mislead. So the tools publish signals in at most three levels and carry the fixed sentence “This tool cannot prove a message is safe.” on every result.

The AI Image Signals Checker goes one step further and publishes no level at all — only an inventory of the records found inside the file.

Is anything I paste or upload sent to a server?

No. All four tools run entirely in your browser; your text, links and files are never transmitted, stored, or checked against any external database. That is also why some checks are not offered: domain age, blacklist membership, remote C2PA manifests and certificate revocation all require sending your content to a third party, so the tools decline them and say so.

Two tools load their own machinery from this site on first use (the C2PA verification engine, about 6.6 MB) — the download is of code, not of your data, and your file is never part of any request.

Where do the scam patterns come from?

From the published alerts of the US Federal Trade Commission and the FBI’s Internet Crime Complaint Center (IC3), which build their alerts from real complaint data. The Scam Case Library maps each major pattern to its official alert with a link, and the pattern lists are extended when those bodies document a genuinely new pattern.

Link and image checks are not pattern-sourced in the same way: they apply structural rules (how addresses are built) and published standards (C2PA, IPTC, EXIF) to the item in front of them.

How to use

  1. Read the cluster rules first — they are the contract all four tools share (signals not verdicts, on-device reading, printed “not found” lists, sourced patterns).
  2. Use the tabs to read one tool’s method at a time: what it reads, how its levels work, and the limits that apply to its results.
  3. When a tool’s result surprises you, come back to its limits section before acting on it — each panel names the failure mode its tool cannot see.

About this tool

The second design decision is architectural. Every check runs in the visitor’s browser, on content that never leaves the device. That choice forecloses real capabilities — live blacklists, domain-age lookups, remote C2PA manifests, revocation status — and the tools say so on their own pages rather than quietly omitting the rows. A methodology page that hid those gaps would be marketing; the gaps are listed per tool, in the limits panels, because a reader deciding whether to trust a result needs them more than they need the feature list.

The third decision is sourcing. Detection patterns are not invented in-house: message patterns track the scam alerts published by the FTC and the FBI’s IC3 from complaint data (the companion case library maps patterns to alerts), link checks are arithmetic on address structure, and image checks read published standards — the C2PA specification, the IPTC Digital Source Type vocabulary, and the EXIF, XMP and PNG record formats as saving software actually writes them. When a source body publishes a new pattern, the lists change and this page’s counts change in the same commit.

How it works

The judgement model, stated once for all four tools. Evidence first: a tool may only use what it can read locally in the item itself — pattern matches in text, structural facts about an address, records inside a file. Levels second: findings are grouped into at most three levels ordered by the strength of the documented pattern, never by a computed score; where even levels would overstate the evidence (the AI Image Signals Checker), no level is published. Disclosure third: every result carries what was not checked, and the fixed sentence about not proving safety, at body size, next to the result — not in a footer.

Update discipline: pattern and rule changes are driven by the source bodies (FTC and IC3 alerts for message patterns; the C2PA and IPTC specifications for image records; address-structure practice for link rules), verified against the source on the day of the change, and recorded with the change. This page’s counts are part of the same record: 31 message patterns and 16 structural link checks as of November 5, 2026.

Worked examples

One message through two tools: A text claims a parcel fee is due and links to a payment page. The Scam Message Checker flags the delivery-fee template, the deadline and the look-alike link (strong warning signs). The Suspicious Link Checker, given the same link, flags the brand name parked in a subdomain and the throwaway TLD (red rows). Two independent readings, one conclusion a reader can act on — without either tool claiming to have “detected a scam”.

One photo through two tools: A PNG from a generator carries no C2PA manifest (Verifier: no credentials found — the neutral result), but its “parameters” text block holds the full generation recipe (Signals Checker: Stable Diffusion generation parameters, listed verbatim). The pair illustrates the methodology: signed records and unsigned records are different evidence, read by different tools, reported without blending into a score.

The four tools at a glance

ToolReadsLevels
Scam Message CheckerMessage text, sender field, links inside the text — 31 patternsStrong warning signs / some warning signs / none found
Suspicious Link CheckerAddress structure only — 16 checksRed rows / amber rows / clean rows
C2PA VerifierEmbedded C2PA manifest store, validated locallyVerified / validation failed / no credentials
AI Image Signals CheckerC2PA presence, IPTC source type, generator tags, saved prompts/workflows, EXIF metadata layerNone — inventory only

Frequently asked questions

What does “strong warning signs” actually mean?

It means high-weight, documented patterns are present in the specific item — for example a demand to read out a verification code, payment by gift cards, or the “move your money to a safe account” script. It is a statement about the item’s contents, not a finding about the sender, and the recommended action is behavioural: stop, and re-enter through a channel you chose.

A tool found nothing. Should I relax?

No — and each tool says so next to its empty result. “Nothing found” means none of the specific, listed signals are present in the parts the tool can read. Novel scripts, stripped metadata and structurally ordinary phishing domains all produce empty results. Treat an empty result as the start of ordinary verification, not the end of it.

Why is there no score or percentage?

A score would claim a precision the evidence does not have, and would train readers to threshold-shop (“only 40% scam — probably fine”). Three coarse levels, each tied to a recommended action, communicate everything the evidence supports.

Who maintains the pattern lists?

The lists live with the tools’ source and are updated when the FTC or IC3 publishes a new documented pattern, or when a structural rule or standard changes. The counts on this page (31 message patterns, 16 link checks) are updated in the same change as the lists themselves.

Can I rely on these tools for a business decision?

They are a first-pass reading aid, not a control. Businesses making payment, hiring or publication decisions need verification procedures that do not depend on any single tool — including these.

📦 Embed this tool on your site

<iframe src="https://verystep.com/embed/trust-checker-methodology/" title="How the Trust Checkers Judge — Methodology" width="100%" height="520" loading="lazy" style="border:0"></iframe>

Free to use. The embed shows a small "Powered by Verystep" link.

First time embedding? Read the step-by-step guide →

More free tools