Privacy policy.

DocParity reads the parts of a pull request needed to work out which documentation a change invalidates, and stores the resulting findings. It does not store your source code. If that is still more than your policy allows, DocParity can be self-hosted, and it runs without any LLM provider at all.

When the GitHub App analyses a pull request, it reads:

• Paths of the files the pull request changed
• The diff hunks of those files
• The text of documentation files that the deterministic rules flagged as affected
• Pull request metadata: number, title, branch name, the merging account, and the commenter's relationship to the repository
• Repository configuration from .docparity.yml and doc-mapping.yaml

• Findings - the changed file path, which documents were affected, why, a confidence score, the outcome, who approved the merge, and when
• Learning data - which code and documentation paths change together, which mappings a team accepts, and wording preferences observed in documentation edits
• Document vectors - numeric embeddings of documentation files, keyed by a content hash, used for semantic ranking
• A short-lived document cache - the text of documentation files, keyed by the git blob hash so an unchanged file is not fetched again. It expires after 30 days and holds documentation only, never source code
• Usage - a record that a given pull request was analysed in a given month, for plan metering
• Account data - your GitHub login and the list of repositories your account can access, so the dashboard shows you only your own

• Your repository's source code at rest
• Files that no rule pointed at
• Credentials, tokens, or environment variable values

Environment variable names are read to check whether they are documented. Their values are never read or stored.

• GitHub - the source of the data and where results are written back
• The configured LLM provider - receives the diff summary and the text of flagged documents, only to draft a replacement. Leave the API key unset and no document text is sent anywhere; the deterministic engine still detects drift.
  Before that prompt is built, credential-shaped values are found and replaced: provider keys by the shapes those providers publish, private key blocks whole, passwords inside connection strings, and any value assigned to a name like CLIENT_SECRET. The variable name survives - it is what the documentation is about - and the value does not. How many were removed, and of what kind, is written to our log; the values themselves are not written anywhere. No detector finds everything, so this is a control rather than a promise.
• The configured embeddings provider - receives documentation text to produce vectors for semantic ranking
• Infrastructure providers - hosting, database, and error monitoring, where enabled

We do not sell data, and we do not use your code to train models.

Findings and learning data persist so scores, trends, and audit exports remain meaningful over time. Uninstalling the GitHub App stops all processing immediately. To have stored data deleted, contact us at the address below and we will remove the records for your repositories.

Finding drift means reading code. If sending yours to us is more than your policy allows, a private runner is the same engine run inside your network, holding your own git credentials. It asks us for work, does the reading there, and sends back file paths, document paths, reasons, confidences and scores. Nothing it sends has a field that would carry file content.

From the moment your account enrols a runner, this deployment refuses to read your repositories at all - not as a preference, but as a check made before any request is opened. If your runner is offline the work waits; it is never quietly analysed here instead.

The enrolment token is stored as a keyed hash. It is shown once, no endpoint returns it, and no support process can recover it - losing it means issuing another.

Drafting is the only call that leaves this system. You can supply your own model provider key, in which case the request is made against your account: the data agreement that applies to it is the one you signed, and the usage appears on your bill.

The key is stored encrypted rather than hashed, because it has to be used. That protects it from a dumped table or a leaked backup, and not from anyone who already has this application's environment - we would rather say so than imply more. It is never shown again, only its last four characters. A deployment that cannot encrypt it does not store it at all.

DocParity can run entirely on infrastructure you control, in which case none of the above involves us at all - the data stays in your network, and you choose whether an LLM provider is involved.