How the catalog is built
The data model behind this browser, and how a scanner is meant to use it. About five minutes.
What the catalog is
The catalog is a published list of observations by which AI software on a computer can be recognised. It is data, and not a scanner.
We produce this list. A separate tool, the scanner, reads it and looks for those observations on an actual machine. We keep the two apart on purpose: the catalog knows nothing about your computer, and the scanner carries no knowledge of its own about individual programs. That way the knowledge can be reviewed, corrected, and published independently of any tool that uses it.
Every release therefore consists of signed files that you can download and check before you trust them.
Entries: the things being described
An entry is one named thing the catalog knows about, and it is always one of three kinds:
- An application is typically a program someone installs and starts, such as a desktop assistant or an editor with AI features.
- A component ships inside other software: a library, a runtime, an SDK, a model file.
- A service is operated by a vendor and called over the network, for example a hosted model API.
We identify an entry by the combination of these three things: its kind, its vendor, and its name. Alongside that it carries a description, the versions it has been recorded in, and a note of where its information came from.
The distinction matters because the three are found in different ways, which the next sections describe.
Indicators: the checkable observations
Evidence and indicators are two words for the same thing; this browser shows them in the "Indicators" section of a signature's own page, not on a page of their own.
An indicator is a single observation that argues a target is present. Every indicator has a category, and that category decides what is compared and what the value looks like: a running process, an installed program, a file on disk, a network host, a web address, a package dependency, a pattern in the browser history, the signature of a model file, the binary of an inference runtime, an import of an accelerator API, or a binary pattern rule.
Besides the value itself, we record for every indicator which tier it belongs to, how reliable a single match is, which programs are known to match without being the target, a short argument for why it points at this target, and how, where, and when it was found.
The categories are not interchangeable between entry kinds: a web address belongs to a service, a pattern in the browser history to an application. Some entries cite the review rules behind these limits by a code, and the review-rule reference explains what each one means.
Tiers: what a check costs
We sort indicators into three tiers. A tier says what a check costs, not how good it is, and a scanner works through them from the cheapest to the most expensive.
- Tier 1 covers names and paths: the name of an installed program, a package, a file path. This is a string comparison, so it is broad and cheap. On its own such a match is a suspicion and not an answer.
- Tier 2 covers the running system: a process, a listening socket, traffic to a host. This requires observing the machine while it runs, and it is a strong signal when it is seen.
- Tier 3 covers file contents: a file hash, a symbol table, the magic bytes of a model file. This is expensive, often gigabytes to read, and the most conclusive. It is the tier that recognises AI use a vendor never declared.
An indicator that touches several tiers is filed under the highest one it needs.
Reliability: how much one match is worth
Reliability answers a single question: if this one observation matches, how confident can we be that the target is really there?
We derive it from how specific the value is, that is, how uniquely it names the vendor and how hard it would be to fake. We deliberately do not derive it from how the indicator was discovered or from how many articles mention it, because neither says anything about the value itself.
- high means the value names the vendor, or an artefact backs it up: a file hash, a vendor's own API host, an identifier the vendor controls such as a reverse-DNS bundle id or an @vendor package scope, a distinctive symbol table, or the magic bytes of a model file.
- medium means the vendor's name appears in a value that a program can choose for itself, such as a process or package name.
- low means a generic term, a fragment of a name, or a bare port or socket. A port carries no vendor identity, because anything on the machine can bind it.
A low indicator is therefore not a bad indicator. It only becomes meaningful in combination, which is what the next section is about.
Mappings: recognising an application
Indicators of components and services stand on their own. Applications do not, because an application is usually made up of exactly those parts.
We therefore recognise an application through a mapping: a set of directed edges from the application to the components and services it relies on. Each edge is a bare relation — it records that the application uses that part, and carries no weight and no threshold.
How a scanner combines the edges it observes into an application-level decision is the scanner's own policy: the catalog publishes the relations, not a rule for adding them up, because a calibrated threshold needs ground truth the catalog does not have.
This is the only mechanism the catalog offers for recognising an application, and it is deliberately not a list of the form "if you see this, then it is that".
How the pieces fit together
Every entry has at least one indicator, because an entry without indicators is just a name.
An indicator can belong to several entries at once, since the same host or the same package can be evidence for more than one target. When a new submission brings an indicator that an entry does not have yet, we add it to that entry instead of dropping it; only an identical repeat of a value we already hold counts as a duplicate. That is how an entry grows over time as different people investigate the same program in different ways.
A mapping, finally, points from one application to the components and services it relies on, as bare directed edges that carry no weight and no threshold.
Every entry has one or more indicators. One indicator can belong to several entries.
A mapping identifies one application by directed edges to the components and services it relies on.
How a scanner uses all this
A scanner works in four steps.
- It fetches a release. We publish the bundles on the project's release page, opens in a new tab. Each one contains the catalog, its companion files, a checksum and a signature per file, and the public signing key.
- It verifies before it trusts. First the checksums, then every signature against the published key. The key itself should be pinned by the hash of the key file as it is delivered, and not by the hash of the key material inside it. This is the step consumers most often get wrong.
- It matches from cheap to expensive. Tier 1 is evaluated across the machine, and only where a cheap hit makes the effort worthwhile does the scanner escalate to Tier 2 and Tier 3. Each indicator carries a reliability the scanner can weigh as it sees fit.
- It combines the results for applications. The catalog gives it the directed edges of each mapping; how to turn the edges it observed into a detection — any weighting, any threshold — is the scanner's own policy, because a calibrated threshold needs ground truth the catalog does not have.
What a scanner reports is therefore a sign of presence and not a verdict. We record what can be observed, and say nothing about whether using a program is a good idea.