# 02 Universal baseline: rules every RM app obeys

These apply to every product, internal tool, prototype that touches real people's data, and every AI-assisted change. The [app register](/playbook/04-app-register) adds app-specific rules on top; it never subtracts from here.

## A. Red lines

1. **Never claim a security or privacy property the code does not have.** No "end-to-end encrypted", "bank-grade", "HIPAA compliant", "GDPR compliant", "zero-knowledge", "military-grade", "SOC 2" unless it is literally true and evidenced. Meet and CoParent both shipped false E2EE claims; that is an FTC Act section 5 case and a UK CMA case waiting to happen.
2. **Never fabricate social proof.** No invented customers, logos, ratings, testimonials, usage numbers, uptime figures, or "trusted by". Landing pages for Dwell, Tulip and Scribe have all had these purged; do not reintroduce them.
3. **Never store payment card numbers, CVVs, or full bank credentials.** Hosted fields and tokens only.
4. **Never send user content or personal data to a cloud AI provider from an app whose policy says local-only.** The local-AI promise is a marketed property; breaking it silently is deception.
5. **Never let AI act alone on a high-stakes decision** (medical, legal, immigration, financial, employment, housing, child safety, content removal). AI drafts, a human decides, and the product says so.
6. **Never commit secrets.** Several repos have live secrets in history; rotation is tracked in [08](/playbook/08-open-questions). New secrets go in environment files with mode 600, or in systemd drop-ins, never in git.
7. **Never build a dark pattern**: no pre-ticked consent, no confirm-shaming, no hidden cancellation, no countdowns that are not real, no drip pricing, no forced account creation to see a price.
8. **Never collect what the feature does not need.** If a field is not used by code, it is not collected.
9. **Never use children's data for advertising, profiling, or model training.** Never let under-13s in anywhere; never let under-18s into Indian consumer products without a parental-consent flow.
10. **Never ship a breach notification path that depends on one person being awake.** Clocks are 6 hours (CERT-In) and 72 hours (UK ICO, DPDP). See [06](/playbook/06-incident-runbook).

## B. Privacy by default

### Data inventory and classification

Every app keeps a `docs/DATA_MAP.md` (or the equivalent section in its README) listing each personal-data field, its class, purpose, retention, storage location, and processors. Classes:

- **P0 restricted**: health, sex life, sexual orientation, biometrics for identification, children's data, immigration or citizenship status, financial account data, precise geolocation, religion or caste, criminal history, government identifiers (Aadhaar, PAN, SSN, passport), credentials and secrets, private message and email content, recordings.
- **P1 personal**: name, email, phone, address, IP, device identifiers, account activity, resumes, calendar data, contacts, content the user authored.
- **P2 business**: company-level data with no natural person, aggregated or anonymised metrics.

P0 data gets: explicit consent with its own checkbox, encryption at rest with a separate key where practical, access logging, a shorter retention period, exclusion from analytics and AI training, a DPIA entry, and a named owner.

### Notice and consent

- One privacy notice per product, in plain language, versioned, dated, linked from every signup, every footer, and the app store listing. It must list: what we collect, why, the lawful basis (UK and EU), who we share with (named sub-processors), where it is stored (India), how long we keep it, the rights and how to use them, the grievance or DPO contact, cross-border transfer tools, cookies, children, and AI use.
- Consent is a separate affirmative act per purpose: account creation, marketing, P0 categories, cookies (UK and EU), health data (everywhere), recording (Meet), device health permissions (RM Health). Withdrawal is one click in settings and works immediately.
- Keep a **consent ledger**: who, what text version, when, how (IP, user agent), and withdrawal time. DPDP and UK GDPR both require proof.
- Marketing consent is never bundled with terms acceptance.

### Rights

Every product exposes, in settings, without a support ticket: download my data (machine-readable export), correct my data, delete my account (with a clear statement of what is retained and why, for example invoices for tax law), withdraw consent, and lodge a complaint (with the regulator's address for the user's region). Serve requests within 30 days (UK, EU) and within the DPDP Rules period (verify), and log them. Identity-verify before export or deletion.

### Retention

