These documentation pages were drafted with AI assistance. They will sometimes be wrong. Verify before following any instruction that affects your data, your install, or your security.
We’re publishing this disclaimer prominently — on every page via the banner, and again here in long form — because we think it’s the honest thing to do. Almost all the prose, structure, and examples on this site were generated by an AI tool from notes, the source code, and prior wiki content. A human maintainer reviewed each page before publishing, but neither the AI nor the maintainer is infallible.

​
What’s AI-generated

  • Page structure and prose (intro, quickstart, configuration, troubleshooting, security, hardening, FAQ, glossary, cookbook, alternatives, every page in the Develop tab, the OpenAPI spec)
  • Most code examples (curl invocations, sample configs, the npm commands)
  • The Mermaid diagrams in develop/architecture.mdx and develop/tauri.mdx

​
What’s verified by a human

  • The site is reviewed end-to-end by a maintainer before each push.
  • Cross-references between pages are validated automatically by npm run check on every PR.
  • Internal and external links are checked weekly by lychee.
  • Code examples are read for plausibility but not always executed — that’s where you should be most cautious.

​
What to double-check before following instructions

A non-exhaustive list of categories where AI-drafted docs go wrong most often:
  • Exact command flags. A flag like --quality 80-95 may be a real pngquant flag (it is) or a hallucination (it isn’t, in most cases). When in doubt, run the command’s --help first.
  • File paths and line numbers. Cross-references to lib/scraper.ts → fetchAndParseApp may be off by one refactor cycle. Check the actual source.
  • Version numbers. The docs say Node 24 LTS pinned in engines.node. If you see a different version in the actual package.json, trust package.json.
  • API request/response shapes. The OpenAPI spec covers ~86 operations; some examples are inferred from CLAUDE.md rather than from the running code. The actual response shape lives in the route handler in app/api/*/route.ts.
  • Threat-model claims. The Security and Hardening pages describe the protections privacytracker has. Before exposing your install on a network, verify the protections are actually in place — the smoke check verifies docs structure, not application security.
  • Step counts and timings. Migrations run in 5 ordered steps, boot resume probes fire at 8s/10s/12s — these reflect the codebase at one moment. Both move with releases.
  • External links. URLs to GitHub Releases, archive.org, third-party tools, the Plane board, etc. all point at things that may have moved or changed shape.

​
Authoritative sources

When the docs and the underlying source disagree, the source wins. In rough order of authority:
  1. The running code in privacykey/privacytracker. lib/, app/api/, instrumentation.ts, next.config.js.
  2. CLAUDE.md at the repo root. Coding-agent instructions; denser than these docs and updated more aggressively.
  3. CHANGELOG.md at the repo root. Auto-generated by the release pipeline.
  4. The Plane board. Long-form architectural and operational notes that used to live in the wiki — see the privacytracker Plane board.
  5. These docs. Useful starting point; treat them as a guided tour, not a contract.
If a doc page contradicts any of the above, the doc is wrong. Report it.

​
Why publish AI-drafted docs at all

A reasonable question. Three reasons:
  • Coverage. Hand-writing comprehensive docs for a project this size is slow. AI-drafting gets us 80% of the way to a complete site that wouldn’t otherwise exist.
  • Honesty about authorship beats hidden authorship. Many projects ship AI-drafted docs without saying so; we’d rather flag it.
  • A flagged-as-fallible doc is still useful. Some documentation that helps you orient, with a clear caveat, is better than no documentation at all — provided you treat it as orientation rather than law.
The alternative is the project’s wiki and source comments, which are denser and require more navigation. These docs aim to be the friendlier surface; they’re not the canonical surface.

​
How to report a documentation bug

Three options, in order of preference:
  1. Open an issue on the docs repo. github.com/privacykey/docs-privacytracker/issues — quote the page, the section, and what’s wrong. Bonus points for a one-line fix.
  2. Click the Suggest edits link in the page footer (Mintlify renders this when feedback is enabled). It opens a PR against the offending MDX file directly.
  3. Mention it in the Plane board. Useful for whole-page-is-misleading feedback that doesn’t fit a single PR.
Security-sensitive corrections (the docs claim something about the security posture that isn’t true) follow SECURITY.md — never a public issue.

​
Reading these docs with an AI assistant

This site follows the llms.txt convention, so you can hand it to whichever assistant you use and ask it to walk you through an install, a recipe, or an API call:
  • /llms.txt is an index of every page with its one-line summary.
  • /llms-full.txt is the whole site in one Markdown file, including a method-by-method table of the API — the thing to paste in when you want the assistant to have everything.
  • Appending .md to any page’s URL returns that page as plain Markdown, and /api-reference/openapi.yaml is the raw OpenAPI spec.
Both files are generated from these pages, so everything above about verifying before you act applies to them just as much. An assistant reading them inherits the same mistakes.

​
Where this lands in practice

  • The banner at the top of every page is dismissible. Dismissing it for your session doesn’t dismiss it for anyone else.
  • This page is reachable from the Help group in the sidebar.
  • Search indexes this page, so a search for AI, disclaimer, accuracy, or verify surfaces it.
  • The disclaimer is also linked from the docs repo’s README.md and CONTRIBUTING.md.
If this disclaimer makes you decide not to use these docs, the Plane board and the main repo’s source are both more authoritative. We’d rather you cross-check than trust blindly.