# TRUST.md — The Trust Posture

Trust is the company. The artifact is the hook; the data is the moat; the trust posture is what keeps users contributing data for 10 years. Everything in this document is binding and visible.

## 1. The 12 commitments (published on `/tillit`)

Numbered list, both languages, prominently linked from the footer of every page.

### 1. Append-only architecture
Your answers are immutable events. We never overwrite history. We publish the schema. → `/metode/arkitektur`

### 2. Foundation-held data trust
User data is held by Stiftelsen Folkepsyk (a Norwegian foundation under Stiftelsesloven), not the operating company. In bankruptcy or sale, the data does not transfer to creditors or buyers. This is codified in the stiftelse's vedtekter, not just our privacy policy. Modeled on Mozilla Foundation/Corporation split.

### 3. Open methodology
Our personality measurement model, IRT item parameters, validation studies, and recompute-on-improvement procedure are published. We do not claim what we do not show. → `/metode`

### 4. Annual transparency report
Every year on the anniversary of our launch (not in December — we don't compete with Spotify Wrapped for attention), we publish:
- Government data requests received and complied with
- Employee access to user data (number of accesses, role categories)
- Security incidents (within 72 hours of detection)
- DPA correspondence summaries
- Methodology changes

### 5. One-click full export
GDPR Article 20 compliance via "Download my data" — JSON + CSV, schemas published, includes every raw answer, not just derived profile. Available at `/konto/eksport`.

### 6. One-click full erasure
GDPR Article 17 compliance, including the bitemporal record of erasure itself (we keep the fact that data was erased, not the data). Crypto-shredding via per-user DEK destruction. Available at `/konto/slett`.

### 7. No data sale, ever
Codified in Stiftelsen Folkepsyk's vedtekter. If the operating company is sold, the foundation's bylaws bind any buyer. Reference: the 23andMe bankruptcy 2025, where $305M sale of 15M genomes to TTAM Research Institute proceeded over user objection because no such bylaws existed.

### 8. No third-party advertising trackers
Subscription + (optional) public grant funding only. Schibsted-style editorial firewall around the research arm. No Mixpanel, Amplitude, Google Analytics, Segment, PostHog Cloud, Meta Pixel.

### 9. Federated / on-device computation where feasible
Personality re-scoring runs client-side when possible. Aggregate analytics use differential privacy (target ε well below 10; we publish actual ε per dataset release).

### 10. Disclosed legal jurisdiction and threat model
Norway. Datatilsynet as supervisory authority. Published list of every government we'd refuse a request from, and our procedure for non-Norwegian/EU requests.

### 11. Open-source client
The client code, including all data-handling, is auditable on GitHub. Server-side is closed-by-default but reproducible builds for the personality model.

### 12. Disclosed independent audit cadence
Annual third-party privacy + security audit, results published. Standing auditor (Norwegian academic institution — Simula, NR, or NTNU).

## 2. Why these 12 are the right 12

The empirical lesson from precedents:

- **Signal**: "data we don't have" is the strongest commitment possible. We can't quite do that (we need the data for the longitudinal moat), so we do the next strongest thing: data that can't be sold and is crypto-shredded on erasure.
- **Proton**: published transparency report with uncomfortable numbers (94% compliance with legal orders). Real trust requires real disclosure.
- **Apple ATT**: privacy nutrition labels were imperfectly enforced (Kollnig et al. 2022 found 80%+ of "no data collected" apps actually had trackers), but the norm-setting move was right. We do the equivalent: granular per-category consent toggles with reasoning.
- **DuckDuckGo Microsoft tracker incident (2022)**: damage was real but recoverable because they admitted and fixed it publicly. Our commitment: any privacy regression disclosed within 30 days of internal discovery.
- **23andMe bankruptcy (2025)**: $305M sale of 15M genomes despite user objection demonstrates that a privacy policy is not enough. Foundation structure is the architectural fix.

## 3. The foundation (Stiftelsen Folkepsyk)

### 3.1 Legal form

**Alminnelig stiftelse** (ordinary, non-commercial foundation) initially, under Lov om stiftelser 2001-06-15 nr. 59.

Convert to næringsdrivende only when commercial operation requires it (i.e., after revenue).

### 3.2 Requirements

- **Grunnkapital**: NOK 100,000 (alminnelig) — founder's contribution
- **Board**: ≥3 members with ≥1 external (not founder or family)
- **Auditor**: required by Stiftelsesloven
- **Name**: must contain "stiftelse" or "STI" (mandatory since lovendring July 2024)
- **Vedtekter**: specify name, formål, grunnkapital, styresammensetning, vedtektsendringer
- **Registration**: in Stiftelsesregisteret (Stiftelsestilsynet) AND Enhetsregisteret
- **Auditor confirmation** that grunnkapital is in place

### 3.3 The formål (purpose) — draft

To be replaced with lawyer-cleared version, but as a starting point:

> "Stiftelsen Folkepsyk har til formål å fremme allmennhetens forståelse av egen personlighet, relasjoner og psykiske velvære gjennom åpen, vitenskapelig forankret metodikk; å forvalte et longitudinelt datasett av norsk personlighet og relasjonsdynamikk til allmennyttig forskning; og å sikre at metode, kildekode og dataforvaltning skjer i full åpenhet og under brukerkontroll."

### 3.4 The Mozilla model, portable to Norway

Mozilla Foundation (501(c)(3)) owns 100% of Mozilla Corporation (taxable subsidiary). Foundation sets mission; corporation employs engineers; profits flow back. We apply the same pattern:

- **Stiftelsen Folkepsyk** (foundation): owns the user dataset, holds vedtekter, sets mission
- **Folkepsyk AS** (operating company, formed when needed): runs commercial operations, pays the founder, employs developers
- **Stiftelsen owns 100% of AS shares** when the AS exists
- **AS dividends after-tax profit to Stiftelsen**, which by formål spends it on the public-benefit mission

**Do NOT form the AS in v0.** In v0 there is only the Stiftelsen, and Mikal operates as a contractor or sole proprietorship doing development work for it. The AS appears when revenue justifies it or when investors require it.

### 3.5 Norwegian law firms

Engaged law firms with stiftelse expertise:

1. **Wikborg Rein** — full-service, frequently used by Norwegian tech and foundations
2. **BAHR** — explicit stiftelse practice (published Family Office material), strong on governance
3. **Schjødt** — strong on tech/IP-heavy structures
4. **Wiersholm** — good on data protection and tech

Budget: NOK 60,000–120,000 in legal fees for incorporation + bylaws + data-trust governance structure.

Recommended starting point: **Wikborg Rein or Wiersholm** given the data-protection angle. Get an intro from a mutual contact — the conversation is faster than cold outreach.

### 3.6 Timing

- Week 6: outreach to law firm + draft vedtekter
- Week 8-10: incorporation paperwork filed
- Week 10-14: registered in Stiftelsesregisteret + Enhetsregisteret (typical Norwegian timeline)

Until incorporation is complete, Mikal is the personal data controller. The trust page must be honest about this transition:

> "Stiftelsen Folkepsyk er under stiftelse. Frem til registrering er Mikal Lewis databehandlingsansvarlig som privatperson under en hensiktserklæring om overføring til stiftelsen ved registrering."

## 4. What we publish (the methodology page `/metode`)

The methodology page is not optional. It is the operational expression of the open-method commitment.

Contents:

1. **Instruments used**: IPIP-NEO-120 (Johnson 2014, public domain), ECR-R scenario adaptations (Brennan/Clark/Shaver 1998 lineage, our scenario format is original), Schwartz values (when added), Natsal-3 breakup taxonomy.
2. **The item bank**: every published item with `item_id`, version, source, both translations, reviewer, scoring direction, domain + facet, link to git blob.
3. **Scoring rules**: how raw responses become trait scores; IRT parameters when calibrated.
4. **The bitemporal data architecture**: high-level explanation of system_time vs valid_time, the never-UPDATE rule.
5. **The crypto-shredding erasure mechanism**: what happens technically when a user requests erasure.
6. **The constellation algorithm**: facet→hue map, correlation table, seed function. Link to GitHub source for current and past generator versions.
7. **The recompute changelog**: every time the model is improved, what changed and why.
8. **Validation studies**: as they accumulate, published here with full data tables.
9. **Known limitations**: explicit list of where the science is contested or weak. Updated as the literature evolves.

## 5. What we never collect

Publish this as a "What we don't ask" list on the trust page:

- IP address (we hash it once for rate-limiting, never store the raw)
- Precise location (no GPS, no IP geolocation)
- Device fingerprint
- Browsing history outside our site
- Contacts list
- Photos
- Sexual partners' identities (only your own characterization of a stub-person)
- Real name unless explicitly given via Vipps/Apple login
- Friends-of-friends graph
- Anything from Facebook/Meta SDKs (we don't use them)

## 6. The annual transparency report format

First report due 1 year from launch date. Format:

```markdown
# Folkepsyk Transparency Report — [Year]

## Government data requests
- Requests received: N
- Requests complied with: M
- Requests challenged: K
- Country breakdown
- For each: hashed identifier, request type, our response

## Employee/contractor access to user data
- Number of access events: X
- By role: developer N, support M, analyst K
- Reason categories: debugging, support ticket, security incident, research export

## Security incidents
- Incidents detected: X
- Users affected: Y
- Median time to user disclosure: Z hours
- Detail per incident

## Data exports requested by users (Article 20)
- Number: X
- Median time to delivery: Y hours

## Erasure requests (Article 17)
- Number: X
- Crypto-shredded: Y
- Failed (with reason): Z

## Methodology changes
- Item additions: list
- Item retirements: list
- Generator version bumps: list
- IRT recalibrations: list with effect size summaries

## DPA correspondence
- Submissions to Datatilsynet: X
- Datatilsynet inquiries received: Y
- Summaries with outcomes

## Audit results
- Third-party audit completed: yes/no
- Findings: list
- Remediation status
```

The first report sets the cadence. Honesty over polish — uncomfortable numbers stay in.

## 7. The deletion experience

The `/konto/slett` flow:

1. **Step 1 — Warning screen**: "Sletting er endelig. Slik foregår det:"
   - We destroy your encryption key (DEK) within 24 hours via Supabase Vault
   - Your encrypted answers become unreadable but the bitemporal record of their existence is kept (we know data was erased; we don't know what it was)
   - You receive a receipt ID for verification
   - Your aggregate contributions to anonymous research (if you opted in) remain, fully anonymized
2. **Step 2 — Confirmation**: type your pseudonym to confirm
3. **Step 3 — Receipt**: receipt ID, timestamp, what was destroyed
4. **Verification path**: visit `/verifiser/[receipt_id]` to confirm erasure status

Test path:

- Create test user
- Take quiz
- Request erasure
- Wait 24h
- Verify: `answer_events` rows exist but `users.email_encrypted` decrypts to gibberish
- Verify: export-my-data returns empty (only metadata remains)

## 8. The export experience

The `/konto/eksport` flow:

- One click, ZIP delivered within 1 hour (typically <60 seconds for v0 users)
- Structure:

```
folkepsyk_export_2026-XX-XX_user_<pseudonym>.zip
├── README.md                    # schema + how to read this
├── identity.json                # account, consent log, devices
├── answers/
│   ├── answers_raw.jsonl        # every event, ever
│   ├── answers_raw.parquet      # same, analytical format
│   └── item_dictionary.json     # item_id → text → version history
├── profiles/
│   ├── snapshots.jsonl          # every computed profile, with model_version
│   └── model_changelog.md       # when/why each recompute happened
├── relationships/
│   ├── people.jsonl             # user-owned stubs
│   ├── transitions.jsonl        # state-change events
│   └── outcomes.jsonl           # post-mortems
└── visual_identity/
    ├── constellations/          # every rendered artifact, dated
    └── snapshots.json
```

The README in the ZIP includes the JSON Schema URIs for each file type, so a researcher can validate the data structurally.

## 9. Consent UX (operational details)

The 5 categories from SCHEMA.md §3 manifest as 5 toggles on the consent screen at first signup:

1. **"Personlighet og holdninger"** — required, can't proceed without. Framed as "what the product needs to work."
2. **"Tilknytningsstil og relasjoner"** — required, same framing.
3. **"Sett som kan antyde psykisk helse"** — optional, default OFF. Copy: "Vi spør ikke om diagnoser. Noen spørsmål handler om hvordan du har det, og det kan i visse tilfeller telles som helsedata under GDPR."
4. **"Bruk av mine svar i fremtidig forskning, fullt anonymisert"** — optional, default OFF. Copy: "Bidra til norsk personlighets- og relasjonsforskning. Du kan trekke deg når som helst."
5. **"Re-engasjement etter 30/60/90 dager"** — optional, default ON. Copy: "E-poster når konstellasjonen din kan ha endret seg. Lett å avregistrere."

Granular update path: `/konto/samtykke` shows all 5 with current state, lets user toggle individually. Every change writes a `consent_log` row.

## 10. The bankruptcy-resistance architecture

The 23andMe outcome (June 27, 2025 bankruptcy sale order; $305M to TTAM Research Institute) is the case study. The court used an "equity toggle" — putting data assets in a wholly-owned subsidiary, then selling subsidiary equity rather than data directly — to argue no asset transfer occurred, sidestepping state genetic-privacy statutes.

Our architecture:

1. **User data is owned by Stiftelsen Folkepsyk** from day one (or from incorporation day; we have the hensiktserklæring during the bridge period).
2. **Folkepsyk AS** (when formed) operates as a data processor for the Stiftelsen, not data controller.
3. **The Stiftelsen's vedtekter** prohibit transfer of the user dataset to any for-profit entity.
4. **Auditor verifies** annually that the Stiftelsen retains data control.
5. **In bankruptcy of the AS**, the Stiftelsen is a separate legal entity with separate assets. Creditors of the AS have no claim on the Stiftelsen's data.
6. **In acquisition of the AS**, the buyer cannot acquire the data — they acquire only the operating contract with the Stiftelsen, who can terminate the contract.

This is the architectural fix that 23andMe didn't have. Wikborg Rein or BAHR needs to verify the structure holds under Norwegian law. The "Mozilla model portable to Norway" is the working hypothesis.

## 11. The trust page (`/tillit`) wireframe

- H1: "Vår tillitsposisjon"
- Sub: "Ditt språk, vår metode, dine data — under ditt eierskap."
- The 12 commitments as a numbered list with expandable sections
- Foundation status box: current legal status of the Stiftelsen, registration number when complete
- "Hva vi aldri samler inn" list
- "Hvordan kontakte oss om personvern" with security@folkepsyk.no PGP key
- "Siste oppdatering" timestamp + git commit hash linking to the page's source

Trust isn't a one-time campaign. It's a page that gets a commit every time we change anything.

## 12. Things Claude Code must NOT do

- **Never add tracking pixels** even from "privacy-friendly" providers. We use Vercel Analytics + Plausible EU only.
- **Never email users without consent**. Re-engagement consent is opt-in (default ON at signup but explicit).
- **Never store decrypted PII in logs** (Sentry, console.log, Vercel logs). Strip PII at the boundary.
- **Never UPDATE on event tables**. Defense in depth: triggers + permissions + code review.
- **Never expose raw user IDs in URLs** that get crawled. Use slugs or short hashes.
- **Never auto-share to social platforms**. Sharing is always a user-initiated tap on the Share button.
- **Never include "compare with friends" features** that surface others' data without their explicit consent.
- **Never use US-jurisdiction analytics, error tracking, or email services**.
- **Never assert the Stiftelsen exists** before it does. Use the honest interim copy in §3.6.