Privacy, storage, and deletion

What the service processes

Research runs can contain queries, user-supplied constraints, public URLs, titles, evidence excerpts, publication and retrieval dates, research results, run IDs, evidence snapshots, comparisons, and tool-usage records. Optional platform features can store notes, tags, folders, decision logs, feedback, watchlists, and validation outcomes.

The service also processes timestamps, request and error categories, provider-usage counts, and hashed owner or client identifiers used to scope runs, caches, quotas, and rate limits. Network information such as an IP address may be read to derive those identifiers; raw IP addresses are not intentionally written into research results. Operational logs include coarse event metadata such as tool, run, provider, duration, source count, and safe error category—not provider keys or full evidence excerpts.

Why it is processed

The data is used to perform requested research, validate and deduplicate evidence, preserve immutable run history, compare later runs, protect the public service from abuse, diagnose failures, and receive optional beta feedback. Feedback is kept separate from public market evidence and cannot change research records or system instructions.

Where it is processed and third parties

• Claude or Anthropic: Claude performs web research through the user’s existing Claude access and processes the conversation before sending a bounded evidence package. The Novelty Engine backend does not call Anthropic in supplied-source mode.
• Vercel: the public web application may run on Vercel and includes Vercel Analytics. Hosting, request, analytics, and operational data are subject to the deployment’s Vercel settings.
• Upstash or compatible Redis: optional durable storage can hold runs, platform records, rate-limit counters, and budgets.
• Brave or Tavily: optional hosted-search adapters receive search queries only when an operator configures and intentionally invokes provider-backed research. They are not called by the default supplied-source flow.
• GitHub: hosts code and public documentation. GitHub processes information only when someone follows a link or submits an issue.

Retention

• Research-result cache: 24 hours by default, configurable up to 7 days.
• Durable Redis run and evidence-snapshot history: 365 days by default and at most 365 days under the current code.
• Local-file run history: persists until the deployment operator removes it.
• Notes, tags, folders, decision logs, feedback, watchlists, validation outcomes, and other platform records: no automatic expiry is implemented; they persist until the operator removes them or the backing store is purged.
• Rate-limit and budget counters: expire on their hourly, daily, monthly, or concurrency windows.
• Hosting, analytics, backups, and operational logs: retention depends on the configured service plan and deployment settings and is not verifiable from this repository.

Optional information and what not to submit

Constraints, notes, feedback, watchlists, and validation outcomes are optional. Never submit private, confidential, personal, medical, financial, credential, trade-secret, customer, or proprietary information. Research sources should be public and excerpts should be limited to what is necessary for source integrity.

Cache reuse and public evidence

A matching result may be reused from the scoped cache for the same owner, query, and provider during the cache period. Public evidence can appear in another run if Claude or a configured provider retrieves it again, or if another user supplies it. The service does not treat one user’s private notes or feedback as market evidence.

Sale and model training

The Novelty Engine code does not sell personal information and does not submit stored research runs to its own model-training pipeline. Third-party services, including Claude, hosting, analytics, search, Redis, and GitHub, operate under their own terms and settings; this policy does not make claims about those providers’ independent training or retention practices.

Deletion requests and limits

There is deliberately no public “delete by run ID” endpoint because possession or guessing of a run ID is not sufficient authorization. Use the configured private contact above and include enough non-sensitive context for the operator to locate and verify the request. The operator may not be able to delete public source material, third-party logs, legally required records, already downloaded exports, de-identified aggregate metrics, or data in backups until those backups rotate. Deletion cannot be guaranteed until identity and scope are verified.

For non-private product questions only, use GitHub.