# Dory: known limits

This page states plainly what Dory does not protect against, so nobody learns it the hard way. Each limit names the measurement behind it and what you can do. It is kept beside Dory's acquisition and update trust policy, and a limit that changes is changed here first.

Adapted for the web from Dory's published known-limits document of 13 October 2026, as amended since.

## 1. Instructions hidden in other people's text

Dory can relay what other people wrote to your assistants: a colleague's message, a shared document, an email. Relaying other people's text is on by default. Someone could write an instruction aimed at your assistant into such a message ("ignore your previous instructions and …").

**What Dory does.** Before relayed text reaches an assistant, Dory removes every form that could act by being rendered: links, images, markup and the like. All twelve rendering forms were tested, and **0 of 24** probes of them got through.

**What it does not do.** Dory cannot tell an instruction written as ordinary prose from an ordinary sentence. Of **30** test payloads, **6** got through: every one of them plain prose of the three instruction kinds (2 of 2 each). A permanent test pins that number, so it can never grow silently. These were measured on synthetic payloads.

**What you can do:**

- Treat what Dory relays as information about what someone said, never as instructions to follow. Assistants that keep that distinction are not moved by it.
- If you do not want other people's text relayed at all, narrow what an assistant may receive: `dory permissions`, or the assistant's card in the app.

## 2. One refusal floor without a measured reliability

Dory refuses some content outright, whatever an assistant asks: its refusal floor. One of the floor's rows, F2, has no measured reliability yet. It is enforced, but how often it misses is not known. It will be measured on labelled data before any claim about it is made. Until then, this page says "unmeasured" rather than a number.

## 3. Large stores and response time

Dory's vector search no longer reads the encrypted store per prompt: it scans an in-memory copy (about 125 MB at 300,000 memories, never written to disk) and checks the closest candidates against the stored vectors. The first step that decides what each assistant may see is kept current as memories change, not rebuilt per answer.

On the synthetic 300,000-memory store, through the daemon with the query embedded, one in twenty answers took more than **85.5 ms** with one assistant asking and more than **107 ms** with four asking at once. Half took under about 40 ms and 60 ms respectively. One full background consolidation pass over 300,000 memories took 30 minutes; the bar is one hour.

What still holds:

- **Every number above was read on a fast Mac (M5 Pro, 24 GB), not on the slowest supported one (M1, 16 GB).** Nobody has measured the slowest supported Mac yet; expect it to be slower.
- **Opening a 300,000-memory store takes about 5.4 seconds** in the worst case, when every memory is a candidate for contradiction checks.
- **The query is embedded on the CPU, not on Apple's Neural Engine.** Core ML was measured and rejected: about 7 times slower for Dory's model, and it would change the stored vectors.

The numbers, the machine and what is still owed are kept in Dory's validation records. `dory doctor` reads the live hook's timeouts.

## 4. Dory Reach: web assistants reaching your Mac

Dory Reach is **coming soon**; it is not available yet. When you turn it on, ChatGPT and Claude on the web will reach your Mac at its own address, through a relay Dory runs.

**The one claim.** The relay forwards encrypted traffic it cannot read. Dory could read it only by obtaining a certificate for your name, which is publicly logged, and your Mac checks for it.

What that means, and what it does not:

- **The encryption ends on your Mac.** Your Mac orders its own certificate; its key stays in your Mac's Keychain. The relay reads only the name a connection asks for, then forwards bytes. A test plants a marker in a request and its answer and finds it nowhere in everything the relay forwarded, while the same capture through a proxy that does end the encryption finds it.
- **Dory runs the relay's DNS, so Dory could get a certificate for your name.** Two things stand in the way. The name is pinned to your Mac's own certificate account (CAA), which certificate authorities that honour CAA respect. And every certificate is publicly logged: once a day your Mac searches the logs for its name. A certificate it did not order stops Reach, and the app shows it in red.
- **The relay sees metadata:** when a connection happens, how much is sent, and which vendor's addresses it comes from. It records counts per hour, never your address together with a connection.
- **Availability is your Mac's.** A sleeping or switched-off Mac cannot answer; the assistant gets an error within ten seconds. "Stay awake while plugged in" keeps it awake on power while the app is open.
- **Every request still needs a token from a pairing you confirmed with Touch ID**, exactly as on your Mac alone.
- **Not yet measured on the real relay.** Reach is proven on one machine and on loopback, and its certificate ordering against Let's Encrypt's own test authority. The live tests (ChatGPT and Claude connecting by URL, Let's Encrypt staging, CAA refusing a foreign account) have not run yet.
- **Cloudflare Tunnel and ngrok** remain available if you bring your own; either one reads your answers in transit, because its servers end the encryption.

## 5. What is never claimed

Dory's guarantees are the ones its tests and decisions state. Nothing on this page is a guarantee that an assistant will behave well with what it receives.