Review rules the catalog enforces

Admissibility of indicators

The catalog splits its entries into three kinds — applications, components, and services — because they are found in different ways. An application is a program a person installs; a component is a library or model that ships inside other software; a service is a remote endpoint someone calls over the network.

An indicator only enters the catalog when it fits the kind of thing it points at. A running-process signal fits an application or a component that runs locally; a network-endpoint signal fits a service; a file-content signal fits something you can inspect on disk. A URL pattern cannot be an application indicator, and an installed-program name cannot be a service indicator — those cases would say more about the observer than about the target.

The per-kind admissibility rules keep the catalog honest: a match on the wrong category is a coincidence, not evidence.

How reliability is graded

Reliability is the confidence that a single match implies the target is present. It is not about how the indicator was discovered or how many blogs mention it — it is about how uniquely the value itself names the target and how hard it is to fake.

A host like `api.anthropic.com`, a bundle id like `com.anthropic.claude`, a distinctive symbol table, and a model-file magic number are examples of high-reliability values: they either name the vendor directly or point at something specific to their code. A vendor token in a broader string — a process name a program can rename freely, a reverse-DNS host without a known vendor part — is medium. A generic word, a name fragment, or a listening port with no vendor context is low reliability on its own, and only becomes useful when combined with something more specific.

A `known false positives` list on each indicator makes the trade-off explicit: it names the programs and contexts that also match the same value.

Known false positives

Every catalog indicator carries a list of programs and contexts that match the same signal but are not the target. The list can be empty, but the field is required — silence means "the reviewer thought about it", not "the reviewer skipped it".

The list matters for two reasons. It tells a downstream scanner where to expect noise, so a Tier-1 match on a common name does not get treated as strongly as a match on a distinctive one. It also tells a contributor which evidence needs corroborating with something more specific before the catalog can promote it.

The list is inspected at review time, but it is not the last word: consumers who see the signal misfire in the real world can report it via the reliability feedback loop, and repeated reports demote the indicator on the next release.

Uniqueness argument

For every indicator, the catalog records a short prose argument for why the observation points at its target — not just what the value is, but why the value is more consistent with one vendor than with any other. The argument may be a per-category template ("a bundle id in reverse-DNS form owned by the vendor namespace"); it does not have to be bespoke to be useful.

What the argument is for is not gatekeeping. It is a citation for the review-time reasoning that survives after publication: a consumer who wants to check why the catalog claims a signal identifies vendor X can read the argument on that indicator instead of asking the reviewer.

A fabricated or copy-pasted argument that does not fit the value is a reason to demote the indicator when a reader flags it via the feedback loop.

Detection tier

Each indicator belongs to one of three scan-cost tiers. Tier 1 covers names and paths — the name of a process, an installed program, a package, a file path. These are cheap to check against the system: a single string compare. Individually they are a suspicion, not a confirmation.

Tier 2 covers the running system — a running process, a listening socket, traffic to a host. Observing them requires that the machine be scanned while it runs, which is more expensive, and a match is a strong signal when seen.

Tier 3 covers file content — a file hash, a symbol table in a binary, the magic bytes of a model file. Reading and parsing the file is expensive, and a match is the most conclusive kind of signal: this 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. A scanner processes indicators cheapest first and escalates only where a cheap hit is worth the effort.

Mappings

An application is rarely identified by one indicator alone. The catalog stores a mapping for each application — a set of directed edges from the application to the components and services it relies on. Each edge is a bare, one-directional relation: it records that the application uses that component or service, and nothing more.

An edge carries no weight and no threshold. The catalog states that a relation exists and its direction; it says nothing about how strongly a single match argues for the application. How a scanner combines the edges it observes into an application-level decision — any weighting, any threshold — is the scanner's own policy, because a calibrated threshold needs ground truth the catalog does not have.

So a mapping records which parts an application is built from and leaves the combining to the consumer. It is deliberately not a rule of the form "if you see this, then it is that".

Category discipline per entry kind

The indicator categories are not interchangeable between entry kinds. A URL pattern belongs to a service (services are the things called over the network), a browser-history pattern belongs to an application (only applications leave that kind of trace on a user's machine), and a filesystem artefact belongs to whatever runs on disk — a component or an application, never a hosted service.

The per-kind restrictions look pedantic and they save real time. Without them, the same value would end up on the wrong kind of entry and consumers would trust matches that mean less than the entry claims. With them, a Tier-3 model-file signature is always on a component (a scanner can look for it in files on disk) and a network-endpoint indicator is always on a service (a scanner can watch for it in outbound traffic).

The review-time check is mechanical: is the indicator category admissible for this entry kind, per the per-domain matrix in the constitution?

Release lifecycle: promotion and demotion

Every submission that lands with outcome `accepted` writes a corresponding row into the promotion table on the same code path. The release publisher reads from that table at bundle-build time and ships every promoted signature that has not been demoted.

Demotion works the other direction. Consumers who see a signature misfire in the real world can report it via the feedback endpoint. When a signature accumulates enough reports over a rolling window — the default is five reports in thirty days — the reliability cron records the demotion and the next bundle build excludes the entry.

The two together mean the catalog's quality is measured post-publication by the report rate the real world produces, not by reviewer effort at publish time. A signature that never generates a report keeps shipping; a signature that generates many disappears from the next release.