Trust

1. What this page is

This page states, in plain terms, what VÆN holds, where it lives, who can see it, when it leaves, how to delete it, and the legal grounds for the processing. This is a public commitment. The Privacy Policy lives at vaen.cc/privacy and carries the binding legal text. This page exists to make the same information readable, in one place, before anyone signs up.

---

2. What VÆN holds

VÆN OS ships with six extensions. Four launch at category-defining depth (Witness, Compass, Enforcer, Forge). Two ship as integration stubs (Fuel as Observe-Only, Playmaker as aggregator). The table lists, per extension, what is collected, how it is created, and how often it changes.

No data is collected by background surveillance. The user enters, imports, or speaks every entry above. Fuel and Playmaker at launch are limited to what the user already records elsewhere (Open Food Facts barcode lookups, Apple Health, third-party fitness platforms). Both extensions deepen post-launch per the roadmap in docs/plans/DECISION-LOG.md §2.

---

3. Where it lives

Footnote 1. Supabase region confirmed eu-central-1 (Frankfurt) on 2026-05-13 by direct dashboard read. Documented in vaen-os/docs/SCHEMA.md schema-conventions front-matter. TODO-JINS A2 closed.

Footnote 2. AI inference runs on AWS Bedrock eu-central-1 (Frankfurt, Germany) per Decision 7 of docs/plans/DECISION-LOG.md (locked 2026-05-14). Vertex AI europe-west-4 (Eemshaven, Netherlands) is documented as a contractual fallback only; not an active deployment path. The code path is wrapped in a provider-abstraction layer so a future switch (Anthropic EU-Direct, Mistral La Platforme, Vertex) is implementable without rewriting the inference layer, per Decision 7 re-evaluate triggers.

Footnote 3. Forge receipt OCR currently runs through the same Anthropic Claude vision pipeline described in §9, hosted on AWS Bedrock eu-central-1 (Frankfurt). A dedicated OCR vendor (Klippa, Netherlands HQ with native EU residency, or Veryfi, US HQ under SCCs with EU residency contractual) is planned to replace this path post-launch. Vendor selection, DPA signing, API keys, and the cut-over smoke test are tracked in TODO-JINS item F5-J13.

Footnote 5. Upstash (§10) hosts rate-limit counters and idempotency keys. Database confirmed 2026-05-14 to run on Google Cloud Platform europe-west1 (Brussels, Belgium) via IP-geolocation of the REST endpoint (35.205.x.x, GCP AS396982, reverse DNS bc.googleusercontent.com, ipinfo city = Brussels, country = BE). EEA-clean. TODO-JINS F5-J7 closed.

Footnote 6. OneSignal (§10) is the push-notification delivery layer. At time of publication (2026-05-14), the OneSignal application is not yet provisioned: the operating-BV is in formation (see §8) and account creation is paused until the BV is incorporated. When provisioned, the OneSignal app will be created on the EU instance to enable data-residency-EU at the storage-and-processing layer. The code is region-agnostic: a single environment variable (ONESIGNAL_API_BASE_URL) switches all REST API calls between US and EU instances, so the runtime choice can land at provisioning time without any code change. The helper getOneSignalApiBaseUrl() in vaen-os/lib/notifications/onesignal.ts is the single read-point; tests confirm the EU host is honoured when the env var is set. Until provisioning closes, push notifications are not active in the product: code paths exist but the env vars are placeholder-only and no push payload is sent. OneSignal, Inc. is US-headquartered, so transfers to the US parent for support, billing, and platform operations will be governed by Standard Contractual Clauses (Module 1, controller-to-processor) once the integration is active, regardless of where notification data is stored. Push payloads are designed to carry title and body text plus a deep-link URL only, never user-content data.