Default schedule unless the app register says otherwise:

| Data | Retain | Then |
| --- | --- | --- |
| Account and profile | Life of account + 30 days grace | Delete |
| Invoices, payment records | 8 years (India Companies Act and GST), 7 years US tax | Delete |
| Server and access logs | 180 days (CERT-In) | Delete |
| Security and audit logs | 1 year | Delete |
| Consent ledger | Life of account + 3 years | Delete |
| Marketing suppression list | Indefinitely (needed to honour opt-outs) | Keep hashed email only |
| Uploaded user content | Until user deletes or account closes + 30 days | Delete, purge backups within 90 days |
| Recordings, transcripts | User-set, default 90 days | Delete |
| Health data | Until user deletes; inactive 2 years then prompt and delete | Delete |
| Children's data (Tulip) | Per school contract; never beyond enrolment + statutory record period | Return or delete |
| Backups | 30 daily, 12 monthly | Rotate; deletion requests propagate on restore |

DPDP Third Schedule forces erasure after 3 years of inactivity for large e-commerce, gaming, and social-media fiduciaries; build the inactivity reaper everywhere anyway.

### Minimisation and analytics

- No third-party advertising SDKs. No Meta Pixel, no Google Ads tags, no data brokers. Product analytics only with a self-hosted or privacy-respecting tool, IP-truncated, and behind consent where the region needs it.
- Error monitoring must scrub PII from payloads (email, tokens, bodies) before they leave the process.
- Logs never contain passwords, tokens, full card numbers, health data, message bodies, or children's data. Structured logging with a redaction list, tested.
- Internal dashboards aggregate; individual user lookups are access-logged.

### Cross-border and processors

- Every third party that touches personal data is a sub-processor: Cloudflare, Resend, Stripe, Razorpay, Google (Gemini, OAuth, Calendar), Groq, Anthropic, GitHub, Expo, Apple, Google Play, MSG91, Meta (WhatsApp), AWS SES, Documenso, TransUnion SmartMove, MinIO if hosted, any email or SMS relay. Maintain `/legal/subprocessors` on each product site, and notify customers 30 days before adding one.
- Sign the provider's DPA and pick the no-training, zero-retention, or enterprise data options where they exist (Gemini paid API, Anthropic, Groq data-retention settings). Record the choice.
- Offer our own DPA (with UK IDTA or Addendum, EU SCCs Module 2, and an Indian annex) to any business customer on request. Template clause list is in [07](/playbook/07-templates).
- Because India has no adequacy decision, **every UK and EU customer contract must include the transfer tool**, and the privacy notice must say data is stored in India.

## C. Security baseline (OWASP ASVS level 2 as the bar)

### Identity and access

- Gate SSO for Orbit apps; OAuth 2.0 with PKCE, exact redirect-URI matching, state and nonce, short-lived access tokens, refresh tokens rotated and revocable, following RFC 9700 (OAuth 2.0 Security Best Current Practice).
- Passwords: minimum 8 characters, maximum at least 64, no composition rules, checked against a breached-password list, argon2id or bcrypt with a per-user salt, no forced periodic rotation, rate-limited login with progressive delays, generic error messages. (NIST SP 800-63B)
- MFA available to every user, mandatory for admins and operators; TOTP (RFC 6238) and passkeys or WebAuthn preferred; SMS OTP only as a fallback. Push approval must use a phone-only approval token (the Gate design), never the browser's polling token.
- Sessions: httpOnly, Secure, SameSite cookies; absolute and idle timeouts; logout revokes server-side; session list with remote sign-out.
- Authorisation checked server-side on every object access. Multi-tenant data needs tenant scoping at the query layer (row-level security where the database supports it, with the session-context reapplied after every commit, as the Mail RLS fix taught us). Every IDOR class found so far (Dwell, Meet, Connect) came from trusting the client's id.
- Admin and break-glass paths are refused from the public edge (check `X-Forwarded-For`), logged, and time-bound.

### Transport and storage

