amadan
Design draft: TensorX is zero-retention, treat it as local
Paul, 2026-09-19: TensorX is a zero data retention provider, and its egress should be treated as equivalent to a local model until the platform can run inference locally. Proposed as decision 16. The practical content is one ingest path: no per-source "index but never embed" switch, no two-tier corpus, no source excluded on the grounds that indexing means sending. Such a switch is permanent complexity bought for a provider relationship meant to be temporary. What it does not change, and the draft says so: zero retention constrains what may be done with content after it arrives, not what is sent. The ruling's force comes from ZDR closing persistence — the copy decision 8 exists for — and §8.3's sentence about this stands unedited. §3 proposes the §3.6 wording and deliberately omits "we have read those terms", because §8.3 records that no account exists and no terms have been read. Restore that clause and close §13's DPA item the day someone has. The honest claim still may not say "no document leaves this instance" with the assistant on; ZDR does not rehabilitate that. §4 moves §12's local-embedding row to the platform, triggered by the platform being able to host open-weight inference rather than by any memoria measurement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1 file changed,
+143
−0
ZDR-TREAT-AS-LOCAL.md+143 −0
CI failed — run details
diff --git a/ZDR-TREAT-AS-LOCAL.md b/ZDR-TREAT-AS-LOCAL.md| new file mode 100644 |
| index 0000000..95513d3 |
| --- /dev/null |
| +++ b/ZDR-TREAT-AS-LOCAL.md |
| @@ -0,0 +1,143 @@ |
| +# Draft amendment — TensorX is zero-retention; treat it as local |
| + |
| +Against `docs/superpowers/specs/2026-09-03-memoria-design.md`, §3.1, §3.2, |
| +§3.6, §8.3, §12 and §13. **Draft, not a ruling.** §1's table carries "Who, |
| +when" and only Paul fills that column. |
| + |
| +Paul, 2026-09-19: *"TensorX is a zero data retention provider. We should |
| +treat it like a local LLM until we have the platform ability to run |
| +inference completely locally."* |
| + |
| +**Numbering note.** This is *memoria* decision 16. The cross-rung reach |
| +draft proposes *suite* ruling 16. Two namespaces, two different things, |
| +and this file says so because collapsing two numbered things is a failure |
| +this repo has caught before. |
| + |
| +--- |
| + |
| +## 1. What the ruling decides, and what it does not |
| + |
| +**Decides:** the operational posture. Egress to TensorX no longer earns |
| +design cost spent avoiding it. Concretely, and this is the whole practical |
| +content of the ruling: |
| + |
| +- **One ingest path.** No per-source "index but never embed" switch, no |
| + two-tier corpus, no sensitivity classes that exist only to keep content |
| + away from the provider. A switch of that kind is permanent complexity |
| + bought for a provider relationship that is meant to be temporary. |
| +- **No new leak-driven refusals.** A source is not excluded from the corpus |
| + on the grounds that embedding it means sending it. |
| +- **The trigger for local embeddings moves repos** — §4 below. |
| + |
| +**Does not decide, and cannot:** whether a document is transmitted. It is. |
| +Zero retention is a statement about what happens to content *after* it |
| +arrives, which is exactly what §8.3 already says: |
| + |
| +> EU jurisdiction and zero retention constrain what may lawfully be done |
| +> with the content *after* it arrives — the first thing on this page that |
| +> constrains anything — but they do not reduce what is sent. |
| + |
| +**That sentence stays.** It is true, the ruling does not contradict it, and |
| +the ruling's force comes from ZDR closing *persistence* — the copy that |
| +outlives the request and cannot be forgotten, which is the leak decision 8 |
| +exists for — not from closing transmission. |
| + |
| +## 2. ANSWERED 2026-09-19 — Paul: "TensorX is zero-retention" |
| + |
| +Stated as fact, not as advertising. **That settles the internal posture and |
| +§1 governs the design.** What it does not by itself settle is the |
| +*user-facing* sentence, because §8.3's reason for the word "advertised" was |
| +never doubt about the vendor's claim — it was that **no account exists and |
| +no terms have been read**, and a README cannot say "we have read their |
| +terms" on a team's behalf if nobody has. |
| + |
| +So §3 below writes the sentence that is true under Paul's ruling **without** |
| +the clause that would not be: it states that the provider's terms forbid |
| +retention and that we cannot audit them, and it omits "we have read those |
| +terms". **If an account has since been opened and the DPA read, restore that |
| +clause and close §13's DPA item.** Until then §13 stays open, and it is now |
| +evidence under a ruling rather than a tidiness item. |
| + |
| +The original framing is kept below, because the distinction it draws is the |
| +one the §3 wording turns on. |
| + |
| +### 2.1 The distinction, as it stood |
| + |
| +§8.3 says, deliberately and twice: |
| + |
| +> with **advertised** zero retention. Advertised: no account exists, no |
| +> terms have been read, and §3.6 tells the reader we cannot verify a |
| +> retention promise. That sentence keeps saying so. |
| + |
| +**The ruling rests on a fact the spec records as unverified.** That is not |
| +an objection to the ruling — it is a question about which of two user-facing |
| +sentences §3.6 gets, and they are not interchangeable: |
| + |
| +- **Still advertised** (no account, DPA unread): §3.6 keeps "we rely on |
| + their retention terms and cannot verify them". The ruling still governs |
| + *our* design decisions; it does not upgrade what we tell a user. |
| +- **Now verified** (account exists, terms read, DPA read): §3.6 can say the |
| + provider's terms forbid retention, and §13's open DPA item closes. |
| + |
| +§13 already carries the DPA as open, and the ruling makes that item more |
| +load-bearing rather than less: it is now the evidence under a decision |
| +rather than a tidiness item. |
| + |
| +## 3. The §3.6 rewrite, both variants |
| + |
| +The clause under change is the last paragraph's middle sentence. Today: |
| + |
| +> The provider can read what it receives; we rely on their retention terms |
| +> and cannot verify them, and content sent before you deleted something |
| +> cannot be recalled. |
| + |
| +**Proposed, under Paul's 2026-09-19 ruling and §2's constraint:** |
| + |
| +> The provider can read what it receives while it answers, and their terms |
| +> say they keep none of it. We cannot audit that. Content sent before you |
| +> deleted something should not have been kept, and we cannot prove it |
| +> wasn't. |
| + |
| +**The clause deliberately absent is "we have read those terms."** Add it the |
| +day someone has. **What this sentence still may not say is "no document |
| +leaves this instance"** with the assistant on — see below. |
| + |
| +**What neither variant may say is "no document leaves this instance"** with |
| +the assistant on. The README records a code review catching that exact |
| +overclaim in an adjacent sentence, and ZDR does not rehabilitate it. The |
| +true claim with the assistant on is about *retention*, never about |
| +transmission. **This is the one place the ruling must not be allowed to |
| +simplify the wording.** |
| + |
| +## 4. §12's local-embedding row changes owner |
| + |
| +Today the row reads as memoria's, and concludes that self-hosting |
| +`qwen3-embedding-8b` means "a second box to run and keep, not a library |
| +linked into the one binary". Under the ruling's own words — *"until we |
| +have the platform ability to run inference completely locally"* — the row |
| +is a **CARLOS platform capability with memoria as a consumer**. Proposed |
| +trigger: *the platform can host open-weight inference*. Not a memoria |
| +measurement, and not query latency, which is §12's ANN row and a different |
| +question. |
| + |
| +## 5. §3.2 and §3.1 |
| + |
| +The provider entry is not currently its own §3.2 bullet — it lives in §3.1 |
| +("embeddings are content") and §8.3. Wherever it is finally written, |
| +**the entry stays and gains a mitigation line; it is not deleted.** A leak |
| +list that drops mitigated entries stops being a map of where content moves |
| +and becomes a list of unsolved problems, which is a different document. |
| +§1.9's lesson is the precedent: the load-bearing half of a decision must |
| +not live only in a commit message. |
| + |
| +## 6. Consequence for fichas |
| + |
| +Fichas holds notes about people who never signed up for anything. **The |
| +ruling covers retention and not lawful basis**, so ZDR makes the DPA easy |
| +and does not make it unnecessary. §8.3 already records the DPA as unread |
| +and the vendor as young enough to be plausibly renting the infrastructure |
| +it serves from three cities — a subprocessor sees content in exactly the |
| +sense §3.2 means. |
| + |
| +Not a blocker for an instance with one user and no real data. It becomes |
| +one the day a second team runs fichas over real prospects. |