From source to knowledge
Distillation turns source material into connected notes. Privacy checks sit on both sides of that model step, with different jobs at each point.
- Prepare locally. The app saves your source and extracts readable text on your computer.
- Check before AI. Local rules can hold a document with a high-severity identifier before any model reads it.
- Distill with your model. If allowed to proceed, document text and relevant graph context go to your configured provider.
- Screen before saving. Local rules check the generated notes and remove matched values configured for redaction before the notes enter your graph.
A check is not blanket anonymization. Content that passes preflight can still contain personal information. A write-time redaction protects the saved note; it cannot undo data already sent to a provider. Personal-content classification can also make a model call before distillation.
What happens when a document is held?
With the default settings, a high-severity match assigned to Redact or Block holds a document before distillation. The original stays on your computer while you decide. A rule set to Flag only records a finding and lets the document through; disabled rules and values you have allowed do not trigger that protection.
In Privacy > Sensitive content, you can sanitize a held document, ingest it as-is, or discard it. Sanitize stages a separate copy with matched identifiers replaced by readable placeholders such as [redacted: SSN]. You review the preview and approve the copy before distillation. The original is preserved unless you discard it.
Sanitize may use AI. The personal-content check can send source text to the configured provider to identify sensitive passages, including when the original hold came from a local rule. It can classify the original text, not just the redacted copy. If that text must never leave your computer, remove it yourself before import instead of using AI-assisted sanitization or releasing the original. Discard removes the held original and its staged extraction and sanitized copies.
What can text extraction actually see?
Checks run on the text the app can extract. The current document pipeline extracts PDF text locally. An image-only PDF is stopped with a request to run optical character recognition (OCR) locally first; it is not sent as page images to a model. Mixed PDFs can have pages without readable text, and extraction warnings identify that missing coverage.
Images, diagrams, unusual encodings, unsupported formats, and information lost in conversion are outside a text detector's view. Read the extraction warnings and inspect the source when that content matters. Document preflight also is not a universal filter on every prompt, repository read, or connected agent: those operations can send content under their own flow.
What the rules look for
Deterministic means the same text, rules, and settings produce the same result. No AI guesses whether a card number passes its checksum. The detector looks for a recognizable shape, then validates its structure or nearby wording where the rule supports it.
| Information | How it is detected | Default response |
|---|---|---|
| Social Security numbers and ITINs | Number patterns plus US structural rules; unseparated SSNs require nearby context | Hold at document preflight; redact from generated notes |
| Payment cards and bank details | Issuer ranges and Luhn for cards; mod-97 for IBANs; routing checksums or bank-account labels | Hold at document preflight; redact from generated notes |
| Secret keys and credentials | Private-key blocks, known vendor prefixes, token shapes, and contextual secret patterns | High-severity matches hold at preflight and redact on write; one-time codes and sign-in tokens redact on write |
| Street addresses | Recognized street-number and suffix patterns; nearby address wording strengthens confidence | Flag for review; no automatic removal |
| Personal details in prose | A separate vocabulary check can route text to an AI classifier | Hold or label according to your vault's purpose and the assessment |
| Names, email addresses, and phone numbers | Deliberately outside the deterministic detector's scope | Kept; not automatically flagged or removed |
- Social Security numbers and ITINs
- How it is detectedNumber patterns plus US structural rules; unseparated SSNs require nearby context
- Default responseHold at document preflight; redact from generated notes
- Payment cards and bank details
- How it is detectedIssuer ranges and Luhn for cards; mod-97 for IBANs; routing checksums or bank-account labels
- Default responseHold at document preflight; redact from generated notes
- Secret keys and credentials
- How it is detectedPrivate-key blocks, known vendor prefixes, token shapes, and contextual secret patterns
- Default responseHigh-severity matches hold at preflight and redact on write; one-time codes and sign-in tokens redact on write
- Street addresses
- How it is detectedRecognized street-number and suffix patterns; nearby address wording strengthens confidence
- Default responseFlag for review; no automatic removal
- Personal details in prose
- How it is detectedA separate vocabulary check can route text to an AI classifier
- Default responseHold or label according to your vault's purpose and the assessment
- Names, email addresses, and phone numbers
- How it is detectedDeliberately outside the deterministic detector's scope
- Default responseKept; not automatically flagged or removed
Phone numbers are not automatically stripped. Street addresses are flagged by default, not automatically removed. Contact details are often useful knowledge, and an address may be a public office. If you need those details excluded, remove them before import; for recognized street addresses, you can also change the rule to Redact. A write rule alone does not keep an address out of a model request.
The checksums and structural checks, explained
- Social Security numbers: validate the area, group, and serial structure, rejecting prohibited ranges, all-zero parts, repeated digits, and a common example value. SSNs do not have a checksum. ITINs use a separate check for their assigned group ranges. These checks do not query a government service or prove an identity.
- Payment cards: require both a recognized issuer prefix and length, and a valid Luhn mod-10 check digit. That reduces the chance of treating an ordinary order number as a card.
- International bank account numbers (IBANs): check the declared length for a supported country and the mod-97 remainder.
- United States bank routing numbers: use the ABA 3-7-1 weighted checksum plus nearby bank or routing wording. Bank account numbers have a separate context-based rule.
The detector also covers patterns for passport and driver's-license numbers, dates of birth, tax IDs, health identifiers, diagnosis codes, and personal compensation. Coverage and default actions vary by rule; this is not validation of every country's identifiers. The app's rule list shows each action. See the detector implementation and default policy for exact behavior. The repository is private during the closed beta and requires access.
How context, masking, and redaction work
Softer patterns such as a labeled account number require nearby wording rather than treating every digit run as sensitive. Context is limited to the match's own line and the line above it, within a bounded window. Known secret prefixes and private-key blocks have dedicated rules; generic secret assignments use an entropy check to reject obvious filler.
Before detection, long encoded blobs are blanked without changing text offsets, so embedded image data does not accidentally look like an identifier. Overlapping findings keep the strongest match. Separate rules flag prompt-injection wording and remove defined hidden characters from generated notes; these are additional signals, not a guarantee against malicious content.
Deterministic findings record a masked value and a salted hash instead of copying the full matched identifier into the report. Their surrounding snippets mask other detected values too. Those snippets can still contain unrecognized personal information, and this masking does not erase the original source, other local records, or provider copies.
At the write boundary, Redact replaces a matched value with a placeholder. Block refuses an agent write; the deterministic writer replaces the value because it cannot ask an agent to rephrase. Flag only saves the content and records a finding. These actions apply to recognized matches under your current policy, including its allowed values. See the write screening code.
What about sensitive information written in ordinary language?
A medical disclosure or a private relationship has no checksum. When the personal-content check is enabled, a local vocabulary scan can route document text to an AI classifier. Code then maps the assessment to Hold, Label, or Clear using the vault's purpose: shared work, private work, mixed personal and work, or a custom purpose.
This classification is model-based, can miss context, and can have limited coverage. A personal-content hold may happen after a model has read the text. Sanitization can remove the containing paragraph of a located passage so it does not leave the disclosure behind while deleting only the request for confidentiality. Review the preview and any coverage notice before approving it.
The on-demand deep privacy review also uses AI to examine graph text. The deterministic local audit makes no model request. None of these reviews certifies that the graph is safe to publish.
Your model, your decision
Cloud AI is enabled by default for a supported, configured destination. When you run AI features, questions, conversation context, source text, and graph content needed for the task can leave your computer. Your provider receives the request even though the app and vault are local.
An API key identifies your account with a model provider. Bring your own key and configure the destination in Settings > Models. Check Privacy > Your data to see the active provider and endpoint, or pause AI for this vault. Your API key selects the account used for requests; it does not automatically enable zero retention or opt you out of training.
Who receives the request, and can they retain it?
Anthropic direct requests use the configured Anthropic account. OpenRouter receives requests and routes them to downstream model providers. A custom endpoint or proxy may forward them elsewhere; OpenContext cannot verify what happens behind it.
Your account, credential type, provider settings, and agreement determine retention, logging, and model training. A Claude Code consumer login can have different terms from an API credential. OpenContext cannot promise zero provider retention or no provider training. Review Anthropic's data practices and, if applicable, OpenRouter's provider logging policies, then configure your account for the material you plan to use.
OpenContext's publisher does not receive your content through a collection service or train on it. That is separate from the policies of the provider you choose.
What does pausing AI do?
A saved pause blocks new app model calls and asks active runs to stop. Requests already sent cannot be recalled. Resuming explicitly approves the current endpoint; changing an explicitly approved endpoint requires a new approval. Existing pauses remain in effect.
Pausing AI is not a network-off switch. Integrations, link fetching, Git operations, and browser speech recognition have separate destinations. Linked coding assistants and Model Context Protocol (MCP) clients can read graph evidence and send it using their own accounts and settings. Pausing OpenContext AI does not pause those clients.
Other connections and requests
- Google Drive and Gmail use connected credentials, read-only access, and on-demand syncs.
- GitHub, GitLab, and X use the accounts or links you provide. Repository cloning fetches code; pushing a vault sends tracked content and history to your selected remote.
- Captured links are fetched from the computer running the app, with an address guard. The destination site receives that computer's request.
- Entity scans can search the web and fetch public pages. The model software development kit's (SDK) web-fetch safety check may send a requested hostname to Anthropic separately from your selected model route.
- OpenRouter model discovery and key checks contact OpenRouter when those settings are used.
- Browser dictation may send audio to your browser's speech provider. The composer explains this before recognition starts.
- Optional app sign-in can involve your configured identity provider. Connected databases use your configured database server.
The site and app load no third-party scripts or fonts. Markdown images in the app do not load automatically, preventing embedded tracking pixels. Following an external link opens that site's own privacy boundary. This public website sets no cookies and runs no analytics; its privacy policy explains hosting and access logs.
What stays on your computer
Local storage is still storage. OpenContext retains the graph, original sources, and working files on the computer running your installation. It does not automatically erase everything after distillation. If someone else hosts your installation, that storage is on their server.
Your graph and source documents are not encrypted by OpenContext. Use your operating-system account, disk encryption, and appropriate backup permissions to protect them. A cloud-synced folder or backup service can copy the files outside that computer.
Which files are kept, and where?
| Local material | Location and purpose |
|---|---|
| Knowledge and history | Markdown notes, project graphs in _projects/, and earlier versions in .git/ |
| Sources and prepared text | Original imports in _sources/; converted text and sanitized copies in _extracted/ |
| Working records | Job logs in _logs/; settings, credentials, caches, feeds, reports, and saved conversations in _state/ |
| Connected repositories | Code clones in _repos/ |
- Knowledge and history
- Location and purposeMarkdown notes, project graphs in
_projects/, and earlier versions in.git/ - Sources and prepared text
- Location and purposeOriginal imports in
_sources/; converted text and sanitized copies in_extracted/ - Working records
- Location and purposeJob logs in
_logs/; settings, credentials, caches, feeds, reports, and saved conversations in_state/ - Connected repositories
- Location and purposeCode clones in
_repos/
Some working records contain source text or model output. They remain for their functions, rather than being automatically erased after processing. Credentials and newly saved chat/comparison files use owner-only permissions where supported.
Files can also exist outside the vault: temporary uploads in the app checkout, the vault-location preference, installed command-line files, linked-repository configuration, browser preferences and downloads, optional authentication state, and historical SDK sessions in the user's Claude configuration directory. API cache protections do not remove old downloads, backups, or third-party records.
Are my conversations saved?
New conversations default to Temporary. Their transcripts remain in server memory, with no OpenContext transcript file or saved comparison. They cannot write to the graph or create checkpoints. They expire after one hour without activity, on a server restart, or when switching vaults. Closing a browser tab alone does not erase server memory; delete the conversation to end it immediately. The operating system may write process memory to swap or crash artifacts. Temporary mode does not change provider retention.
Choose Save on this computer to keep questions, answers, and tool activity in _state/chats/ until deletion. Saved conversations can edit the graph; Checkpoint distills their contents into knowledge. Changing the default does not delete previously saved chats. Content-free token and cost counters can remain locally for both modes.
For app-run agents, OpenContext disables the model SDK's separate session history, automatic memory, file checkpoints, and diagnostic telemetry. This does not erase older SDK sessions or change Claude Code sessions you run independently. See the app privacy implementation.
Who can access a local installation?
The API listens on loopback by default and checks Host and Origin headers. Other local users or processes can still reach an unauthenticated local API. Exposing the API beyond the computer requires app sign-in; the server refuses an unauthenticated non-loopback bind. A proxy or tunnel can change that exposure outside the app's knowledge.
This is a single-vault application, not an isolated multi-tenant hosted service. Local ownership is useful control, not protection against someone who already has access to your files, operating-system account, or an exposed installation.
Before you share or delete
Run the local privacy audit and review the actual notes before sharing. It distinguishes findings in graph files from findings in stored originals. A clean report means no configured rules found a match; it is not a guarantee that every sensitive detail is gone.
Export graph only in Privacy excludes originals, app state, logs, extraction caches, repository clones, and Git history. The notes themselves may still contain personal information. Review the contents and the people who will receive them.
Export, Git history, and backups
The full backup export can include originals and version history: review its options before sharing. Git-ignore rules help exclude source and working folders from an ordinary push, but do not protect a whole-folder copy or files already tracked by Git.
Redacting today's note does not remove older Git versions. A push can publish those earlier versions, and copies may already exist in remote repositories or backups. Treat those destinations separately when removing sensitive information.
What does deletion remove?
Discarding a held document removes its original and staged copies. Deleting a saved conversation also deletes its saved comparisons, but not knowledge already written, checkpoint source copies, job logs, or Git history. Disconnecting an integration removes access, not previously imported knowledge.
For complete local removal, stop the app, remove the entire vault including hidden directories, remove leftover uploads and older SDK sessions where applicable, and unlink connected agents. Exports, remote repositories, synced copies, backups, and provider records require separate deletion. OpenContext cannot guarantee secure erasure of storage media or delete a copy held elsewhere.
Your documents and graph remain yours after you stop using OpenContext. The beta license applies to the software, not your content.
Check your own setup
Open Privacy > Your data in your workspace to see the actual vault folder, model destination, AI status, conversation default, and API access mode. You can open the folder, export the graph, or download a configuration report without questions, documents, or credentials. The report includes the folder path.
That view describes your running configuration. It is not an independent security certification or a measurement of provider behavior. In Sensitive content, review held imports and audit findings; use the privacy rule settings to choose what is redacted, blocked, flagged, or allowed.
Set up your installation, read the privacy policy, or review the security documentation. For a security issue, use the private reporting route described there. The repository is private during the closed beta; the maintainer's profile is available if you do not have repository access.