Production user-content data, journal entries, mood logs, habit ledgers, recovery records, AI inference inputs, and AI inference outputs, never leaves the European Economic Area during the request lifecycle. Two narrow exceptions apply for non-content metadata: subscription billing rails (Stripe, EU plus US under SCCs, see §10 and §10b) and push-notification metadata (OneSignal, EU data residency tentative with US-headquartered controller under SCCs Module 1, see §10 and footnote 6). Both exceptions are scoped to the minimum data needed for billing and delivery, and both are disclosed in §10. Operational metadata at other sub-processors (billing records, support tickets, AWS or Google Cloud control-plane logs) may transit between EU and US regions of the same provider under SCCs, governed by each sub-processor's published Data Processing Agreement.

---

4. Who can see it

By default, the only person who can see a user's data is the user.

Cross-pillar reads (the system reading across two or more pillars) require an explicit consent grant per pair (source extension, target extension, inference type). The default state is OFF. The consent matrix lives in Settings under "Your Data, Consent Matrix", and the schema for it is the source of truth (no client-side flag, no default-true list). See F4.3-consent-grants-schema.sql for the data model and F4.3-audit-replay-design.md for the audit trail.

Audit-replay tooling. Every cross-pillar read writes a row to the audit log with: the source events read, the consent grants that enabled the read, the timestamp, and the inference type. At any future moment, the consent state at any past timestamp can be reconstructed by a single database query. If a regulator or the user asks "was this Mirror generation legal?", the answer is a three-table join, not an interpretation. See §11 for how to file the request.

Zero-employee access by default. No member of the team has standing access to production data. Every access happens through a ticket, requires a documented user request or a documented legal obligation, and is logged. The audit log is itself append-only.

---

5. When it leaves

Footnote 4. The 13-month default for cross_pillar_events and for consent-history retention after account deletion is the working figure. The DPO will confirm or revise during F1.5 DPIA co-sign. See TODO-JINS item H1 and H3.

Per-user delete. When a user deletes their account in-app, the database row is soft-deleted for 30 days (accidental-recovery window). After 30 days, a hard-delete cascade runs across all tables holding that user's data. Sub-processors are issued purge requests within 30 days of the hard-delete, per Article 17 GDPR. The full erasure round-trip target is 30 days from the user's initial delete action, with the SLA hard-bound to 30 days as required by Article 12(3) GDPR.

Pseudonymisation. After deletion, audit log rows that must be retained for legal reasons (consent history within the retention window, security incidents within their statutory period) have the user identifier replaced with a stable pseudonymous hash. The original identifier is destroyed at hash time.

---

6. How to delete

In-app: Settings , Your Data , Delete Account.

The page walks through three steps:

1. Export first. A button generates a CSV plus JSON export of every record the system holds for the account, including entries, transcripts, consent history, and inference outputs the user has saved. The export is delivered as a single ZIP archive by email within 14 days of request, hard-bound to 30 days by Article 20 GDPR.
2. Confirm scope. The page lists what will be hard-deleted, what will be soft-deleted for 30 days, and what must be retained under legal retention (e.g., Stripe invoice records for 7 years per Belgian tax law).
3. Confirm intent. The user types the word DELETE in the confirmation field. There is no "are you sure" pop-up. The action is decisive once confirmed.

Outside the app: email dpo@vaen.cc from the email address registered to the account. The Privacy intake (DPO upon engagement, target 2026-06-17 per TODO-JINS D1) responds within 24 hours business day and completes the action within the same 30-day SLA.

---

7. Legal grounds

A Data Protection Impact Assessment is filed and reviewed annually. The DPIA is summarised on this page; the full text is available on request to dpo@vaen.cc.

VÆN's position on Article 22 (automated decision-making) is that cross-pillar inference does not produce a legal-effect or similarly-significant-effect decision because the inference is shown to the user as text and never enforces an action. The user reviews every inference and may reject it. The DPO will confirm this analysis at DPIA co-sign (F1.5, TODO-JINS D7).

---

8. Pseudonymous founder

