traicer-harvester

An open, structured signature catalog that lets any tool detect which AI programs are running or installed on a machine — even when the vendor doesn't declare it.

I want to… help in 5 minutes · use the catalog · run the harvester · decide whether to trust this

---

What is this?

Organisations and individuals increasingly need to know what AI software is present on their machines — for inventory, for policy, for their own peace of mind. Vendors don't always tell you. traicer-harvester builds and publishes a catalog of detection signatures: concrete, verifiable observations (a process name, an API endpoint, a model file's magic bytes) that a scanner can match against a host to answer "which AI programs are here?" — independent of vendor disclosure.

The catalog is the project's only deliverable. Scanning is done by downstream consumers (such as traicer-cli, a separate project) — or by any tool you build on top of the published data.

Signatures come in three tiers, ordered by scan cost and confidence:

Tier	What it matches	Cost	Confidence per match
1 — Surface	Installed-program names, package manifests, file paths	Cheap (string compare)	Low–medium: a candidate, not a confirmation
2 — Runtime	Network endpoints, daemon sockets, processes, env vars	Moderate (live observation)	High: api.anthropic.com traffic is hard to fake
3 — Content	Binary fingerprints, library symbols, model-file magic bytes	Costly (file parse)	Highest: catches AI use the vendor never declared

The catalog produces facts, not judgements. It never says whether running a program is good or bad, compliant or non-compliant — that evaluation belongs to the tools and people consuming the data.

---

Why your contribution matters

The catalog's value scales with breadth of coverage, and breadth scales with contributors. Pick your effort level:

• 5 minutes — report or run. Saw a catalog entry fire incorrectly? File a false-positive report — entries crossing the report threshold are automatically demoted from the next release. Or donate compute: install the binary, harvester doctor, harvester run — done (quick start).
• Half an hour — add a signature. Author a catalog entry with full provenance and open a PR (or use the no-tooling proposal form) — quick start.
• Ongoing — investigate mappings. Applications are detected by weighted combinations of component and service signatures; investigating and refining those mappings is its own work-unit type, open to anyone (CONTRIBUTING.md, Channel 3). Sustained contributors grow into triage and maintainer roles (MAINTAINERS.md).

Two properties keep the catalog honest:

• Per-entry provenance. Every indicator records how it was discovered, its source URL, and when it was last confirmed. No anonymous facts.
• A consumer feedback loop. Consumers report entries that fire incorrectly; entries crossing the report threshold are automatically demoted and excluded from the next release. Your report directly changes the next published catalog.

---

Quick starts

Consume the catalog

# Fetch the latest signed release bundle:
#   https://codeberg.org/traicer/traicer-harvester/releases
# Verify sha256 + ed25519 signatures before loading:
#   docs/releases/verify-downloads.md

Bundle layout, schema, and the full verification contract: docs/releases/README.md and docs/releases/catalog-database-structure.md.

Donate compute (Worker mode)

# Download the binary for your OS from the latest release, then:
./harvester doctor                       # checks your setup end-to-end
./harvester run    # connects to the project intake (https://intake.traicer.app) by default

The Worker pulls work from the central queue, processes it (a local Ollama model helps — see harvester run --help), and submits results. Ctrl-C any time; in-flight work is re-queued after the lease expires.

First-run setup

Installed the harvester via a package manager (brew, apt, dnf, .msi) and want to contribute? Run the interactive walkthrough once:

harvester setup

It detects any LLM API keys in your environment, asks which driver profile to use, confirms the intake URL, captures a submitter pseudonym, and writes harvester.toml under your per-user config dir ($XDG_CONFIG_HOME/traicer/ on Linux/macOS, %LOCALAPPDATA%\traicer\ on Windows). From then on harvester run / harvester quick read that file (flags and env vars still override it). Verify with harvester doctor.

Submit a signature

Hand-authored entries live in the curated corpora under seeds/curated/ — full catalog-entry JSON with the five required indicator fields (tier, reliability, known false positives, uniqueness argument, provenance). Add or correct an entry there and open a PR; every entry is machine-validated at ingestion by the same schema validator the release publisher applies, and a maintainer reviews the PR (.codeowners guards seeds/ and data/).

No tooling, no clone? Use the signature proposal form — it collects exactly the required fields. Evidence requirements and the full workflow: CONTRIBUTING.md.

---

Architecture

Two Go binaries built from one repository:

 contributors                         project-operated
┌──────────────┐   fetch work        ┌───────────────┐
│  harvester   │◄────────────────────│ intake-server │
│  (CLI, your  │────────────────────►│  (queues,     │
│   machine)   │   submit findings   │   review,     │
└──────────────┘                     │   publish)    │
       │                             └───────┬───────┘
       │ local / quick modes                 │ signed releases
       ▼                                     ▼
  local output                    catalog artifacts (JSON bundles,
                                  sha256 + ed25519 sidecars, pubkey)

• harvester — single statically-linked binary for contributors. Worker mode (run), targeted one-shot (quick), and a fully offline local pipeline (local).
• intake-server — project-operated service holding the work queues, accepting submissions, and publishing releases. Not end-user-facing.
• Releases — every catalog release ships JSON artifacts with sha256 sidecars and ed25519 signatures; the public key is pinned and committed in-repo. See docs/releases/verify-downloads.md.

---

Trust

• SECURITY.md — reporting vulnerabilities, disclosure policy
• TRANSPARENCY.md — how AI is used to build this project, and what gates apply
• CODE_OF_CONDUCT.md — community standards
• MAINTAINERS.md — who maintains this, how decisions are made
• docs/releases/verify-downloads.md — verify every download before trusting it

---

Documentation

docs/README.md is the audience-routed index — start there whether you consume the catalog, contribute signatures, operate an intake server, or maintain the project. Project rules live in the constitution; development workflow in CONTRIBUTING.md.

Frontend contributors working on the signature-browser UI: your one-page kickoff is HANDOFF-FRONTEND.md. It scopes your safe space (the internal/signaturebrowser/web/ folder, no Go needed), lists the four commands to run it locally, and hands your AI agent its operating contract.

---

License

• Code is licensed under Apache-2.0 — see LICENSE.
• Catalog data (signature source files and release artifacts) is licensed under CC BY 4.0 — see LICENSE-data.

---

Canonical repository

The canonical repository lives on Codeberg. The GitHub copy is a read-only mirror: Issues and Pull Requests are disabled there — file everything at the Codeberg repository.