Djeed · Trust Center
Methodology in public. Provenance on every governed record. A clear deployment boundary for every surface. No third-party analytics, no advertising pixels, no cross-site tracking, no behavioural profiling. The operational signals we do keep are the minimum needed to run the service well — and inside DjeedX every customer gets an audit trail for activity in their own workspace. Anchor and Gateway use separate knowledge foundations per app, profile, and tenant; nothing connects across those scopes by default.
This page is the official record of how that works. For contractual terms see Privacy, Terms, and the DPA.
Pillar 01
No Google Analytics, no advertising pixels, no session-replay tools, no behavioural profiling. The browser ships with one strictly-necessary auth cookie, one bot-protection cookie, and a first-party theme preference. That's it.
Cookie Policy →Pillar 02
DjeedX runs in Geneva. Anchor Desk is designed for on-device and sealed operation. Anchor Cloud is being built for a tenant-isolated Swiss workspace. Gateway is isolated per instance. The public website has a separate Cloudflare boundary, including globally replicated KV for submitted leads.
Compare every surface →Pillar 03
Every customer, app, profile, and deployment has its own knowledge foundation and tool registry. Cross-scope sharing is explicit, logged, purpose-limited, and revocable — never an automatic match behind the scenes.
How we audit →Section 01
Two columns side by side, plain language. The left column lists every signal we collect, where it lives, and how long we keep it. The right column lists categories of data we have decided not to collect.
What we collect
What we don't collect
The bottom lineDjeed runs no <script> tag that pings a third-party analytics endpoint on either djeed.com or DjeedX. The performance and privacy benefits compound: lighter pages, no consent banner, no third-party contracts to audit.
Section 02
Status, deployment, data, and isolation are stated together. Preview and in-development surfaces are labelled as such; a residency promise on one product is never silently applied to another.
| Surface | Status | Deployment boundary | Data in scope | Isolation |
|---|---|---|---|---|
| djeed.com | Live | Cloudflare Pages; R2 in the EU jurisdictional ring; KV globally replicated | Public site content, submitted lead details, and operational rate-limit state | Separate from customer product workspaces |
| DjeedX | Invite-only beta | Infomaniak Public Cloud · Geneva, Switzerland | Workspace records, files, graph data, audit metadata, and backups | Workspace and tenant boundaries in the application and data layers |
| Anchor Desk | Public preview · in development | Customer device; sealed zero-egress mode is a product requirement | Only approved local folders, conversations, memory, models, and tools | Separate foundation per selected working scope; no cloud attach while sealed |
| Anchor Cloud | In development | Planned tenant-isolated Swiss workspace on Infomaniak | Tenant-approved sources, foundation, routines, and organization tools | Separate tenant foundation and tool registry; explicit grants only |
| Gateway | Live embedded surface | Instance-specific; agreed for each tenant | That site's foundation, approved brief, session context, and server-side tools | No visitor filesystem or terminal access; no cross-site visitor profile |
| Cloud Services | Scoped delivery | Customer-selected cloud, data centre, air-gapped environment, or provider | Defined in the delivery scope and data-processing terms | Customer-specific architecture and responsibility model |
Section 03
The two current infrastructure boundaries below are deliberately separated. Your workspace data — the records you create in DjeedX, the audit log, the backups — sits in Geneva, Switzerland, on Infomaniak Public Cloud. Infomaniak is an independent, ethical, Swiss-sovereign cloud and AI provider — renewable-powered, under Swiss data-protection law, and deliberately not a US hyperscaler. Djeed's own AI runs on Infomaniak's sovereign Swiss AI, so the intelligence layer stays in the same jurisdiction as the data. The public website at djeed.com is a separate Cloudflare surface. Its R2 object store uses the EU jurisdictional ring; Cloudflare KV, which stores lead submissions and rate-limit state, is globally replicated and has no per-namespace residency control. Anchor and Gateway boundaries are stated separately in the matrix above.
Side A · your data
Every record you create in DjeedX, every member you invite, every file you upload, every audit-log entry, every backup — all of it lives on Infomaniak Public Cloud in Geneva. Infomaniak is an independent, ethical, Swiss-sovereign cloud and AI provider — renewable-powered and under Swiss data-protection law, not a US hyperscaler. The factory that produces base datasets runs on the same Swiss infrastructure. This is where your real data sits.
Side B · the website
The public site, methodology pages, and lead-capture forms run on Cloudflare Pages at the European edge. Storage on this side is small and operational: aggregate factory snapshots, lead-form submissions, and rate-limit counters. None of your DjeedX workspace data passes through here.
┌──────── visitor ────────┐ │ │ ▼ ▼ ┌── Cloudflare edge (global) ──┐ djeedx.djeed.com sign-in │ TLS 1.3 · WAF · Turnstile │ │ │ DNS · CDN · Bot mgmt │ │ (passes through, └────────────┬──────────────────┘ │ not stored on CF) │ │ SIDE B — website surface (Cloudflare) │ ┌─────────────┬──────────────────┐ │ ▼ ▼ ▼ │ djeed.com KV (global) R2 (EU jurisdiction) │ Pages leads + rate-limit factory stats │ │ SIDE A — your data (Infomaniak Geneva, CH) ◀──────┘ Infomaniak Public Cloud · Geneva, Switzerland ├─ Postgres 16 + PostGIS (workspace records, audit) ├─ Neo4j 5 + APOC (graph data) ├─ Redis (job queue) ├─ Object storage (CH) (backups, 30-day rotation) └─ Caddy host (TLS termination) Identity: Clerk (EU residency configured) — clerk.djeed.com
Residency is product- and service-specific. DjeedX customer content stays inside its Swiss workspace boundary; public-site lead submissions use globally replicated Cloudflare KV. The applicable processing and transfer terms are documented in Privacy §04.
Section 04
The other companies that process personal data on Djeed's behalf, what each one does, and where they sit. Each is bound by a written agreement and processes data only on our documented instructions.
| Sub-processor | Role | Region | Status |
|---|---|---|---|
| Cloudflare, Inc. | Website surface only: CDN, DNS, R2 (public site snapshots), KV (lead submissions + rate-limit), Turnstile bot protection. Does not process DjeedX workspace data. | Global edge (EU/CH primarily for European visitors); R2 bucket created in the EU jurisdictional ring (Western Europe); KV globally replicated (no per-namespace residency). | Active |
| Infomaniak Network SA | Compute, PostgreSQL, Neo4j, Redis, and CH-resident object storage for DjeedX workspaces. Also the target infrastructure for tenant-isolated Anchor Cloud workspaces as that surface is built. | Geneva, Switzerland | Active |
| Clerk, Inc. | Identity, sessions, organisation management | EU residency configured | Active |
| Neo4j, Inc. | Managed graph database (Aura) — engaged when DjeedX migrates from container Neo4j to managed Aura | EU | Contracted, not yet active |
| Resend, Inc. | Transactional email — engaged when transactional mail is enabled | EU | Contracted, not yet active |
| Stripe Payments Europe, Ltd. | Payment processing — engaged when paid plans are activated | EU | Contracted, not yet active |
Material changes to the sub-processor list are notified to account holders by email at least 14 days before the change takes effect.
Section 05
The technical and organisational safeguards that are in place today. Items are listed only when they are running in production — items in flight are tracked separately in the strategy document and surface here when they ship.
TLS 1.3 on every public endpoint. HSTS preload-eligible. No mixed-content paths.
AES-256 for databases, object storage, and backups. Keys managed by the underlying provider; rotation is on the provider's schedule.
Inside DjeedX, every workspace has its own row-level security boundary at the Postgres layer. Cross-workspace queries are not possible at the database level.
Anchor and Gateway treat each app, profile, tenant, and deployment as a separate foundation with a separate tool registry. Sharing requires an explicit, logged grant.
Every record write inside DjeedX is logged with actor, timestamp, IP, and diff. The log is append-only and surfaced back to workspace admins.
Cloudflare Turnstile gates the public lead-form endpoints. Sign-in attempts are throttled by Clerk.
Daily backups of Postgres and Neo4j, encrypted at rest, with a 30-day rotation window. Stored in Switzerland alongside primary storage. Restore procedure documented and rehearsed.
GitHub Dependabot on the platform monorepo. CI build is non-deployable on a high-severity advisory in a production dependency.
Operator access to production is limited to the founder during the private-beta phase. Cloud credentials are stored in chmod-0600 files on the operator workstation, never in the repo, never in chat.
Section 06
Operational signals we keep to run the service reliably — focused on the platform itself, not on the visitor as an individual. Categories, sources, and what gets flagged.
Cloudflare WAF
Injection attempts (SQL, command, header), known-bad payloads, request-size anomalies — filtered with Cloudflare's managed ruleset.
Cloudflare Bot Score + Turnstile
Automated traffic, scraping behaviour, headless-browser fingerprints. Forms fail-closed when Turnstile validation fails.
Cloudflare KV counters + Clerk
Per-IP request floods on /api/leads/* and sign-in. Counters surface to operators; the IP is throttled or blocked at the edge.
Clerk security events
Repeated failed-credential attempts, sign-ins from unusual geographies, OAuth callback anomalies, session-token reuse.
FastAPI structured logs (DjeedX)
5xx error spikes, slow queries, dramatiq job failures, Postgres connection-pool saturation.
Postgres audit_log table
Bulk-delete patterns, export bursts, member-role escalations. Surfaced to the workspace admin in the customer Audit Center (Phase 3) and to operators only on customer report.
Section 07
We welcome reports from security researchers. If you have found a vulnerability, contact us before disclosing publicly — we acknowledge within 72 hours and will work with you on a co-ordinated timeline.
How to report
Include reproduction steps, affected URL or endpoint, the impact you believe the issue has, and any suggested mitigation. PGP available on request.
Machine-readable: see /.well-known/security.txt (RFC 9116).
What we ask
Section 08
We name the standards we align to today and the ones we are working toward. Where a certification is not yet held we say so plainly, rather than implying coverage we don't have.
The Privacy Policy, DPA, and operating practice implement the controller and processor obligations of Regulation (EU) 2016/679. Subject-rights workflow runs through privacy@djeed.com with a 30-day SLA.
The Federal Act on Data Protection (revised, in force September 2023) is observed for all Switzerland-resident data. Switzerland is covered by the EU Adequacy Decision (renewed January 2024).
No non-essential cookies, no client-side tracking. Article 5(3) consent is not triggered because there is no storage on or access to user-device data beyond strictly-necessary purposes.
Annex A self-assessment is on the roadmap post-incorporation. We do not claim certification.
Type I readiness assessment planned once the operating entity is incorporated and a multi-engineer team is onboarded. We do not claim certification.
The Bronze → Silver → Gold pipeline that produces our records is mapped to the Berkeley Protocol on Digital Open Source Investigations — the most rigorous open-source-research standard available. The same chain-of-custody discipline travels across sectors, from a planning team tracking permits across municipalities to a corporate-research team building entity graphs from registries and filings. See the Methodology page.
Section 09
Operational status, incident history, and the policy we follow when an incident affects customer data.
Live status
A public uptime page covering djeed.com, djeedx.djeed.com, and their API endpoints will publish at status.djeed.com. Until it ships, operational issues are posted to the Djeed Beta workspace announcement channel and emailed to affected accounts.
Incident response policy
For any personal-data breach, we notify the relevant supervisory authority and affected customers within 72 hours of becoming aware, per GDPR Article 33. Post-incident review is published as a public postmortem when remediation is complete.
Talk to a person
Privacy and data-protection rights: privacy@djeed.com. Vulnerability reports: security@djeed.com. Contractual or commercial questions: legal@djeed.com. We respond within 30 days; usually much sooner.
Living documentThe Trust Center reflects the operating practice of the private beta. Sub-processor list, certification status, and incident history are kept current; material changes are notified to account holders by email at least 14 days before they take effect.