- TLS 1.2 minimum, 1.3 preferred, HSTS, Cloudflare in front of everything public; origins bound to loopback or `::` behind the tunnel, never the public IP.
- Encryption at rest for P0 data with keys outside the database; disk encryption for the host; database credentials per app, least privilege, non-superuser roles for application connections.
- Secrets in files with mode 600 or systemd credentials; rotation procedure documented per app; key material that must never rotate (Gate RSA, VAPID, Fernet) labelled as such.
- Backups encrypted, off-box copy, restore tested quarterly and logged. No backups means no product (Scribe is the open case).

### Application

- Input validation and output encoding everywhere; parameterised queries; HTML from users sanitised (nh3 or DOMPurify) on both write and read; file uploads type-sniffed, size-capped, stored outside the web root under random names, served with `Content-Disposition` and a separate origin or strict CSP; images re-encoded.
- CSRF protection for cookie sessions; CORS allow-lists, never `*` with credentials; security headers (CSP, X-Content-Type-Options, X-Frame-Options or frame-ancestors, Referrer-Policy, Permissions-Policy) set by the app, since nginx needs root here.
- SSRF guards on any server-side fetch of user-supplied URLs (webhooks, link previews, calendar URLs, yt-dlp targets): block private ranges and the metadata IPs, resolve then connect, time out.
- Rate limiting on auth, OTP, password reset, public forms, share links, APIs; per-IP and per-account; loopback exempt so health checks work.
- No state-changing GET endpoints (the RM Sign logout prefetch lesson). Idempotency keys on payment and send paths.
- Dependencies pinned and scanned (npm audit, pip-audit, Dependabot or Renovate); a software bill of materials per release; no end-of-life runtimes.
- Path traversal: resolve and contain every filesystem path built from a request (the Meet serve.cjs case).
- WebSockets and Socket.IO: authenticate on connect, authorise per room, rate-limit per socket, and never broadcast across tenants.

### Operations

- Logs kept 180 days in India (CERT-In), clocks synced, access to logs restricted, logs free of secrets and P0 data.
- Health endpoints, watchdogs, and restarts do not lose state (Meet in-process Maps, Music in-memory sessions were both data-loss bugs).
- Change management: a branch, tests green, the [ship gate](/playbook/05-ship-gate), one change per deploy, a rollback path.
- Vulnerability disclosure: `/.well-known/security.txt` (RFC 9116) on every public host, a monitored security mailbox, acknowledgement within 3 business days, no legal threats against good-faith researchers.
- Incident response per [06](/playbook/06-incident-runbook), drilled twice a year.
- Access reviews quarterly: who has SSH, database, Cloudflare, registrar, Stripe, Razorpay, Resend, GitHub org, Apple and Google developer accounts. Hardware keys for the root accounts.

### Roadmap attestations

Not legally required, but US and UK enterprise buyers will ask: SOC 2 Type II and ISO/IEC 27001. Keep evidence as you go (policies, access reviews, change logs, vendor reviews, risk register) so an audit is a packaging exercise, not a rebuild. ISO/IEC 42001 for AI management is the next one buyers will ask for.

## D. AI rules (every feature that calls a model)

