Privacy

What Fathohm reads, keeps, and never keeps

Fathohm measures comprehension debt: code no human has recently written, reviewed, or explained — measured from the record, not a survey. That record is git and pull-request metadata. This page says exactly what the hosted service at fathohm.dev reads from your GitHub organisation, what it stores, who else processes it, and how to have it deleted. The free command-line tool is covered at the end: it reads nothing from us and sends nothing to us.

Last changed 2026-09-06.

What the GitHub App can access

The App requests three permissions, all read-only: Contents, Metadata and Pull requests. It never writes to a repository, never opens a pull request, never runs your code, and asks for no write scope of any kind. You choose which repositories it can see when you install it, and you can narrow that list or uninstall at any time from your organisation’s GitHub settings.

What it reads

• Commit metadata. The commit id, the author and committer name and email as git recorded them, timestamps, the commit message and its trailers (this is how agent-written commits are recognised), and the paths and byte sizes of the files each commit changed.
• Pull-request and review metadata. Who opened, reviewed and approved what, and when; the state of each review; and the length of each review comment. The comment text itself is not stored — the schema holds a character count.
• The file tree. Paths and sizes, so the Map can size its cells and the code-or-not rule can leave out images, lockfiles, minified bundles and prose.

The two places file contents are read, and dropped

Source code is never stored. The database has no column for it, and a change that would add one is treated as a critical bug. There are exactly two moments when file contents are read at all, and both are transient:

• A module briefing you ask for. When a signed-in member requests a briefing on one file, that file’s contents are fetched from GitHub, sent once to the model provider to write the briefing, and discarded. What is kept is the briefing itself — a short description, entry points, dependencies, failure modes and three questions — never the source it was written from.
• Classifying an ambiguous commit. Most commits are labelled human or agent from their trailers and signatures alone. For the residue, the model is sent the commit message and the list of changed paths — not a diff, and not file contents.

What it stores

• Events. The commit and review metadata above, as an append-only record. Scores are recomputed from it, which is why it is kept rather than summarised.
• Scores, with their factors. Every score is stored beside the four factors it is made of, so the number can be taken apart on every screen that shows it.
• Identities. The author emails in your commits, mapped to GitHub accounts where GitHub itself makes the link, so one person’s commits count as one person. Members can correct a label; corrections are stored as events too.
• What your team decides. Accepted risks, ownership from your CODEOWNERS file, comprehension policies, briefings, and the weekly digests — the product is a record of decisions, and these are the decisions.
• Your account. Signing in with GitHub gives us your GitHub id, login, the email address on that account and its avatar URL, plus which of your organisations have Fathohm installed. Digest emails, where an organisation turns them on, go only to sign-in addresses — never to an address taken from a commit.
• The waitlist. If you join it: your email address and your answer to the one question on the form.

Who else processes it

The service runs on a small number of providers, each under its own terms. GitHub is the source of every event. Vercel hosts the website and provides its page analytics, which are cookieless and aggregate. Supabase holds the database and handles sign-in. Hetzner runs the workers that read your organisation’s events. Anthropic, sometimes reached through OpenRouter, writes briefings and classifies ambiguous commits from the inputs described above. Resend delivers digest emails and Slack receives digest messages, each only for an organisation that has switched that channel on. Nobody is sold or shown your data; the only public pages are the gallery of open-source repositories we chose to map, and no customer organisation appears there.

Cookies

Two kinds. The sign-in session cookies set by Supabase Auth, and one cookie of our own, fathohm_org, that remembers which organisation you last looked at. There are no advertising or cross-site tracking cookies, and the analytics set none.

Retention and deletion

Uninstalling the App stops every read immediately and marks your organisation inactive. The metadata already stored is kept, because a score history can only be recomputed from it, until you ask for it to go. Email hello@fathohm.dev from an address on the organisation and we delete the organisation’s events, scores, identities, decisions and briefings within thirty days, and confirm when it is done. The same address handles a request to see or export what is held about you.

The command-line tool

npx fathohm reads git metadata on your machine and writes its reading to your terminal. It opens no file in your source tree, makes no network request, and sends nothing to fathohm.dev or anywhere else. Its full source is in the published package and at github.com/fathohm/cli, and the support page lists every filesystem call it makes.

Questions

Write to hello@fathohm.dev. It is read by the person who wrote the service. How the score is computed, and what it cannot tell you, is on the methodology page.