Terminology

The explorer starts with a package and its versions: which advisories match, which versions matched, and whether the checks can answer. Platform and build results, patch status, and source coverage remain separate facts.

The explorer's package versions come from conda-forge repodata. A PyPI, npm, GitHub, or other upstream identity links a conda-forge package to advisory data; it does not change where the listed releases were published.

Headlines describe the selected scope. “This version matches no advisories” describes one version; “No versions matched” describes the checked package history. A history summary such as “12 versions match 4 advisories” counts package versions and distinct advisories separately. The source-reported ranges and matcher details explain these answers in the evidence disclosures.

Advisories and severity

Term	Definition
Advisory	A source record describing a vulnerability or malicious package. Basilisk groups records with a shared canonical ID into one advisory in the explorer.
CVE ID, for example `CVE-2023-50447`	An identifier assigned to a vulnerability. Other databases may use different IDs for the same issue.
Alias / other ID	Another known identifier for the grouped advisory, such as a GHSA or PYSEC ID.
Severity / CVSS	The impact reported by an advisory source. CVSS scores range from 0 to 10; the score does not establish whether a particular version, build, or installation is affected.
Malware	A package reported as malicious, rather than a vulnerability in otherwise legitimate software. It may have no CVSS score.
Not scored	No usable numerical severity score is available in this result. It does not mean low severity.

Version results

Term	Definition
This version matched / matching advisories	The package version matches an advisory's reported affected versions or ranges. This is not proof of exploitability or the absence of a build patch. “Latest version matched” refers only to the latest indexed package version.
This version matches no advisories / no versions matched	The recorded checks found no matches for the selected version or checked package history, respectively. Read this alongside source coverage and freshness; it is not a claim that the installation has no vulnerabilities.
Checks incomplete	The required checks do not provide a complete result for the selected version or history. Some checks may have completed while others are missing or out of date.
Can't check this package	Basilisk has no upstream identifier it can use to check the relevant advisories. A mapping can exist without being usable by a matcher.
Version not found in conda-forge records	The requested version is absent from Basilisk's indexed conda-forge release history. It is not a vulnerability result.
Couldn't determine a match	The available evidence cannot establish which advisories or versions match for the requested scope. Missing, stale, unsupported, or ambiguous evidence can cause this. This is distinct from completed checks finding no matches.
Unresolved matches / other linked reports	Reports linked to a package without an established version match. They may have unevaluated version information or no usable bounds. This describes the match evidence, not the credibility of the report or a scheduled human review.
Count unavailable	Basilisk cannot establish the exact count. Positive matches may still be recorded; an unavailable count is neither zero nor proof that no checks ran.

Evaluation and source coverage

“Evaluated” depends on context. A source-coverage label says a check ran. An evaluated source record can have no matching versions; evaluated on a stored package–advisory match means at least one known version matched.

Term	Definition
Evaluated (source coverage)	A recorded check used the named source revision for this scope. The result may be a match, no match, or inconclusive. Any incomplete-source qualification still applies.
`evaluated` (stored package–advisory match)	At least one known version matched an advisory's affected versions or a usable range.
`unevaluated`	The package identity joined the advisory, but its version information could not be evaluated.
`version_unbounded`	The advisory identifies the product but has no usable version bounds. This does not establish an evaluated match for every version.
Not checked (a source)	No recorded check covers that source for the selected scope. Other sources may have been checked.
Source unavailable	The source or a usable identity needed to check it is unavailable.
Stale evidence	An input changed after the recorded evaluation. A retained positive result is historical evidence, not proof that the current inputs have been evaluated.
Partial coverage	Some required evidence or checks are incomplete. A positive match can coexist with partial coverage.
Source-data timestamp	A timestamp recorded for source data. It does not by itself prove that a complete source synchronization succeeded.

Version, platform, and build scope

Term	Definition
Package history / all versions	A query across the indexed release history. Finding a matching version does not mean every version matches. History advisory totals count each grouped advisory once.
Platform	A conda artifact subdirectory, such as `linux-64`, `linux-aarch64`, or `noarch`. It describes the published artifact, not every detail of the environment where it is installed.
Build	A published artifact identified by its version, platform, build string, and filename. Different builds of the same version can contain different bytes.
Match result / matches your selection	Whether the selected version, platform, or build matches the advisory's version and platform conditions. “Does not match your selection” is specific to that advisory and scope, not a general safety claim.
This version matches on some platforms	A platform-specific match exists, but no particular platform or build was selected. Read the platform results rather than treating it as a package-wide positive. Platform conditions alone do not establish a match.
All platforms (result grouping)	Current, complete source evidence reports a match without a platform restriction. It does not establish patch status or exploitability.
All indexed platforms	The complete indexed artifact inventory agrees for the listed versions. Source platform conditions still apply; this is not the same as unrestricted evidence.

Fixes and publication

Term	Definition
Reported fixed version	A source-reported fixed boundary, or a version resolved from source-reported fix-commit evidence. Publication on conda-forge is a separate fact.
Fix committed upstream	A fix commit is recorded upstream. It may not belong to a release or map to a conda-forge version.
No fixed version identified	This result does not identify a fixed version. A fix commit or backport may still exist. More specific source evidence can distinguish no reported fix from a fix committed upstream without an identified release.
Version published on conda-forge / version not found on conda-forge	Whether the exact reported version spelling exists in the indexed conda-forge releases. Publication does not establish platform compatibility or prove that every build contains a security fix. Unknown publication remains a separate state.
Fix could not be mapped to a release	Basilisk could not associate the upstream fix with a conda-forge release. This does not prove that no published build contains the fix.
First version with no matches to these advisories	The first indexed release outside all the reported ranges in the stated advisory scope. A single-source result instead describes no match to that advisory's reported ranges. Neither is a universal upgrade recommendation or verified build patch.
Patch / backport status unknown	The available evidence does not establish whether the selected build includes a patch. A higher build number alone is not proof of a fix.

Identity and data sources

Term	Definition
PURL	A package URL identifying a package in an ecosystem. Basilisk uses mapped upstream PURLs to connect conda-forge packages to OSV records.
CPE	A product identifier used by NVD. It can include version, hardware, and software conditions.
Upstream ecosystem	The ecosystem of a mapped package identity, such as PyPI or npm. The explorer still lists conda-forge releases.
Primary-PURL coverage	The proportion of indexed packages with a primary PURL mapping. It does not measure completed vulnerability checks; other identities, including CPEs, may also support matching.
Automatic identity	A package-to-project mapping created automatically. It is not evidence of manual verification.
OSV	osv.dev, a vulnerability database and schema for open-source packages. Basilisk ingests selected OSV ecosystems.
NVD	The U.S. National Vulnerability Database at nvd.nist.gov. Basilisk uses its CVE metadata and CPE configurations.
Anchore enrichment	Attributed replacement data for NVD applicability rules. NVD remains the advisory source, and the evidence records the enrichment revision.

See How matching works for the evaluation rules, Advisory grouping for aliases and source records, and Using the API for structured scope and coverage results.