Skip to content

Privacy and Data Rights

shashank-sn edited this page Aug 4, 2026 · 2 revisions

Privacy and Data Rights

Local-first runtime promise

The core runtime does not use an account, API, MCP server, telemetry, payment collection, or network request. Your writing samples, profile, draft, candidate, and reports stay in the files and terminal environment you control unless you independently send them somewhere else.

The project cannot extend that promise to tools you choose outside it. If you paste a generated brief or draft into another model, editor, cloud drive, issue tracker, or chat system, that service’s terms and privacy controls apply.

Treat inputs as sensitive

Profiles are derived from private writing samples. Although a profile is aggregated JSON rather than a copy of the samples, it can expose recurring vocabulary, stylistic preferences, or forbidden phrases. Treat the following as potentially sensitive:

  • Source samples and drafts.
  • Generated profiles and avoid lists.
  • Candidate rewrites and diffs.
  • Client feedback, annotations, edit histories, embeddings, and benchmark corpora.

Keep them out of the public repository unless every contributor and rights holder has explicitly cleared publication.

Contribution boundary

The public codebase may contain generic, reproducible examples and documentation. It must not contain client or user text, private profiles, copied corpus data, credentials, access tokens, secret configuration, or data with uncertain provenance.

Before contributing a fixture, ask: “Could a reasonable reader identify a client, a private author, or a source that did not grant public reuse?” If yes—or if you cannot answer—do not submit it. Replace it with a synthetic, generic fixture that tests the same behavior.

Benchmark boundary

A benchmark must state the source rights, preparation method, model/editor settings, scoring rubric, dates, sample selection, and limitations. Historical product findings belong in clearly labeled documentation, not in code comments or marketing claims presented as universal results. See Benchmarks and Research.

Security practices for maintainers

  1. Keep private examples outside the repository and add local ignore rules.
  2. Review every diff for accidental sample text, email addresses, IDs, credentials, or embedded exports.
  3. Use reproducible tests based on synthetic text.
  4. Do not weaken release checks to publish a change faster.
  5. Disclose a security issue privately through the repository’s reporting route rather than posting exploitable detail in a public issue.

MIT licensing grants broad rights to the code. It does not grant rights to third-party text or data accidentally committed beside it.

Clone this wiki locally