The one rule that shapes everything else
If a claim cannot be traced to a public record, it appears on this site as Unknown. It does not appear as a guess, a rumor, or a plausible-sounding sentence. That rule is the reason several profile pages are short and one profile page is almost empty. The alternative — filling gaps with invented versions, dates, or safety scores — would make the pages look more complete and make the research less honest.
What counts as a "traceable record"
A traceable record is a source that a reader can open, read, and check against the claim it supports. The site uses four kinds of records, and it keeps them separate because they carry different weight:
1. Tracker measurements
ScriptBunker, ScriptBlox, and Rscripts publish version numbers, sUNC scores, and detection flags. These are measurements of function coverage and status. They are the strongest records the site uses for version and sUNC, but they measure one thing: whether standard functions exist and work. They do not measure safety, and the trackers themselves say so. ScriptBunker's standard caveat — that "not marked detected" is not a guarantee of safety and that the tracker does not verify the upstream data — is reproduced on the profile pages because it is part of the record.
2. Project-controlled claims
A website title that says "99% sUNC," a repository description that says "keyless and secure," or a GitBook page that documents a download command. These are claims made by the project about itself. They are recorded because they exist, and they are labeled as claims because that is what they are. A claim is not a measurement, even when it is specific. Swift's 87% and ByteBreaker's 99% are marked "claimed" on their profiles for this reason.
3. Independent behavioral signals
Triage sandbox scores, Joe Sandbox classifications, and Microsoft Q&A reports describe behavior observed outside the project's own ecosystem. A Triage score of 7/10 or a Joe Sandbox verdict of MAL is a stronger signal than a website claim, because it comes from someone who ran the file and reported what happened. It is still not a complete audit. A sandbox can only describe what it observed in the time it had.
4. Domain reputation scans
Gridinsoft trust scores and Cloudflare Radar classifications describe websites, not binaries. A 1/100 trust score on a domain is a warning about the site's reputation, not a malware verdict on the file it serves. The site keeps these separate from sandbox scores for that reason. Velocity and Volcano both have flagged domains; neither flag is presented as a file verdict.
The order matters. A tracker measurement is not the same as a website claim, and a domain scan is not the same as a sandbox score. When a profile page presents them side by side, it is not combining them into a single conclusion. It is showing you the records and letting you see where they agree and where they do not.
What "Unknown" means on a profile page
A dash or the word "Unknown" in a table cell means one thing: no traceable record was found for that attribute at review time. It does not mean the executor lacks a version. It does not mean the executor is unsafe. It does not mean the executor is discontinued. It means the search did not find a public source that could be cited.
The distinction is not pedantic. An empty cell in a comparison table is easy to misread as a negative. The site tries to prevent that misreading by marking empty cells explicitly and by explaining, on the compare page, that a blank cell is not a zero. Medium's profile is almost entirely Unknown because no tracker entry, repository, or community guide was found. That is a description of the public record, not a statement about the executor.
There is a second kind of Unknown that appears on several pages: a gap inside an otherwise filled record. Synapse Z has a 98% sUNC score, but the two failing functions are not named in the public test summary reviewed here. That gap is marked, not filled. A reader who needs to know which functions are missing cannot get that answer from this site, and the page says so.
What this site does not do
- It does not execute the files it describes. No profile on this site is based on a hands-on test. The site compares public records; it does not run binaries.
- It does not assign safety scores. There is no "Safety 99%" gauge on any page, because no source reviewed here provides a basis for one. A tracker measurement and a sandbox score are not safety scores, and the site does not treat them as such.
- It does not invent versions, dates, download URLs, or user counts. Where a number appears, it comes from a cited source. Where no number exists, the page says Unknown.
- It does not link to downloads on profile pages. The Download buttons are placeholders. The site does not host executables, and it does not embed links to sources it has not verified.
- It does not claim that a high sUNC score means an executor is safe. sUNC measures function coverage. The site repeats that distinction on every profile that includes a score.
Why some pages are short and some are long
The length of a profile follows the record, not a word count target. Xeno has a long page because Bitdefender published a detailed analysis of fake installers and the public repository describes a specific loader architecture. There is a lot to compare. Medium has a short page because no record was found. Cosmic has a long page because three separate sources — a tracker, a DevForum post, and a GitBook — each describe a different part of the picture.
Padding a short record to match a long one would require invented context. The site does not do that. A reader who lands on Medium's page and finds an empty record has learned something real: the public evidence for that name is thin. That is a more useful outcome than a page that looks complete and says nothing verifiable.
Corrections
If a claim on this site is wrong and you can point to a better source, the claim should change. The correction route is described on the About page. A correction is not a comment or a counter-claim; it is a source that contradicts what the page says. If the source is stronger than the one the page used, the page will be updated and the change will be recorded in the Changelog.
The Changelog records dated changes that actually happened. It does not record pages that were "refreshed" without a substantive change. If a page's last-reviewed date changes, it means the page was reviewed, not that it was rewritten.
Methodology questions
Why does the site use trackers if trackers are not audits?
Because a tracker measurement is better than no record. A version number from ScriptBunker is a dated, specific fact. It does not tell you whether the binary is safe, but it tells you what the tracker observed. The site uses trackers for what they measure and marks the limits of what they measure.
Why not combine all the signals into one score?
Because a combined score would hide which question is being answered. A high sUNC score and a low Triage score describe different properties. Combining them into a single number would imply a precision that the underlying records do not have. The site keeps them separate so a reader can see which signal is which.
What does "checked 2026-10-21" mean?
It means the sources on the page were reviewed on that date. It does not mean every source was re-downloaded or that every tracker entry was re-verified. It means the records cited were the ones found and read at that time. Tracker data changes; the date exists so you can judge the gap.
Does the site have a position on whether executors are safe?
No. The site has a position on what the public records say. It does not conclude that any executor is safe, and it does not conclude that any is malware unless a sandbox or research report says so about a specific file. The site's position is that the records should be presented without being merged into a verdict they do not support.