VÆN is operated by {LEGAL_ENTITY_NAME} (Belgian BV in formation, see footnote 7), with the trademarks (VÆN, ÆON, JÆRVIS) held by a separate Belgian holding-BV. Both entities have addresses on file with the Belgian Crossroads Bank for Enterprises (KBO/BCE) once registered. Director details follow Belgian transparency requirements as restricted by the 2022 CJEU ruling on UBO-register access.

Footnote 7. The operating-BV is in formation as of page publication. The placeholder {LEGAL_ENTITY_NAME} will be replaced with the registered KBO/BCE name once incorporation closes (target: June 2026, tracked under foundation TODO-JINS items A4 + D2). Until incorporation closes, this page is operated by the existing Belgian BV that holds the project's pre-incorporation contracts. Any data-controller obligation between the user and VÆN under GDPR Article 4(7) attaches to the operating-BV upon incorporation and is back-dated to the user's account-creation date for the avoidance of any gap.

The founder operates under the pseudonym The Architect for all public-philosophical surfaces (Manifesto, Quarterly Letter, strategic statements). The pseudonym is a deliberate design choice, not an omission. Anonymity allows the work to hold its line, and the brand voice to stay stable through future succession of the position. Reference: docs/plans/DECISION-LOG.md §3.

On identity claims. VÆN does not confirm or deny identity claims about the people behind the project. This is not a hedge; it is a posture. Identity questions are treated as beside the point. Read the Manifesto, read the Quarterly Letter, decide on the substance. The full standing response is filed at docs/plans/foundation/F1-legal/F1.6-doxx-statement-standard.md and the Architect signs the public version.

WHOIS for vaen.cc and the defensive domains (vaen.com, vaen.eu, vaen.be, and others) is redacted under registrar privacy. Domain technical contact resolves to a privacy-proxy address.

---

9. Anthropic Zero-Data-Retention

The Mirror, the Sunday prompt, and the Weekly Witness Report are generated by an inference call to Anthropic Claude, served from AWS Bedrock eu-central-1 (Frankfurt). The Zero-Data-Retention agreement with Anthropic is currently in signing (target close: pre-launch; tracked under TODO-JINS item D5). ZDR means: prompts and outputs are not stored, not logged beyond the request, and not used to train any model owned by Anthropic or any third party. The 30-day abuse-monitoring window that applies to non-ZDR Anthropic customers will not apply once ZDR is in force. Until ZDR is in force, the Mirror is generated by Anthropic under standard Bedrock retention terms, which keep model-invocation data in eu-central-1 but allow the 30-day window. The code path is wired; AWS Bedrock credentials provision at D5 close.

Every cross-pillar inference call carries a pseudonymised user identifier, not an email or any other directly identifying field. Anthropic never sees a name, an email, or an IP address tied to a VÆN user. The contractual text is available on request to dpo@vaen.cc.

Note on terminology: the technical term "AI inference" appears on this page in three places, the residency table (§3), this section (§9), and the sub-processors table (§10). All three refer to the same Anthropic Claude via AWS Bedrock pipeline described in this section. Elsewhere on the page, and elsewhere in the product, the in-app character that writes the Mirror is referred to as ÆON, because that is the character the user interacts with. The substrate is not the point. The Mirror is.

---

10. Sub-processors

Vercel Edge serves static assets and runs server-side render functions. During PDF and image generation (Mirror artifacts, Compass Booklet, therapist exports, share templates, dynamic Open Graph images), VÆN processes user content within Vercel's render runtime in eu-central-1 (Frankfurt). Content is never persisted by Vercel beyond the render request. The rendered binary is uploaded directly to Supabase Storage or streamed to the user.

Footnote 8. "Transient" means: Vercel's render runtime holds the data in memory for the lifetime of the HTTP request only. No disk writes by Vercel. Render workers are stateless and ephemeral. Vercel's contract is the standard Vercel DPA.

Each new sub-processor passes a DPO review before entering this list. Users may object to a sub-processor under Article 21 by writing to dpo@vaen.cc. If the objection is upheld, VÆN either changes the sub-processor for that user (where feasible) or, if not feasible, terminates the contract with a pro-rata refund.