1. **Disclose.** Users are told, in the interface where it happens, that content, scores, summaries, or replies are AI-generated, and what the human review step is. Chat-style features say "You are talking to an AI" at the start of each session. Regulated contexts (health, legal, immigration, finance) say it again in the output.
2. **Local by default.** Ollama on the box is the standard. Cloud providers only where the app register lists an approved exception; when used, send the minimum, strip identifiers where the task allows, choose no-training and zero-retention settings, and name the provider in the privacy notice and sub-processor list.
3. **Human in the loop for consequential outputs.** A person approves before anything is published under a customer's name (Scribe), sent to a third party (Digitailor applications, Planet outreach), filed with an authority (Merit), or used to change a plan that affects health (RM Health). The UI shows who approved.
4. **No invented facts.** References, statistics, citations, quotes, case law, statutes, prices, and people must be verified against a source before they appear in output; unverifiable claims are dropped or marked. This is the "verified refs" rule from Research and the "no claim without a rule_id" rule from Nimitra, generalised.
5. **Safety filters are deterministic and sit after the model.** Self-harm, medical emergencies, child safety, violence, and illegal-activity triggers route to fixed, reviewed responses and resources, never to a free-form model reply. Companion-style features (Imprint, Nimitra persona, RM Health coach) must have a suicide and self-harm protocol and minors blocked.
6. **Prompts are code.** System prompts live in the repo, are reviewed, versioned, and tested with regression cases including adversarial ones (prompt injection via uploaded documents, emails, web pages, resumes). Model output is untrusted input to the rest of the system: never executed, never rendered as HTML unsanitised, never given authority it was not explicitly granted.
7. **Logging of prompts and completions** is minimised: no P0 data in prompt logs; retention 30 days; access-logged. Users can opt out of their content being used to improve prompts; nothing is used to train models without separate, explicit consent.
8. **Rights apply to AI outputs.** Profiles, scores, and summaries about a person are personal data: exportable, correctable, deletable.
9. **No emotion inference, biometric categorisation, social scoring, or manipulation.** No inferring protected characteristics. No "dark" persuasion.
10. **Provider terms flow down.** OpenAI, Anthropic, Google, Groq usage policies forbid certain uses (medical diagnosis without oversight, legal advice without oversight, surveillance, deception). Our product rules are at least as strict.
11. **Copyright.** Outputs may not reproduce third-party works at length; generated images and text that mimic a living person's voice or likeness are not used; training data and retrieval corpora are licensed or public-domain and documented.
12. **Label synthetic media.** Any AI-generated image, audio, or video carries a visible label and, where a standard exists, provenance metadata (C2PA). India's IT Rules amendment and YouTube's policy both require it.

## E. Communications (email, SMS, push, WhatsApp)

- Transactional and marketing are separate streams with separate templates, separate sending identities, and a flag in the send path. Marketing needs consent (PECR opt-in or soft opt-in in the UK, DPDP consent in India, CAN-SPAM opt-out in the US, CASL express consent in Canada) and a one-click unsubscribe (RFC 8058 `List-Unsubscribe-Post` header) honoured instantly.
- Every commercial email carries: the legal sender name, a postal address (Visakhapatnam registered office), a reason line ("you are receiving this because..."), and the unsubscribe link. SPF, DKIM, DMARC aligned on the sending domain; we send from rmmail.in only, through Resend.
- A global **suppression list** shared by all apps (hashed addresses): bounces, complaints, unsubscribes, fake seed domains. Dwell's 100-email burst to fake seed addresses burned the shared daily quota and the domain's reputation; never send to unverified recipients from production.
- SMS to India needs DLT-registered headers and templates; to the US needs TCPA consent (marketing: prior express written consent) and STOP handling; to the UK needs PECR consent. WhatsApp follows Meta's policy and templates.
- Push notifications are opt-in at the OS level and have a per-category toggle in app. No marketing push without consent.
- Caps and circuit breakers: per-app daily send budget, alert at 80%, hard stop at 100%, with a copy-link fallback so the product still works when the quota is gone.

## F. Payments, subscriptions, invoices

- Stripe (US, UK, global) and Razorpay (India) hosted checkout or elements; webhooks verified by signature, idempotent, and replay-safe; never trust the client's statement of what was paid.
- PCI DSS 4.0 scope stays at SAQ A: no card data on our servers, no card fields we render ourselves, iframes or redirects only.
- Prices shown with tax treatment; GST for India, VAT for UK and EU with number validation for B2B, US sales tax when nexus triggers. Every invoice numbered sequentially per series, immutable once issued, with the mandatory GST fields for Indian supplies and the LUT reference for exports. RM Bills is the only issuer of numbered documents.
- Subscriptions: all material terms on one screen before the button (price, period, renewal, trial end, how to cancel); renewal reminders for annual plans; online cancellation in no more steps than signup; refunds policy published; price changes notified in advance with a right to cancel.
- Indian recurring payments run on the provider's e-mandate flow; we do not store mandates ourselves.
- Third-party money (fees to schools, reimbursements between parents, vendor payouts, rent to landlords) goes through a licensed split-settlement or connected-accounts product; Rang & Mall never holds or routes funds that belong to someone else.
- Receipts and refunds within the times the regime sets; chargeback evidence kept (signup IP, consent text, usage logs).
- App stores: digital goods bought inside iOS or Android apps use the store's billing unless a legal carve-out applies in that market; follow Apple 3.1.1 and Google Play Billing policy; external purchase links only where the store allows them (US after the Epic injunction, verify current state).

