Research and egress

Research is where a private writing tool is most likely to leak, because a web search says something about what you are working on. Storyline screens, shows you and records every crossing.

The research desk

• One capture bar. Paste a link, type a note, drop a file or speak a thought, and it goes through the same ingestion pipeline.
• Ingestion on the device. Web pages go through ReadabilityCleaner, a Readability-style cleaner with no third-party DOM parser. PDFs go through PDFTextExtractor and audio is transcribed on the device. Text is chunked and embedded with NLEmbedding for similarity search across your notes.
• Originals kept and sealed. Every imported original is kept on the device from the moment it arrives, sealed at rest with AES-GCM under the vault key, and decrypted only when you view or export it. A repeat import offers the existing copy instead of a silent duplicate.
• Synthesis. A one-tap synthesis on the device pulls the themes, the strongest claims and one open gap from your notes into a short brief.
• Citing into the draft. A picker inserts a note reference at the cursor, ranked by relevance to the page you are on, as a link, a formatted reference, a quote or a marker. Citation engines for APA, AMA, Bluebook and others are deterministic, and clips keep a provenance chain from the quoted passage back to the source bytes.

Real sources, or none

Select a phrase and choose Search the web, and Storyline runs a real search. DuckDuckGo is the default backend and needs no key. Where the project’s policy allows cloud models, an OpenAI or Anthropic key lets that model run the research and read full pages. The first search is issued deterministically, so it fires even with an on-device model that would not call a tool by itself. The model finds real sources or says plainly that nothing came back; it does not invent citations. If the web is unreachable, you get the on-device result and a note saying so.

One door out

Every outbound request from research passes through EgressFunnel. The network transports are private to the tool layer, so the only network path a tool can reach is the funnel’s fetch and search, and a link you paste for import crosses the same funnel. The funnel screens each request, writes the ledger entry before anything is sent, and returns one of three verdicts: pass, warned or blocked. Content coming back goes through IngressFunnel, which screens and defuses it before it reaches the model.

selected passage
  → distilled on the device to a few generic keywords (short topics pass as typed)
  → screened: Tier 0 protected terms, Tier 1 semantic closeness, the pattern guard
  → consent sheet: the exact query and its verdict
       clean · flagged · blocked · circling a protected topic
       edit it, generalise it on the device, then choose Local or External
  → External: the funnel records a sealed ledger entry, adds its hash to the audit chain, then sends

The leak guard

• Tier 0, hard block. The query is checked against the project’s protected vocabulary: names from its knowledge base and identifiers from its project facts, such as case numbers and client or matter names. A hit blocks the crossing, whether the model issued the search or it is the deterministic first search.
• Tier 1, soft warning. An on-device embedding measures how close the query sits to protected material, and close queries are flagged. If protected material exists but the embedder cannot run, the result is “unverified” and the crossing is recorded as warned, never as a silent pass.

The consent sheet

The sheet shows the exact text that would leave. You can edit it; the edit is screened again, and the edited text is what gets searched. Generalise asks the on-device model for the broadest form of the query that still returns useful background, without names or the specific mechanism, and screens the result before it can go. In the 1.2.1 launch demo, a line naming a protected person was held back because “protected terms never leave the device”, and the query that went out instead was “An individual is working on a project and requires validation”. Approvals are recorded in the audit chain.

The search-pattern guard

Each query can be clean while the sequence gives you away. The pattern guard watches for that, on the device. It embeds each outbound query, measures how close it sits to the project’s protected material and how tightly recent queries cluster around one concept, and keeps a running signal that decays with time and count. Past a threshold, the sheet warns that your searches are circling a protected topic and suggests staying on the device or generalising; it does not block. The guard keeps vectors and a score, never the query text, and the audit chain records only that it fired, with a coarse score.

Per-project controls

• Privileged projects keep web research off by default. Allow approved web research turns it on, and each crossing still needs your consent. Queries are kept generic, the search history is sealed to the vault, and research threads are held in memory only.
• Keep research on this device makes a project’s research on-device only.
• Anonymise web searches is reserved for a privacy relay. Until one is configured it also keeps research on the device; both options fail closed.

The Data flow ledger

Each project has a Data flow ledger: what left this device, and what came back.

Section	What it lists
Outbound	Every query that left, verbatim, with the leak guard’s verdict
Inbound	Every source that came back, verbatim, next to the query that fetched it

It also lists activity that stayed on the device, such as dictation. Entries are sealed, and the audit chain holds a hash of each, so the ledger can be checked against the chain.

These protections are a security posture, not legal advice. Whether search traces bear on patent novelty, priority or confidentiality is a question for a patent attorney.