How your contribution reaches the catalog

What the harvester and the intake server do, and what happens to what you send. About five minutes.

Two ways in

There are two ways to contribute to this catalog, and they differ in who does the work.

You suggest a program. You name what is missing, and our machines do the searching later. The suggestion form is here.
You run the harvester yourself. Then your machine does the searching, and it does it now.

Both paths end in the same place, namely a submission to the intake server. The rest of this page describes what happens there.

The harvester: where evidence comes from

The harvester is a command-line program that you download and run yourself. Given a program to look into, it gathers what can be observed about it, that is names, packages, hosts, and files, turns those observations into indicators, and sends the result to the intake server.

It runs on your machine and not on ours, and it only reads: it does not change your system. The computing work of a contribution happens here, which is why every contributor is also the one who pays for it in time and electricity.

There are two ways to use it. One takes open work items from our queue and processes whatever currently needs doing; the other looks into one specific program straight away, without waiting for the queue.

The intake server: where submissions land

The intake server manages every contribution that is sent in, and decides how it is processed and whether it is published. The project operates it.

Anyone who wants to contribute evidence of AI software with the traicer harvester uploads their own findings there — and improves entries that already exist the same way, by having the tool look into them again.

It checks essentially three things: that the format is right, that the submission is not a duplicate of something already recorded, and that the information an entry needs is actually present.

So the intake server takes suggestions in, hands them out to individual harvesters as work items, takes their results back, and publishes what qualifies in the next version of the catalog. Accepted submissions become part of the community catalog you are browsing here.

One suggestion, end to end

It helps to follow one suggestion all the way through:

You send a suggestion, and a maintainer reads it.
If it is accepted, it becomes a work item, and the next harvester that asks for work can pick it up.
That harvester looks into the program, extracts indicators from what it finds, and submits the result.
The intake server checks the submission. An unknown target becomes a new entry, while a known target keeps its entry and gains the indicators it did not have yet.
An accepted entry is marked as ready for release.
We build and sign the next release bundle, and scanners pick it up from there.

If you run the harvester yourself, the first two steps simply fall away, because you produce the submission directly.

Where it can stop

The path can end at any of these steps, and it often does. That is normal, so it is worth knowing where:

A maintainer decides that a suggestion is out of scope for this catalog.
The search finds nothing solid enough to be worth submitting.
The target is already covered and the submission adds no observation that is new, so we record it as a duplicate. If it does bring something new, that part is added to the existing entry instead.
The quality check before publication holds an entry back, for example because supporting sources are missing or because it did not pass the schema check. We mark entries in that state in this browser, together with the reason.
Enough people report an entry as unreliable, and it drops out of later releases.

None of this is a judgement about the program itself. It is always a judgement about the evidence.

What actually ships

A release bundle contains only those entries that were accepted, marked for release, and not dropped again since. That signed bundle is what a scanner actually reads.

Everything else stays visible here in the community browser without being part of a release, which is why an entry you can see here is not automatically an entry a scanner knows. How the catalog is built describes what a bundle contains and how to check one before trusting it.

Try it

Look into one program and submit what is found:

harvester quick "<name>" --domain application

Commands use the project intake by default; add --intake-url <url> to target a different one. `harvester help contributing` walks through the five-minute path, and `harvester doctor` checks your setup before you spend a run finding out.