## G. Content, IP, and platform terms

- User uploads: a DMCA agent registered with the US Copyright Office, a notice-and-takedown process, a counter-notice path, a repeat-infringer policy, an IT Rules grievance officer for India, and an Online Safety Act reporting path for the UK. Removal requests logged with reasons; statement of reasons to the uploader (DSA style).
- Abuse: CSAM detection and reporting path (NCMEC for US-related, local police and the IT Rules for India, IWF-aligned for the UK); non-consensual intimate imagery removed within 24 hours of complaint; terrorism and violent content removed on notice.
- Open source licences: no AGPL code linked into proprietary services without isolation or a commercial licence (Swiss Ephemeris rejected in Nimitra; Documenso and SearxNG run unmodified as separate services); GPL not linked; attribution file shipped; licence scan in CI. Fonts used under their licence terms; RM Forma is ours, Google Fonts are OFL.
- Third-party platform terms are law for us: YouTube, LinkedIn, X, Meta, Google APIs, Apple, Google Play, Stripe, Razorpay, GitHub. Automated access beyond what an official API allows is a red line unless the app register grants a specific, documented exception with a risk acceptance.
- Trademarks: product names that collide with household brands (Meet, Drive, Nest, Authenticator, Atlas, Planet) are used only with the RM house mark, never with the other company's colours, logo, or typography, and never in a way that suggests affiliation. File Indian trademark applications for the names we keep.
- Our copy never implies government, court, bank, medical, or university affiliation we do not have.

## H. Accessibility and copy

- WCAG 2.2 AA: keyboard operable, visible focus, 4.5:1 contrast, labels and names on every control, error identification, no content that only exists behind a script that can fail, captions for video, reduced-motion respected, target size 24 px. Test with a screen reader once per release.
- Copy rules already in force across RM: short declarative sentences, no em-dashes, no emoji in product copy, no fake urgency, no jargon in consent text, operator identity "Rang & Mall" internally and "An R&M Product" in customer-facing footers.
- Legal pages in the product language; DPDP notices available in the Eighth Schedule languages we support in the app.

## I. Trust pages every public product must have

!!! note "RM Orbit apps: link to the suite notices"
    A suite-level set for the Orbit apps is published at [/legal/orbit/](/legal/orbit/) (privacy, terms, sub-processors, AI, cookies, retention, security, grievance, accessibility). An Orbit app satisfies this section by linking `/legal/orbit/privacy` and `/legal/orbit/terms` from its footer and sign-in page, and by adding its own `/.well-known/security.txt`. Products outside the suite publish their own pages.

`/legal/privacy`, `/legal/terms`, `/legal/cookies` (UK and EU traffic), `/legal/refunds` (anything that charges), `/legal/subprocessors`, `/legal/dpa` (business products), `/legal/grievance` (India: Grievance Officer name, email, postal address, response times; DPO or contact person), `/legal/ai` (what AI does here, which providers, how to opt out), `/legal/accessibility`, `/legal/security` with a link to `/.well-known/security.txt`, `/legal/dmca` (US, if user uploads exist), `/legal/retention`, and a children's statement (18+ unless the product is designed for children).

## J. Vendor and dependency register

Keep one file per app listing: vendor, purpose, data shared, region, DPA signed (date), no-training or retention setting, contract owner, exit plan. The shared list today: Cloudflare (tunnel, DNS, WAF), Resend (email), Stripe, Razorpay, Google (Gemini API, OAuth, Calendar, Play), Apple (App Store), Expo EAS, GitHub, Groq, Anthropic, MSG91, Meta WhatsApp Cloud API, AWS SES (digitailor.org mail), TransUnion SmartMove, Documenso, GoDaddy SMTP (founder@ mailbox), YouTube (Music, unlicensed, see register), LinkedIn and X APIs (Scribe, Writer-X).