Future OCR vendor selection. A dedicated OCR vendor (Klippa, Netherlands HQ with native EU residency, or Veryfi, US HQ under SCCs with EU residency contractual) is planned to replace the Anthropic-vision path for Forge receipt scanning. The codebase already abstracts the OCR call behind a provider interface (vaen-os/lib/forge/ocr-provider.ts), so flipping the OCR_PROVIDER env var will route receipts to the chosen vendor without changes to business logic. Vendor selection, DPA signing, API key provisioning, and the end-to-end smoke test are tracked in TODO-JINS item F5-J13 (post-launch P1, target 2026-Q3). When the dedicated vendor goes live, this row updates accordingly and the T1 audit reflects the change.

---

10b. User-initiated integrations and platform partners

The following vendors are not VÆN sub-processors under Article 28 GDPR. They are listed separately because they are visible to the user and the legal relationship differs.

User-initiated OAuth integrations (joint controllers under Article 26)

Each integration starts with an explicit OAuth consent screen on the platform's domain. The user accepts that platform's terms at OAuth time. VÆN never writes data back to these platforms. If a user revokes the OAuth grant on the platform side, the connection breaks immediately and any further sync stops. For Google Fit specifically, Google LLC is the OAuth identity provider and joint controller for the consent screen; the user can manage or revoke the VÆN authorisation at any time via the Google Account permissions page.

The data imported from these platforms is Article 9 special-category data (health). VÆN processes it under Article 9(2)(a) explicit consent, recorded in consent_grants at the moment the user initiates the OAuth flow. See §7 for the consent ledger and §5 for retention.

Platform partners (joint controllers under Article 26)

Apple and Google bill the user directly under their own terms. VÆN receives only the receipt or token needed to activate the subscription on the VÆN side. Neither platform sees user-content data.

On-device APIs (not recipients)

These are not sub-processors. They are device APIs the user grants permission to.

---

11. Crisis routing and Data Subject Rights

If a user's input contains a signal of acute crisis (self-harm, suicide, immediate danger), ÆON breaks character with one plain sentence and routes the user to a country-specific hotline. ÆON does not respond again in that thread until the user returns and re-opens the Mirror. This is the only place in the system where the in-app character ever uses the construction "I will".

The country-specific hotlines at launch:

A user can override the auto-detected country in Settings if needed.

Every change to crisis-related copy (the break message, the hotline numbers, the re-engagement wording when the user returns, any future crisis-adjacent surface) carries triple sign-off per F2-brand/F2.2-aeon-persona.md: Privacy/Legal signs off on regulatory compliance, Brand Steward signs off on voice register, Clinical Advisor signs off on safety. All three sign-offs are logged at docs/plans/foundation/F2-brand/CRISIS-COPY-SIGNOFFS.md. No crisis-related copy ships without all three.

VÆN does not replace professional care. The product is the layer between an app and a professional, not the professional.

Data Subject Rights. All Data Subject Rights (access, rectification, erasure, portability, restriction, objection, consent withdrawal, right not to be subject to automated decision-making) are exercisable in-app under Settings , Your Data, or by writing to dpo@vaen.cc. The Privacy intake (DPO upon engagement, target 2026-06-17 per TODO-JINS D1) responds within 24 hours business day for intake and within 14 days for the substantive response, hard-bound to 30 days by Article 12(3) GDPR. Users have the right to lodge a complaint with the Belgian Data Protection Authority (autoriteitpersoonsgegevens.be) or with the supervisory authority of their member state of residence.

---

12. Last updated

This page is reviewed at every release that touches data flow, plus annually at minimum. The change log above lists every public-facing revision.

---

Contact. dpo@vaen.cc for Data Subject Rights and privacy questions. press@vaen.cc for institutional press inquiries. The Architect signs the Manifesto and the Quarterly Letter, not this page.