Classification, access control, confidentiality, GDPR, and what the system actually does with your data.
Every entry gets a sensitivity level when it's saved: public, internal, confidential, restricted, HR-confidential, legal-privileged, or client-confidential. The system classifies content automatically when it ingests, using regex patterns that detect financial data, personnel matters, legal language, and client-specific content. The person who saves an entry can override the automatic classification.
At search time, results are filtered by the requester's clearance level. Someone in engineering searching for "compensation" won't see HR-confidential entries. Someone in the Norwegian office won't see entries tagged to the Swedish client team unless they have cross-client access. Enforcement is at retrieval, not at storage: you can save anything. The gate is at the door.
Wing-to-wing isolation means entries tagged to "project-thor" are invisible to anyone outside that wing. Tenant-level scoping via API keys means the legal department's key sees legal entries, the engineering key sees engineering entries. For the highest-stakes projects, you run a separate instance: it's a single binary, not a multi-tenant cloud service.
The ingestion pipeline has a PII detection layer that flags salary figures, personal identification numbers, health information, and personnel matters. When HR-sensitive content is detected, the entry is automatically tagged as HR-confidential — which excludes it from search results for anyone without HR clearance.
The system prevents accidents, not malice. Could someone deliberately save HR data with a lower sensitivity tag? Yes, but it would be in the audit log, the tag would be visible, and the content patterns would trigger a review flag. The design philosophy is transparent: patterns are visible regex rules in the source code, not a black-box classifier. Your compliance team can review every pattern in about 30 seconds.
Three layers: wing isolation (entries tagged to a project wing are invisible to other wings), client-level scoping (entries tagged with a client_id are filtered by the requester's client access), and instance isolation (for the most sensitive work, run a completely separate ThreadWeave instance on dedicated hardware with its own API keys and its own MemPalace data store).
There is no shared cloud layer. No cross-tenant leakage vector. The isolation is at the process level, not the configuration level.
ThreadWeave stores institutional knowledge produced during employment — the work product the company paid for — not personal data. GDPR Article 17 explicitly exempts data processed for archiving purposes. Organizational memory is archiving.
What ThreadWeave does not store: personnel files, salary data, health information, performance reviews. It reads work communication: email, chat, documents. If HR records are in your email system, that's an email governance problem, not a ThreadWeave problem.
ThreadWeave inherits the GDPR compliance posture of your existing systems. If content is deleted from Gmail or Exchange per a data subject request, the connector won't re-ingest it because the source is gone. Entries can be deleted by author email or by individual ID via the API. The audit log records every deletion.
The one thing we won't do: claim GPSR compliance out of the box. If your organization handles person-level references in knowledge graphs (entity extraction that resolves to individuals), that's a nuanced legal interpretation and should be reviewed by your legal team. We tell you exactly what's covered so you know what to examine.
You do. The classification rules are open source regex patterns in detector.py — about 360 lines of readable Python. Not a black-box model, not a vendor's proprietary policy. Your compliance team can review every pattern, remove ones that don't apply to your domain, and add your own.
If your organization handles defense contracts and "project-thor" should never appear in search results, you add a sensitivity pattern for it. If Norwegian employment law uses different trigger phrases from the default HR patterns, you tune them. If your engineers write "vi bestemte oss for" instead of "we decided," you add the Norwegian equivalents.
The thresholds are configurable: bump the save threshold from 0.35 to 0.50 for fewer false positives, or lower it to 0.25 to catch everything and triage later. The LLM detector can point at any OpenAI-compatible model — local, self-hosted, or cloud — or nothing at all.
This is the difference between a tool and a service. A SaaS product hands you a classification policy and says "trust us." ThreadWeave hands you the source code and says "review it, change it, audit it."
This is the right question. Here's precisely what happens to your data at each stage:
Stored (verbatim). The full text of every email, chat message, or document is stored exactly as received. No compression, no rewriting, no alteration. Original source metadata — sender, timestamp, thread ID, message ID — is preserved alongside the content. What your colleague wrote is what gets stored.
Inferred (metadata tags). The detection engine produces classification tags: content type (answer, decision, chat, question, reference), confidence score (0.0 to 1.0), sensitivity level (public through client-confidential), suggested scope (team, department, organization), and a suggested title. These are all metadata — labels attached to the original content. They come from visible, auditable regex patterns or an opt-in local LLM.
Summarized. Nothing. ThreadWeave does not summarize content. The "title" on an entry is either the email subject line provided by the connector, or the first sentence of the content auto-extracted by the detector. There is no AI-generated summary, no compression, no paraphrase, no "key points" extraction.
Generated by LLM. Only if you opt in, and even then, the LLM only produces a classification label — content type and confidence score. It never generates text, rewrites content, produces summaries, or creates new knowledge. An LLM hallucination cannot contaminate your organizational memory because the LLM only votes on whether to save something. The content stays exactly as it was written.
The system is tuned to favor saving over skipping. The save threshold is 0.35, not 0.70 — deliberately low, because a false positive (a newsletter sitting in your knowledge base) is a minor annoyance measured in kilobytes, while a false negative (knowledge walking out the door when someone retires) is potentially catastrophic. The asymmetry is intentional.
Nothing is lost — only classified. If the detector skips something it shouldn't have, the original email is still in your mail system. You can re-run the connector with a lower threshold, or manually save the entry via the API or CLI. The detector is a filter, not a shredder.
The two detection layers are complementary: the regex detector catches explicit patterns ("we decided," "the reason is," "you should use"), while the LLM detector catches softer content — the Go-Live strategy memo that contains no trigger phrases but clearly holds institutional knowledge. Run both, and they cover each other's gaps.
The source code is public. The detector patterns are in src/threadweave/detector.py. The confidentiality engine is in src/threadweave/confidentiality.py. The access enforcement is in src/threadweave/auth.py. The ingestion pipeline is in src/threadweave/api.py. Every classification decision, every sensitivity tag, every access control check — visible, auditable, and modifiable. No trust required.