The public corpus (contribute)

What the corpus is

The corpus is the open library of facts that tells Anomalous what a process actually is. When a diagnosis card says "dasd is Apple's background-activity scheduler," that sentence comes from the corpus — not from a language model guessing. Small on-device models confidently invent identities for processes they don't recognize, so Anomalous refuses to speak about a process unless the corpus knows it. That keeps the app honest: a real answer or an explicit "unknown," never a fabrication.

It is public open data. The corpus lives in its own GitHub repository, licensed Apache-2.0, as one JSON file per process. Because it is plain, diffable data, anyone can read it, correct a wrong entry, or add a missing one through a pull request. The same reasoning that open-sourced the Anomalous sensor applies here: the facts that ground every card should be inspectable and correctable by the people who actually know these processes.

How entries are shaped

Each entry answers the same handful of questions about one process: what it is, who ships it, what it means when it runs hot, and how safe it is to intervene. The safety guidance is deliberately conservative — a wrong "safe to kill" can cost someone data, so anything unproven stays at the most cautious tier.

Here is the shipped macOS entry for dasd, which is a good template for what a complete entry looks like:

{
  "process_name": "dasd",
  "display_name": "Duet Activity Scheduler",
  "what_it_is": "Apple's background-activity scheduler...",
  "owned_by": "Apple (system daemon, launchd-managed)",
  "when_hot_implies": "Almost always a wedged scheduling loop...",
  "safety_tier": 1,
  "safe_action": "kill — launchd respawns it fresh within seconds, reclaiming the leaked memory immediately",
  "worst_case": "A deferred background task (backup, update check) runs later than it otherwise would.",
  "causally_linked": ["appstoreagent", "backupd", "BiomeAgent"],
  "sources": [],
  "platform": "macos",
  "corrected_by": null
}

Browse the data

The whole corpus is browsable on GitHub as ordinary JSON files. Open the corpus repository, look under entries/macos/, and read any process you're curious about. Every claim in an entry is meant to be traceable to its cited sources, so you can check the reasoning, not just the conclusion.

Two other directories are worth knowing. needs-review/ holds processes the fleet flagged but the automated engine couldn't fully verify — real gaps waiting for someone to research and fix. And README.md, CONTRIBUTING.md, and SCHEMA.md at the root explain the project, the contribution flow, and the field-by-field schema.

The corpus repository may still be private today while the project stabilizes. The URL is wired into the docs and tooling, and pull requests are welcome the moment you can reach it.

Send a pull request

Contributing is a normal GitHub pull request. Fork the repo, add or edit one JSON file, and open a PR describing what was wrong and how your sources support the change. The best contributions are small and specific: fix one field of one entry, and explain why.

1. Fork the corpus repo and edit or add entries/{platform}/{process_name}.json.
2. Include at least one http(s) source a reviewer can read — vendor docs, engineering blog posts, bug trackers, or reputable technical write-ups. "I saw this on my machine" makes a great PR description but is not a source on its own.
3. Be conservative on safety_tier: move toward 1 (safe to kill) only with evidence about how the process is supervised and respawned. Keep worst_case honest — never "nothing bad happens."
4. Set corrected_by to your attribution (for example github:yourhandle/pr-42) if you want credit carried into the published feed.

The highest-value starting point is an existing gap. Pick a file under needs-review/{platform}/, read its why_unverified note — that is exactly what needs fixing — write a correct, cited entry, and delete the needs-review/ file in the same PR.

How contributions are reviewed

Every contribution passes through a human. A curator checks out your pull request and imports it with the corpus:import command into the same review queue the automated research engine feeds. Import validates the schema hard — field types and lengths, plain-text-only fields, http(s)-only sources, at least one source, no unknown fields — and then a person reads the entry against its citations before anything ships.

If approved, the entry publishes into the signed feed tagged source: "community" with your attribution, and reaches every Anomalous client on its next refresh. If rejected, the PR gets a comment explaining why so you can tighten the sources and try again. Correcting an already-published entry temporarily unpublishes it while the replacement is under review; reviews are kept fast so that window stays small.

Your PR is one of two doors into that queue, which produces three trust tiers:

• community — a pull request, after a human curator approves it.
• reviewed — the discovery engine (or an original seed), after a human approves it.
• anomalous — the discovery engine, auto-published after an independent verifier model confirmed the draft against its own citations. Cards from this tier read "Sourced by Anomalous."

An entry you think is wrong — including an automatically published anomalous one — is correctable exactly like any other: open a PR with sources, and a human review supersedes the automated one.