App register

Ordered by compliance risk. Each entry lists what the app is, who uses it and where, the data classes it holds, the domain modules that apply, the red flags found in the live code or memory as of 2026-08-21, and the must-do list. The machine-readable version is /apps.json.

Status legend: live (public URL with real users), pilot (real users, closed), internal (company use only), dormant (code exists, nothing running), planned (docs only).

Development addition: Music Gen (2026-09-14)#

• What: Music Gen, RM Portfolio/Music_Gen, experiment.freedomlabs.in. Observed status: development prototype. Separate from FreeTunes/RM Music.
• Authorisation: the operator explicitly requested enabling the disabled Gemini integration on 2026-09-14. Record a narrow Google Gemini/Lyria BYOK exception for development use. This is not a public-launch approval or a legal/vendor review sign-off.
• AI and egress: user-provided Google key only; no managed credential or provider fallback. Browser sends creative prompts, lyrics and selected settings directly to the official Google API after unchecked session consent. store=false on Interactions requests; provider terms and abuse-monitoring retention still apply. Paid-project, adult-use, and eligible-region acknowledgement required.
• Data: P0 Google key in page memory only; P1 creative text and preferences; generated audio and Google consent/access events in page memory. Operator requested browser-persistent setups on 2026-09-14: explicit Save stores project name, creative setup, AI text drafts, selected model, random ID, revision, timestamps and storage-notice version in IndexedDB until deletion or browser eviction. No API keys, Google consent, or audio in projects. Storage is origin/profile-specific, not app-encrypted, and not a cloud backup. Export/delete available. Disconnect aborts requests and clears the key. Clear session removes current drafts/output, not saved projects. No uploads, microphone, cloud library, or publishing.
• Pricing: display dated official Google Standard paid-tier USD rates with source, text token/thinking caveat and tax/account variation. Not an invoice, spend meter or hard cap. No new RM charge or payment processor.
• Modules: M6 and M16. Regions: operator development use; public-launch countries not approved.
• Must do: disclose AI and Google processing, no sensitive or third-party confidential material, no voice cloning or copied copyrighted lyrics, no auto-publish, no credentials in URLs/logs/storage, no automatic retries or fallback on billing/permission errors; test cancellation and pre-consent egress prevention. Complete production hosting, provider/transfer terms, consent retention, trust pages, and public-launch review before external users.

Tier 1: regulated domains, highest exposure#

RM Health (ex FitterMe)#

• What: lifestyle weight-loss coaching, mobile app (Expo) + web coach console; health.freedomlabs.in; RM External/FitterMe. Status: pilot (2 users).
• Users and regions: India now; product is global by design, US and UK likely.
• Data: P0 health (weight, body metrics, meals, food photos, steps, HR, HRV, sleep via HealthKit and Health Connect, goals), P1 identity. Possible cycle data (women's-health tab removed; do not re-add without M1 rules).
• Modules: M1, M11, M16 (Gate).
• Regimes: DPDP and SPDI (health is sensitive), UK GDPR Article 9 + DPIA, FTC Act and FTC Health Breach Notification Rule, Washington MHMDA and clones, California CMIA and CalOPPA, Apple HealthKit and Google Health Connect policies, Drugs and Magic Remedies Act for claims, ASA and FTC weight-loss advertising rules, Colorado AI Act (health care category) if coaching drives care decisions.
• Red flags: AI coaching brain was a facade until the think:false fix; keep a regression test that the coach's output is real and guarded. Goal-enum bug produced wrong calorie targets: nutrition math must have unit tests with physiological floors. Coach (Sasi) is not a licensed dietitian: copy must say "coach", plans are "suggestions you accept". Staging on SQLite, single worker: not fit for health data at scale; Postgres, backups, and encryption at rest before any user beyond the pilot. Mobile build pending: Data Safety form and App Privacy labels must match the actual SDKs.
• Must do: health-data consent per stream; deterministic ED and red-flag guardrails with tests; Consumer Health Data Privacy Policy page; HealthKit and Health Connect declarations; no analytics SDKs; FTC HBNR and state breach plan in the runbook; DPIA on file; export and delete in app; 18+ gate; inactive-data reaper; remove "RM Health" from any listing that shows other Orbit apps (private app).

RM Pharma screening assistant and DuoFlow Dx#

• What: infection-screening chatbot (healthtest.freedomlabs.in, RM Pharma, local gemma4:12b, image input) and the DuoFlow Dx cartridge site (pharma.freedomlabs.in, DuoFlow). Status: live site, investigational product.
• Users and regions: India (AP and Telangana students), anyone who finds the URL.
• Data: P0 health symptoms and photos of test strips or affected areas (memory-only by design), language choice; contact-form data on the DuoFlow site.
• Modules: M1, M1b, M13.
• Regimes: Medical Devices Rules 2017 (software as medical device, IVD), CDSCO licensing, New Drugs and Clinical Trials Rules 2019 for evaluations, FDA device law if US users, UK MDR, EU IVDR, Telemedicine Practice Guidelines (AI cannot consult or prescribe), Drugs and Magic Remedies Act, DPDP, Patents Act section 3(i).
• Red flags: the chatbot interprets cartridge photos and maps zones to results: that is device functionality without a licence. Public URL with no gate means anyone can use it clinically. Contact form relays through GoDaddy SMTP from [email protected] (consent text and retention for enquiries needed).
• Must do: investigational banner on every screen, "not for diagnosis, not approved by CDSCO or FDA"; no public marketing of cartridge reading; ethics-committee approval and consent for any real-sample evaluation; keep photos memory-only (test for it); AI self-identification in all 8 languages; regulatory-status page kept truthful; start ISO 13485 and IEC 62304 technical file; patent copy stays device-only.

CampusIndex (Tulip engine; formerly EduOS, RM Schools)#

• What: K-12 school OS for Indian private schools: SIS, attendance, exams and term report cards, learning profiles, fees counter and receipts, concessions, accounts (vouchers, cash and bank books), staff attendance and payroll, gate register and early-pickup passes, library, parent-teacher meetings, admissions, documents with public QR verification, an assistant that acts with the user's own permissions; RM Portfolio/Tulip; home.campusindex.in. Status: pilot-ready (2 schools signed up as of 2026-10-11, no real data yet).
• Users and regions: India only. Children, parents, teachers, office staff, school admins.
• Data: P0 children's data (identity, attendance, marks, learning profile, photos, health notes, transport, early-pickup records naming who collected the child), parents' contact and payment records, P0 staff financial identifiers (bank account, IFSC, PAN, UAN, salary, payslips; added 2026-10-11), P1 staff attendance, visitor log (name, mobile, purpose), library loans, parent-teacher meeting notes, live bus location from the attendant's phone during a trip (kept 48 hours; visible to staff and the parents of children on that route). Public verification (/v/<code>) shows only the minimal facts printed on the paper; a gate pass verifies on its day only.
• AI: local model (Ollama on our server) for the assistant; no school data to third-party AI. Every change the assistant proposes waits for the user's confirmation and runs through the API as that user.
• Modules: M2, M4, M11 (parent PWA), M14 (government schools).
• Regimes: DPDP children's provisions and Rule 10 consent, Fourth Schedule Part A, IT Rules, RBI PA Directions (fee settlement), EPF and ESI Acts and state professional-tax laws (payroll figures are computed, the school files), Income-tax Act (PAN, TDS), GST 18%, Consumer Protection E-Commerce Rules (marketplace), Legal Metrology and FSSAI (listings), TRAI DLT, WhatsApp Business policy, POCSO reporting, Aadhaar restrictions, ASCI.
• Red flags: per-school Razorpay is built (a school without its own connected account gets "pay at the office"; the demo payment is demo-school only); keep it that way, never a global key. Landing page once carried invented customers and ratings (purged; keep it purged). At-risk and learning-profile analytics must stay school-scoped, non-stigmatising, and never show another child's mark (class figures need 5+ children). Statutory payroll rates are built in from published slabs and must be checked by the school's auditor each year.
• Must do: DPA with each school that bars cross-school training; verifiable parental consent flow; staff bank account, PAN and UAN encrypted at rest and masked in the UI (done 2026-10-11); retention: visitor log 180 days, early-pickup records 1 year, bus positions 48 hours (nightly job, done 2026-10-11); automatic fee reminders opt-in per school, at most weekly per family (done 2026-10-11); keep the cross-school write and child-read guards (tests) green; no ads or tracking in the parent app; DLT templates; marketplace grievance officer; GST on every quote; POCSO escalation SOP; GIGW and regional-language readiness for government schools.
• Launch controls (05, L1-L11), 2026-10-11: evidence in tests/test_launch_controls.py and scripts/third_party_scan.py (0 outside requests). Done: parental consent record per child (in-app or paper, withdrawable, exact notice kept); children do not sign in; Terms/DPA accepted by name and version; grievance form, desk and clocks; audit trail kept 400 days and readable by the school; CSP and images uploaded only; WhatsApp/SMS opt-out honoured at send; phone numbers and message text out of logs; sub-processors (Cloudflare, Meta, MSG91, Google FCM, Razorpay) on /privacy and in the DPA annex. Open: a named Grievance Officer in GRIEVANCE_OFFICER_* (the pages say "use the form" until set); DLT registration for the MSG91 templates; pricing shown on the landing (per year) disagrees with the plans in the app (per month, 14-day trial); counsel to confirm the IT Rules 2026 text and whether the school or CampusIndex is the intermediary for takedown. Pilot close-out, 2026-10-11: phone alerts are standard Web Push (VAPID; payload encrypted for the device; browser push services named on /privacy and in the DPA annex). Messages are in each parent's chosen language (en/hi/te). Circulars go only to the addressed families, receipts only to the paying family. Plans and the free term match the published offer, and no school can mark itself paid. The whole-school export (GET /schools/me/export) is office-only and audited. Backups are owner-only and mirrored to a second disk; off-site is still open. Full audit, 2026-10-12 (three read-only reviews: security, flows, claims against code; evidence in tests/test_security_2026_10_12.py and tests/test_ready_for_a_real_school.py). Closed: parents could list every child; a parent link crossed schools; one online payment could be replayed; no one could change a password and resets left sessions alive; demo logins with passwords in the public bundle; the API reference public; field encryption shared the sign-in secret (now its own key, FIELD_ENCRYPTION_KEY, which must be kept off-machine); principal and coordinator roles did not exist. Made true: per-child export of every record and audited; erasure everywhere with a stated keep-list; consent withdrawal alerts the head of school; consent notice v2026-10b names bus location, boarding, photo, pickup persons and early-warning; DPA published at /dpa; offboarding script; audit trail screen. Reworded: online fee payment is not available (no parent checkout exists), WhatsApp/SMS not on, "stored in India". Open: demo teacher/parent passwords are still the old weak ones (rotate); the sales demo principal's password was reset by a test and needs restoring; Postgres/Redis use default local credentials and containers run as root; WeasyPrint has no deny-all URL fetcher; sign-in tokens are in localStorage with no idle timeout; no incident runbook naming who notifies which school; operator's legal form, registered address and GSTIN are blank on every agreement. First-day walk, 2026-10-12/13 (a new school taken through its seven setup steps in a browser; evidence in tests/test_fee_setup.py, four of five planted defects caught on a copy). New personal-data field: users.slip_code (P1), an UNUSED one-time sign-in code kept encrypted with the field key so a printed slip can be reprinted, cleared at first sign-in; stated in DPA 4.1 and on /privacy. Closed: setting a fee charged nobody until an unexplained second step, and doubled dues if repeated; a child admitted later owed nothing; reprinting slips killed the codes already handed out; a new school could not save its letterhead; the overdue-fees and children-needing-attention screens were labelled "AI" for what is a rule over the school's own records (reworded; no model is involved). Open: the Generate route's own duplicate guard was planted together with another defect and is not separately proven. 2026-10-13: receipt numbers were unique across all schools, so a second school's first payment failed (now unique per school; tests/test_new_school_sweep.py runs two schools and every list route for a new school, 0 server errors); the dues import's already-imported check hashed file bytes and let a re-saved file double old dues (now hashes the rows); PDFs can load only embedded images and our own fonts (print_kit.render_pdf); sessions end when unused (office roles 12 hours on the server and 30 minutes untouched in the browser, teachers 7 days, parents 30 days); docs/INCIDENT_RUNBOOK.md and scripts/incident.py exist but the runbook's named people (incident lead, second, Grievance Officer, counsel) are blank, and there is still no off-site copy of backups or of the field encryption key. The school app now has its own test suite (109 Jest tests in admin/src/__tests__, 18 of 18 planted defects caught by scripts/mutate_frontend.py) and scripts/deploy_admin.sh refuses to deploy on a red suite; scripts/test_all.sh runs everything. App containers run as an ordinary user with no capabilities. Open: the Postgres password is still the default in docker-compose.yml until a person runs scripts/rotate_db_password.sh; Redis has no password (loopback and the private container network only). 2026-10-13, realtime and load: the live stream opens only with a single-use ticket (a sign-in token in a URL is refused); tests/test_live.py now uses throwaway schools (it had been signing in to the demo school) and proves an event reaches its own school and family within 1.5 s and nobody else. The pilot kit moved from a hosted page to /kit?k=<PILOT_KIT_KEY> on our own site (noindex, no outside loads). Overdue-fees list 5.9 s to 0.07 s at 1,200 children. scripts/e2e_first_day.py drives the deployed app in a real browser (office and parent side by side) and found that the letterhead form lost what was typed while it loaded. scripts/e2e_teacher_day.py (teacher and parent on phones) found a false statement to parents: a message only PREPARED while WhatsApp is not switched on was listed on the parent's phone as "WhatsApp to you" and on the office's record as "WhatsApp to parent"; parents now see only what reached them and the office sees "not switched on: not sent" (test_a_parent_is_never_told_a_message_reached_them_on_whatsapp_when_it_did_not). It also found two phone-layout faults (the roll's Save bar over the last child, the leave sheet's Send button under the tab bar). Tenant isolation, 2026-10-13: the check that every id in a request body belongs to the caller's school was something each route had to remember; 28 write routes had not, and 5 of 15 probed accepted another school's ids (a parent linked to another school's child, an exam and a section under another school's class). It now runs centrally before all 133 routes with a body (core/tenancy.guard_request_bodies; test_every_route_with_a_body_checks_that_its_ids_are_the_callers_school). No real school's data was involved: only the demo school exists. Also: no exam could be created from the screen (a schema accepted only an empty date); fixed, with scripts/e2e_exam_day.py. 2026-10-15, two-step sign-in: office roles (admin, principal, coordinator, accountant) can add an authenticator-app code (RFC 6238) after the password; a school can require it for its office (Settings). New stored fields on users: totp_secret (encrypted with the field key), totp_on, totp_recovery (SHA-256 hashes of ten one-time recovery codes; the codes themselves are shown once and never stored). A code works once, a sign-in ticket allows five tries and lives five minutes, and a principal's reset for a lost phone ends that person's sessions and is in the audit trail. Evidence: tests/test_two_step.py, admin/src/__tests__/two-step.test.tsx, scripts/e2e_two_step.py. The tenancy check now runs as a dependency of the whole API router (core/tenancy.own_ids_in_body), after the FastAPI 0.143 upgrade made the earlier wrapper ineffective. 2026-10-15, later: the school check now covers ids in URL paths and query strings too (tests/test_ids_in_urls.py; no live leak found, the rule is now structural). Found and fixed: since the FastAPI upgrade, saves were committed after the answer was sent, so a read straight after could show the old value (12 of 30; tests/test_saved_before_answered.py). API answers now carry nosniff, DENY framing, no-referrer, no-store and a JSON CSP. Audits in docs/security/AUDIT_2026-10-15.md: Python 0 findings, shipped JS 0, git history clean. Data map (docs/compliance/DATA_MAP.md, enforced by tests/test_data_map.py), DPIA draft (docs/compliance/DPIA.md), sub-processor scan, and a browser-storage section on /privacy (no tracking; two sign-in tokens, one marker cookie, display choices, an offline copy of pages and never records). Ended sign-ins are now removed 30 days after they end. Open: Redis password (scripts/set_redis_password.sh), DB password, a retention period for grievances, counsel review of the DPIA. 2026-10-15, evening: a parent's screens and the consent notice are in Hindi and Telugu when the parent chooses them, and the consent record keeps the exact text agreed to in that language (DPDP s.5(3); tests/test_parent_language.py); native-speaker check still open. Accessibility: axe WCAG 2.1 AA over 33 screen checks, 0 findings (scripts/a11y_check.py). The assistant had been failing every question because its model had been removed from the server; it now uses the installed model, and an instruction is no longer answered as a question. Sales documents (demo script, one-pager, pricing) rewritten to remove claims the product cannot back (a pay-now link, a 70-to-90% collection promise, AI that predicts payment, pay-only-if-it-works, the marketplace); the School Service Agreement no longer promises online payment, and its support times match the annexure. Releases go through scripts/release.sh (full check, tag) with scripts/rollback.sh.

CoParent#

• What: co-parenting communication, scheduling, expenses, evidence exports; RM Portfolio/CoParent; coparent.freedomlabs.in. Status: pilot-ready, P0s open.
• Users and regions: US first (Free, Record, Court tiers), India wedge (BSA section 63 certificates), NRI cases.
• Data: P0 children's details, family-law disputes, messages, payments between parents, attorney access, location of exchanges.
• Modules: M2, M3, M4, M5, M7.
• Regimes: COPPA adjacent (data about children entered by parents), state privacy and breach laws, FRE 902 evidence rules, BSA 2023 section 63, DPDP, UK GDPR if UK parents, FTC Act (encryption claim), money-transmission law if funds flow, UPL if the AI suggests legal strategy, domestic-violence safety expectations.
• Red flags: UI claims "END-TO-END ENCRYPTED" while the server reads messages for tone analysis (deceptive); one committed SECRET_KEY roots JWT, Fernet, and the evidence HMAC chain; 65B certificate cites the repealed Evidence Act and is machine-signed; one parent can grant attorneys access to the other parent's data; CSP broke PDF export.
• Must do: remove the E2EE claim (or build it); three-key split and rotation; BSA section 63 wording with a human custodian signature; mutual consent or court order for third-party access; expense settlement through Stripe Connect only; tone analysis disclosed and optional; dual-region pin honoured; safe-exit and address-hiding features for abuse cases; attorney-review of the legal drafts before publishing.

Digitailor (Reach)#

• What: visa-aware autonomous job applying for US tech candidates; RM External/Reach, runs on the user's device; home.digitailor.org. Status: live, early.
• Users and regions: US only (India parked).
• Data: P0 immigration status, EEO self-identification, resumes, inbox access (receipt verification), P0 account credentials (bcrypt password hashes, added 2026-08-21 with email sign-in; never stored or logged in plaintext, single-use mailed tokens stored as SHA-256 digests), P1 identity; DOL LCA public data.
• Modules: M8, M11, M10 (outreach).
• Regimes: CPRA sensitive PI (immigration status), Virginia, Colorado, Connecticut opt-in for sensitive data, CalOPPA, FTC Act (accuracy and autonomy claims), CFAA and platform terms (LinkedIn, job boards, ATS vendors), Google API Services User Data Policy (restricted Gmail scopes, CASA assessment, Limited Use), CAN-SPAM for recruiter outreach, Title VII adjacency, Stripe billing rules, ROSCA.
• Red flags: bot-detection episodes (SmartRecruiters) are a stop signal; zero verified applies in August shows the verification promise is not yet met, so marketing must not claim it; billing needs price ids and a refund policy before charging.
• Must do: email sign-in additions (2026-08-21): registration must never create an account before the mailed link is opened (a Google sign-in on the same address lands in the same row, so an unverified password account is an account-takeover path); identical responses whether or not an address is known; per-account lockout in the database; password-changed notice to the owner.
• Must do: written per-channel terms review and risk acceptance; candidate-approval step and submission preview; never infer protected-class or authorisation answers; Gmail restricted-scope verification or a forwarding-address design; sensitive-data consent screen; "applications are submitted as you, you are responsible for their accuracy" in terms; delete resume data on request; honest marketing (no "auto-apply to 1,000 jobs" claims without verified numbers).

LegalOS#

• What: cross-border legal OS with AI personas for founders (India and US), 402 deterministic rules; RM Portfolio/LegalOS; legalos.freedomlabs.in. Status: live.
• Users and regions: India and US founders; optional user-supplied cloud keys.
• Data: P1 company and founder data, P0 legal matters and documents, user API keys.
• Modules: M3, M16.
• Regimes: Advocates Act and Bar Council rules, US state UPL, Texas 81.101(c) disclosure model, Colorado AI Act (legal services), DPDP, CalOPPA, provider terms for BYOK.
• Red flags: demo credentials documented in memory; personas can read as attorneys.
• Must do: "not a law firm, not legal advice, not a substitute for an attorney" in the UI at every advice-like output; persona disclosure as AI; citations verified and dated; BYOK keys encrypted and never logged; rotate the documented passwords; retention and deletion for matters.

Merit (O-1 and EB-1A readiness)#

• What: petition-readiness rubric, evidence extraction, drafting; RM Portfolio/EB1A; merit.freedomlabs.in :45036. Status: building, Gemini Flash Lite only.
• Users and regions: US-bound petitioners (many in India), attorneys.
• Data: P0 immigration files, passports, employment history, publications, salary, letters.
• Modules: M3, M13, M11.
• Regimes: 8 CFR 1001.1 (immigration advice limited to attorneys and accredited representatives), state notario-fraud laws, UK IAA if UK users, USCIS perjury exposure for petitioners, CPRA sensitive PI, DPDP, Gemini API data terms.
• Red flags: drafting engine could produce filings; terms gate exists (keep the tests).
• Must do: disclosure on every output; two scores never collapsed; evidence traceability to uploaded documents; local PII redaction before Gemini; no-training API tier; attorney hand-off path; no outcome guarantees; retention with delete on request; backups (units exist, restore drill timer exists, keep them green).

Nimitra (Kala Chakra)#

• What: AI Jyotish and Vastu engine, deterministic rule corpus, LLM prose; Nimitra; Postgres :45067; Gemini Flash Lite. Status: building.
• Users and regions: India primary, diaspora in US and UK.
• Data: P1 birth data, P0 religion and caste where entered, relationship and matching data.
• Modules: M12, M11.
• Regimes: Consumer Protection Act section 2(47), Drugs and Magic Remedies Act, state anti-superstition laws, New York Penal Law 165.35 style statutes (entertainment disclaimer), UK CPUT Regulations Schedule 1, CAP Code, UK GDPR Article 9 for religion, DPDP.
• Red flags: none in code yet; the risk is in copy and upsells.
• Must do: entertainment and reflection positioning by region; safety classes suppressed (death, disease, fertility, marriage veto); no remedy upsell; AI-forward persona; verified rule ids on every claim; explicit consent for religion or caste fields; refund policy for digital readings.

Lakshmi#

• What: internal NSE research and paper-trading engine; RM Orbit/Lakshmi; lakshmi.freedomlabs.in behind auth. Status: internal, build closed.
• Users and regions: company only, India.
• Data: P2 market data, company paper book; Upstox broker hooks.
• Modules: M4.
• Regimes: SEBI Research Analyst and Investment Adviser regulations (if ever external), Upstox API terms, data-vendor licences (exchange data redistribution is licensed).
• Red flags: a public hostname exists; outputs must never leave the company.
• Must do: auth on every route; no sharing of signals; no marketing; data-vendor terms honoured; if productised, SEBI RA registration first.

SafeNet (personal safety alarm and responder network)#

• What: one-tap personal safety alarm for Android. It texts trusted contacts from the user's own SIM, streams live location and optional audio to a tracking page, and shows alarms on an ops console. If the user opts in, it also alerts nearby volunteer responders in rings (500 m to 3 km) until 3 accept. A duress PIN keeps the alarm running while looking stopped. RM Portfolio/safenet; safenet.freedomlabs.in. Status: pre-launch (added 2026-09-30, responder network 2026-10-01).
• Users and regions: India, adults only (18+ gate in onboarding).
• Data: P0 precise location and P0 audio for requesters, only during an alarm. P0 precise location for responders, only while they choose "Available now" or are responding, latest value only. Responder saved areas are stored at about 550 m only. P1 names. Trusted contacts and PIN hashes stay on the phone. The server holds an install id, an encrypted push token (responders only), a consent ledger, write-once incident events, alert records, abuse reports, and an access log.
• Also: trips (deleted when they end), hands-free alarms (power presses, Bluetooth panic button, Wear OS watch, motion check-ins; background location requested only for this), responder coverage from a 500 m point, and phone-move backups encrypted on the phone (the server cannot read them).
• Modules: M5 (recording, law-enforcement requests), M11 (store forms, in-app deletion), M16.
• Regimes: DPDP and SPDI (precise location and recordings), IT Act sections 66E and 72, IT Rules 2021 grievance officer, CERT-In logging, Consumer Protection Act (no rescue claims), Google Play SMS and Call Log policy (emergency alerts exception), foreground service and location policies, Firebase Cloud Messaging terms, Good Samaritan guidelines for responders, BNSS lawful access.
• Red flags: Safety-critical; copy must never promise rescue or that responders will come. A bad actor can join as a responder. Unverified responders see only a 100 m area with a fixed offset, the exact pin goes only to responders verified in person, and every view is logged. Abuse reports could be used to silence a real victim's crowd channel; it takes 2 reporters or 1 verified one, and contacts and ops are never paused. Evidence is write-once and duress incidents are on legal hold, which limits erasure; counsel must confirm. Audio captures third parties. Ops is founder on-call with no 24x7 paging. Backups share the host. Grievance contacts must be filled. "SafeNet" may clash with an existing trademark.
• Must do: Keep per-purpose consents unticked (location, SMS, audio, crowd alerts, responder). Keep push payloads free of location and names. Keep no analytics SDKs; Firebase Analytics stays off. Verify responders in person with an ID check and a recorded note. Complete the DPIA before the first real user. Get counsel review of terms, retention, responder liability, and the law-enforcement request process. The Play Data safety form and declarations must match docs/PLAY_CONSOLE.md exactly. Set up off-box encrypted backups with a tested restore.

Tier 2: communications, content hosting, and identity#

RM Mail#

• What: hosted mail for rmmail.in and client domains; RM Orbit/Mail; mail.freedomlabs.in; inbound via CF Worker, outbound via Resend. Status: live, recently rebuilt.
• Users and regions: company and Orbit users, clients later; global recipients.
• Data: P0 message content, attachments, contacts, automation rules.
• Modules: M5, M16.
• Regimes: IT Rules 2021 (intermediary), DPDP, CERT-In logging, CAN-SPAM and PECR for outbound marketing through the product, Gmail and Yahoo bulk-sender rules, lawful-access requests, UK Online Safety Act only if user-to-user features exist (mail is not U2U in the OSA sense).
• Red flags: history of BCC leaks, lost sends, duplicate mailboxes, RLS bypass (all fixed on the unpushed branch); AI worker triages content; WS previews once leaked cross-tenant.
• Must do: keep RLS with the after_begin hook; AI triage disclosed and off-switchable; retention schedule; law-enforcement policy; SPF, DKIM, DMARC on every hosted domain; one-click unsubscribe for bulk mail sent through us; grievance officer page; breach plan for mailbox compromise.

RM Meet#

• What: video meetings, recording, captions, notes; RM Orbit/Meet; meet.freedomlabs.in. Status: live, P0s open.
• Users and regions: Orbit users and guests, global.
• Data: P0 audio, video, recordings, transcripts, chat; participants' identities.
• Modules: M5, M16.
• Regimes: recording-consent laws by region, UK IPA and GDPR, BIPA if voiceprints, FTC Act (E2EE claim), Online Safety Act (U2U with UK users), COPPA if minors join.
• Red flags: lobby claims "end-to-end encrypted" with no E2EE; no server-side host authorisation; static server path traversal; unauthenticated guest-session endpoint in production; no meeting entity, state in process memory.
• Must do: remove E2EE claim; enforce host roles server-side; fix serve.cjs containment; disable the dev guest endpoint in production; meeting entity with owner and ACL; consent prompt and indicator for recording and captions; recording retention default; rotate and un-commit secrets (done) and apply the hardening flags.

FounderStack#

• What: the founder platform: one agent over one data plane, with capabilities (Atlas, Chronos, Capital Hub, TurboTick, Search, Mail, Ping, Drive, Safe, Sign, Roster, Shakespeare, Cards, Gate and more) rendered as chat tiles that expand into full app views; RM Orbit/FounderStack; founderstack.freedomlabs.in. Status: building, no external tenant yet.
• Users and regions: paying companies and their staff, plus external contacts who never sign up; IN, US, UK, EU. Data is stored in India, so UK and EU tenants need an IDTA or SCCs and the privacy notice must say where the data lives.
• Data: P0 tenant AI provider keys (encrypted at rest, never returned by the API), tenant-issued API keys for the public API (stored as a SHA-256 with a short prefix, never recoverable, redacted from exports, revocable, and never wider than the person who made them), credential-vault metadata, and, once Mail and Ping are built, message content and meeting transcripts. P1 contacts created automatically from meeting attendees and mail headers, and all workspace content. P2 invoices, budgets and contract references. Per-tenant AI usage ledger. Sign (built 2026-09-18): P0 signed documents, signature images and the hash-chained signing audit trail, holding each external signer's name, email, consent and action times, IP and user agent, kept with the signed record for as long as the tenant keeps the document; signing links are capability tokens stored only as hashes. Roster (built 2026-09-18): P1 timesheets, shifts and approval decisions; P2 hourly cost rates with history, readable by the person and admins only. Shakespeare (building from 2026-09-21): P1 motion design scenes, meaning the scene document, its edit history as an op log with the author of each commit, project names, and the brief a person typed; P1 uploaded assets (logos, images and footage), sniffed and capped, stored outside any web root and reachable only with the tenant's own token; rendered frames of a scene, which are sent to the tenant's chosen model as pictures so the agent can judge its own layout; exported media (MP4, GIF, Lottie, stills), kept until the person deletes the scene. Shakespeare workspace assets (2026-09-21): P1 vector drawings a person pasted or uploaded, or the agent drew, kept per tenant with who added them and whether the agent made them; stored only as the engine's own serialization of the geometry it read, never the text that arrived, and kept until deleted. Early access (2026-10-02): P1 email, an optional one-sentence request, a coarse region and the consent record from the Supernatural landing, collected behind an unticked consent box, stored in India, deleted after 12 months untouched or on request; IP addresses are counted for rate limiting and never stored. P1 Reps voice agents (2026-10-08): agent instructions, voices, document scopes; API tools as cURL, whose secret header values (Authorization, keys, tokens, cookies) are Fernet-encrypted apart from the tool and never returned to a browser. P0 live call audio and its transcripts: audio is streamed to the tenant's chosen speech-to-text provider one turn at a time and never stored; the transcript lives in call memory only, except when an agent hands the call to a person, when the last 12 turns, the caller's name and the issue summary are sealed (encrypted at rest) on the handoff row and deleted after the workspace's retention setting (default 30 days, 1 to 365). P0 per-person voice-call consent: who, text version, when, withdrawal time. P1 uploaded documents for agents to answer from: sniffed, capped at 25 MB per file and 200 MB per upload, zip expansion capped, stored outside any web root under Backend/var/reps-store/, erased with the tenant. Accounts (2026-10-10): adding a person mails a one-time set-password link from [email protected]; only a SHA-256 of the link is stored (invite 7 days, reset 1 hour, a reset ends every other session). P1 workspace mail addresses: [email protected], shared with the standalone RM Mail app, which is offered each inbound message first and whose names are reserved, or name@ a workspace's own domain once Resend has verified it (P1 domain, Resend id, DNS records, one workspace per domain). P0 connected mail accounts: IMAP and SMTP host, user name and a Fernet-encrypted password that is never returned, visible to the person who connected it only; new inbox mail is copied in read-only (first sync the last 14 days, at most 200) and kept until deleted; replies leave through the account's own SMTP. Reps (2026-10-10): every call now keeps a sealed transcript that expires with the workspace retention setting, and a wrap-up (summary, qualification, next step) the workspace's own model writes from it; the consent text says so (version 2026-10-10). Website visitors: a random visitor id in their browser and their versioned consent; IPs are counted for rate limits in memory, never stored. Leads a rep saves go into the shared people and org tables as the caller said them. Reps phone (2026-10-11): a workspace connects its own Twilio account (Account SID, API key SID, and the key secret Fernet-encrypted, never returned); Twilio bills the workspace and is its processor for call audio. P0 inbound phone calls: the caller's number (E.164), call audio streamed through Twilio to the kernel and on to the tenant's speech providers one turn at a time and never stored, and the same sealed transcript and wrap-up as a web call. Callers hear a spoken AI notice before the agent answers. Caller numbers are counted in memory for rate limits (5 calls an hour) and a per-number daily cap; the webhook URL is HMAC-signed and the media stream takes a one-time token. Reps live (2026-10-11): voice calls (phone and web) run on one live model, Google Gemini Live (gemini-3.8-live) on the workspace's own Gemini key, in place of separate speech to text, chat and voice providers. Caller audio streams to Google for as long as the model is listening, not one turn at a time, and is never stored by us; the model receives the agent's instructions, its tools, tool results and document excerpts it asks for; the call transcript is the model's own transcription of both sides, sealed as before. A phone menu is read by the same model. The chat model under AI providers now serves only typed chats and the wrap-up. Consent text version 2026-10-11 names Google Gemini and continuous streaming. Bridge CRM (2026-10-11): P1 contacts and companies on the shared person and org tables (name, emails, phones, title, company, LinkedIn URL as typed, city, country, owner, lifecycle, tags, custom fields), deals (amount, stage, close date, won or lost reason, next step), memos, follow-ups and buying-committee roles; added by members, by Blue with a member's yes, or from a CSV a member uploads (5,000 rows, previewed first, duplicates update); reach is by record owner (own, team, all); removing is a soft delete; export needs bridge.transfer. Bridge modules and smart import (2026-10-11): custom module records (whatever record types a workspace defines, with its fields and links); smart import reads CSV, Excel, JSON, YAML or ZIP files from the person's Drive (25 MB each, 60,000 rows), keeps only file ids, column shape and the plan; the workspace's own AI model sees column names, types, fill rates and short-list values (never names, emails, phones or free text), and 20 sample rows per file only when the person ticks the unticked sharing box for that import; samples are never stored. Bridge lead funnels (2026-10-11): leads posted by the public through a workspace's forms and tools (name, email, phone, company, message, UTM, and any consent fields the form sends, stored with the lead); each request kept 30 days in a delivery log for replay, then deleted; secret funnel keys stored as SHA-256 only, publishable keys locked to listed origins; an Apollo key a workspace brings is Fernet-encrypted; honeypot, per-IP and per-funnel rate limits, daily cap. Bridge products on deals (2026-10-11): P1 purchase history, meaning the products on a deal (name, quantity, unit price, discount) and, read from won deals, what each person or company bought and who bought each product; a one-step sale is an ordinary won deal, so nothing about a buyer is stored outside the deal and its people links, and erasing a person takes their bought list with those links. Links (2026-10-11): one row per link between any two objects (both ids and types, a label, small fields such as a role, who made it); no copy of either side is kept. What a link shows is read live from the owning app through that app's own visibility rule (Drive personal files stay their owner's, Mail threads stay with their mailbox, Sign by sender), so a person never sees through a link what the app itself would hide: they see only that something is there. Files uploaded from a record go to the team drive. Matched panels (2026-10-11): a record also shows, without anyone linking them, mails with its people (envelope only: subject, sender, count; read through the reader's own and shared mailboxes, so another person's mail never shows), invoices for its company, meetings, tickets, agreements its people sign, and Reps calls with its people (the wrap-up summary, never the transcript); nothing is copied, each is read live from its app. Layouts per kind of record are workspace settings. A link intent (made in another app from a record) holds two ids and expires in an hour. Mail sent from a record goes through Mail's own send path. Blue charts and pictures (2026-10-11): a chart is drawn from a result Blue already fetched in the conversation and holds no new data. A picture sends the person's description, nothing else, to the workspace's own image model, only after the person confirms; the PNG is saved in their own Drive under Blue images, tagged AI generated with the model's name, kept until they delete it, and shown in the chat with an AI generated label through a ten-minute Drive link. Query layer (2026-10-11): Blue answers questions with read-only SQL over views in schema q (deals, people, companies, module records, mail, meetings, invoices, payments, customers, files, tickets, tasks, projects, agreements, signers). Each view applies the owning app's own visibility for the asking person (record scope, mailbox membership, personal Drive files) from a context the kernel signs per question; questions run as a login that can read only those views, read-only, 5 seconds, 500 rows, always rolled back. No secret or sealed column is in any view (passwords, keys, link and signing hashes, signature images, locked notes, transcripts, invite tokens, signer IP and user agent). Rows Blue reads, mail bodies included for mailboxes the person can open, go to the workspace's own chat model like any tool result. Calls meet the CRM (2026-10-11): an inbound phone call's number is matched to a Bridge contact or member the moment it connects (numbers stored as E.164), and a number nobody has becomes a contact named by the number; the agent is briefed with what its owner may see about that person (company, open deals and tickets, the last call's wrap-up), so those facts go to the workspace's voice and chat model for the call; the agent is told caller ID can be faked and to disclose or act on account details only after the caller confirms who they are. A handoff carries the person id, and the operator's screen reads the record through the operator's own access. Scribe in the suite (2026-10-13): an author profile per person (headline, field, audience, goals, voice samples they pasted), their posts from draft to published, and from the quality slice: verified facts about the author, sentences they said are untrue of them, and an identity anchor in their own words. The anchor can hold the author's work-authorisation status and sponsoring employer, which is sensitive personal data: it is typed by the author about themselves, visible to that author only, and can be cleared. Drafts, the author block and each check (hook, critic, claims, integrity) go to the workspace's own chat model; up to nine calls per draft, capped per author per day. Scribe, the rest (2026-10-13): P0 each author's own LinkedIn access and refresh tokens and a company account's tokens, sealed at rest, never returned, revocable by disconnecting; P1 the member id and display name LinkedIn returns. P1 results the author uploads from their own LinkedIn export (per-post numbers, follower counts, aggregate audience shares). P1 about people who never signed up: authors of posts the author pasted to comment on and people who commented on theirs (name, headline, profile link as typed, the pasted text), watched people, connection suggestions, rivals (name and link, nothing fetched), boost squad members (name, email) and newsletter readers (email, name, the consent statement with its time and how they were added, an unsubscribe token hash). P1 the author's interview answers and stories about their working life, which may name an employer; a story reaches the writer only after the author verifies it, and is the author's alone. A profile picture, re-encoded with its metadata removed, served at a signed address. Stored AI output: strategy analyses, briefings, week reviews, ideas. Public blog pages a workspace publishes (author name, article, an AI-assistance line when a person did not edit it), marked not to be indexed. Ping chat AI (2026-10-14): catch-up, thread summaries, translation, decision scanning and Blue's help in chat no longer run on a model on this machine (it was removed). The recent messages of the open, non-private conversation (up to 150, trimmed to 9,000 characters) go to the workspace's own AI provider when a person asks; a private, end-to-end encrypted conversation is still never read. TurboTick customer page (built 2026-10-14, off until a workspace manager turns it on): P1 name, email address and request text typed by a person outside the workspace into a public form, their later replies, and a 1 to 5 rating with an optional note; a contact is created from the address; the form names who receives it and says it is stored in India; desk and ticket links are capability tokens stored only as hashes; an optional notice email to the requester on a public staff reply goes through Mail's relay and carries a link, not the reply; submitting the form sends no email. Workspace security (built 2026-10-14, kernel app/security): P1 sign-in records per device (network address, browser, times) and every sign-in and failed sign-in on the append-only event record; P0 two-step secrets (encrypted) and recovery codes (hashed); P0 single sign-on client secret (encrypted); SCIM token (hashed, shown once). Admins read their own workspace's audit trail only; audit-trail retention is not yet enforced. Calls from Bridge (2026-10-16): a member with the Make calls permission (reps.calls.dial, granted by an admin) calls a contact from the workspace's Twilio number, by hand, from the contact's record; the browser must be on the call within ten seconds or it is hung up, so nothing rings without a person. P0 call audio both ways: relayed through the kernel, recorded as a stereo WAV (the other side left, the member right), Fernet-encrypted at rest under Backend/var/reps-store/recordings, kept for the workspace's transcript retention (default 30 days) and deleted with it; the recording is heard only by the member who made the call and roles with reps.transcripts.read. The transcript is made after the call on this server by the local Whisper service Meet uses (the audio does not leave the machine for it), sealed like other call transcripts; the wrap-up is written from the transcript by the workspace's own chat model. P1 the number dialled (E.164) and who called it. Before anything is kept the other side hears a spoken notice that the call from the workspace is recorded and transcribed; the member sees a Recording mark for as long as it is. A contact tagged do not call (or dnc) is refused at the dial path. Champagne (campaigns, 2026-10-16): sequences and broadcasts to Bridge contacts, sent as ordinary mail from mailboxes the workspace chooses (a member's own or a shared mailbox they belong to; never someone else's), through Mail's own delivery, so they sit in Sent and replies thread back. P1 the consent register: append-only rows per address and person, channel (email, phone, SMS) and purpose (sales, marketing), status (granted, withdrawn, objected), basis, wording version, source, who recorded it and when; kept for the life of the workspace as the evidence of consent. P1 enrolments (who is in which sequence, step, state, the reason it waits or stopped), touches (sent, held, replied with the reply's kind, bounced, unsubscribed) and broadcast recipients; audiences are filters over Bridge or lists of person ids, resolved through the author's own Bridge reach. Every campaign mail carries the company name, a postal address and an unsubscribe link, plus List-Unsubscribe and List-Unsubscribe-Post (RFC 8058); the link is an HMAC-signed token (nothing stored), GET changes nothing, POST withdraws both purposes, suppresses the address in Mail's list and stops every enrolment. Before each step the kernel reads, inside the same workspace, recent inbound mail and Reps calls with the person, their urgent tickets, agreements out for their signature, overdue invoices for their company, meetings with them and late-stage deals, to hold the step; nothing is copied. AI: the workspace's own chat model drafts sequences from a brief (the brief only), personalises one email from the template and these Bridge fields only (name, company, title, city, lifecycle, sender name), and sorts replies (the reply's subject and up to 3,000 characters of its body); a personalised email waits for a person's yes unless the sequence owner chose otherwise, and anything flagged (a number, link or address not in the template or the record) always waits. An AI call step hands the person to a Reps agent from the workspace number only with a recorded phone consent, never to Indian numbers. Designer (design studio, 2026-10-16): the workspace brand kit (name, colours, fonts, logos, a line on its voice); pictures members upload (re-encoded, metadata stripped), make with the workspace image model (the prompt kept, labelled AI with the model, a real person's likeness refused in the prompt) or cut out on this server (background removal runs locally, no provider); designs and their exports (into the member's own Drive, and kept as images for email; an export that contains an AI picture is tagged so); fonts the workspace uploads, accepted only with a licence statement recorded with who uploaded it. Pictures and fonts are served at signed, unguessable addresses so emails can show them; a removed picture leaves the library but still draws where it is already used, including sent emails. Words from a brief and drafting a design send the brief and the brand voice to the workspace chat model; lettering sends only the words and the style to the image model. Designed campaign emails (2026-10-16): blocks rendered to email-safe HTML with a plain-text copy of the same words; a raw HTML block is cleaned with nh3 (no scripts, forms, frames or event handlers); pictures load from Designer's signed addresses, with no tracking pixel and no open tracking; the footer with company, postal address and unsubscribe is added by the send path, never by a design. Designer outside pictures and 3D (2026-10-16): stock photos (Openverse public domain; Unsplash and Pexels when keys are set), GIFs and stickers (GIPHY) and 3D models (Poly Haven, CC0) are hotlinked, never stored: a design keeps the address and the credit; the kernel sends only the search words to the provider, but a viewer's browser loads the picture or model from the provider, so the provider sees that viewer's IP address and user agent (also when a designed email shows one). Workspaces may upload their own 3D models (.glb, checked to be glTF 2.0, up to 30 MB, kept like pictures, signed addresses). DevStudio discovery (2026-10-17): a brief per app project (audience, journey flowchart, screens, integrations, template and look, builder-written mock-ups and example customer messages) and each person's stated comfort with code; things attached to the chat from Drive or any app are linked to the project and their contents, which can include contacts' personal data, are sent with the conversation to the founder's own coding tool provider. Integrations (building from 2026-10-18, kernel app/integrations, migrations 0175 and 0176, not offered to tenants yet): an org admin connects outside software to the workspace (HubSpot for the CRM; Google mail, calendar and files). P0 the connection's credential: OAuth access and refresh tokens or an API key, Fernet-encrypted at rest, never returned to a browser, never logged, read only by the code that calls that provider; every store, use, refresh and removal is written to an append-only credential audit with a plain purpose; removing a connection revokes it at the provider where the provider allows and deletes the credential. Sign-in state is single-use, signed, bound to the person and browser, and expires in minutes. Routes (2026-10-18): for providers whose sign-in waits on our app being approved, a customer may connect with a personal key made in their own settings (kept in the same vault as any key), or bring data over once from the export file their product gives them, read from the admin's own Drive with only the mapped columns kept and nothing logged. Google Takeout and Gmail with an app password copy a whole mailbox into Mail. Beta workspaces (2026-10-19, built, not open): the first 100 companies, up to 25 people each, no clock, sign-up by email code recording the beta terms version, an 18-or-older business declaration and a region tag; each brings its own AI provider key, so content goes to the customer's own provider. Release variables (DevStudio): per-environment values and secrets, encrypted and never read back, and links that read workspace data as the admin who made them. The beta is by invitation: single-use invite codes (admin-only, keyed hash, kept encrypted for re-sending); each early-access request is also mailed to the team mailbox through Resend in the US, as the early-access privacy notice (ea-2026-10-19) says. P1 records copied both ways between the provider and the workspace's own apps (Bridge companies, contacts, deals and notes; Chronos calendars and events; Drive folders and files, and in a migration their bytes; mail threads and received messages, read only, into a mailbox of the connection's own, never a person's personal mailbox), written through each app's own functions with the connecting admin's own reach, never an integration key. Each pairing keeps both ids and a hash of each side, not the content; a pairing waiting for a person keeps a snapshot of the outside record without what the domain marks sensitive (a message's words). Deletions are mirrored only when the admin turns that on; copies already made stay when a connection is removed. Calendar writes never email guests. Outbound calls reach only each provider's listed hosts. Each provider is a processor the workspace chose. Test accounts (built 2026-10-18, kernel app/onboarding, migration 0177, sign-up shut unless FS_TEST_SIGNUP=1): a self sign-up with an email code (signed challenge, keyed hash of the code, 5 tries, 10 minutes, rate-limited per email and IP). P1 a guard table kept outside any workspace and readable only by the admin connection: an HMAC of the email (never the address), the company domain, when the account started and was deleted, so one test account per email and per company domain and a 90-day cooldown after deletion can be enforced. P1 extension requests: the reason typed, and a usage summary (people, people active in 7 days, apps used, AI spend, days left), sent as a ticket into Supernatural's own workspace once it exists. Retention: 15 days, then 7 days read-only with export open, then deletion (built off: until FS_TEST_ACCOUNT_DELETE=1 it only writes a report of what it would delete); notices on day 10 and 13 in the app and by email to every member with the real dates; AI receipts kept after deletion with no content and no person, for a period still to be set per tax law; one audit line; backups age out. App gateway (built 2026-10-18, kernel app/integrations/gateway, migration 0178): apps a workspace builds in DevStudio call its connections through narrow app tokens (SHA-256 and a prefix, shown once or installed encrypted into the project's vault, revocable, per-minute and per-day limits), granted only by an org admin as named domain operations; a call log of ids, operation, status and duration, never content or a token.
• Modules: M4 (invoices and ledgers), M5 (mail, chat, meetings, file sharing), M6 (generated media, for Shakespeare), M7 (e-signature and evidence), M9 (hosting other companies' data), M16 (identity and secrets).
• Regimes: DPDP Act 2023 and Rules 2025, GDPR and UK GDPR with transfer tools, FTC Act section 5, CAN-SPAM and PECR, ESIGN, UETA, UK eIDAS simple signatures, IT Act 2000 section 10A with First Schedule exclusions, and BSA 2023 section 63 for any evidence export (Sign is built: a simple electronic signature with a hash chain and an RFC 3161 anchor, not an Aadhaar eSign or DSC), GST and UK/EU VAT, CERT-In directions including 180-day logs, EU AI Act Article 50 disclosure. For Shakespeare's generated video: copyright, right of publicity and synthetic-media disclosure (YouTube altered-content disclosure, Meta AI labels, India synthetic-media rules, Tennessee ELVIS Act), and the SIL Open Font License for the fonts it bundles. Shakespeare's bundled illustration library is Microsoft Fluent Emoji (flat set, via fluentui-emoji 1.3.0) under the MIT licence, which passes no attribution or share-alike duty to a customer's export; the licence text ships with the product.
• AI: BYOK per tenant, set by an org admin for the whole workspace. Any OpenAI-compatible endpoint including a self-hosted vLLM, plus Anthropic, OpenAI, Gemini, Bedrock, Azure and OpenRouter. Local Ollama is the default and the default embedder, so the product works with no key at all. This is an approved exception to the local-only standard, because the tenant chooses and pays for the provider; there is no RM-paid key anywhere in the product, and an unconfigured workspace gets an honest error rather than a silent downgrade.
• Red flags: multi-tenant isolation is the entire product, so every table needs forced row-level security and a tenant policy, verified rather than assumed. Tenant data leaves the deployment to whichever provider that tenant configured, so the egress has to be disclosed per role rather than described once in general terms. Contacts are created from mail headers and meeting attendees, which means holding personal data about people who never signed up. The agent can act on a person's behalf, so the actor shown on outbound artefacts must be configurable and always recorded. Two product laws are load-bearing and must not be weakened: money only moves behind an executed contract (Law 5), and an automated message must not land on a thread a person is actively working (Law 6). Shakespeare shows the tenant's chosen model rendered frames of an ad, which carry the customer's logo and unreleased creative, so the egress page must name frames for the director role. A font embedded in a Lottie or SVG export is redistributed, so an uploaded font needs an embedding licence the product cannot verify. An uploaded SVG can carry script, so it is sanitised or rasterised and never served inline from the app origin. Shakespeare imports SVG, which is markup somebody else wrote: scripts, links, images, foreign content and styles are never read, a drawing that needs them is refused by name, and nothing from a file is ever placed in a page as markup. Connected IMAP accounts copy a person's outside mailbox, including third parties' messages, into the platform; servers are reached only at checked public addresses, over TLS. rmmail.in is shared with RM Mail: a mailbox RM Mail creates later under a name Supernatural already gave out would take that person's inbound mail. Reps takes calls from the public through a website button (an AI notice and an unticked consent box before anything is sent; a publishable key bound to one agent, listed origins, the live version and a daily cap), and mails recap emails to callers on its own through Mail.
• Must do: update this entry before the first external tenant; a provider-egress page naming which data goes to which provider for which role; consent ledger and shared suppression list enforced at the send path; tenant export and delete-tenant that emits a deletion event; recording and transcript consent before Ping ships; per-tenant Resend sending-domain verification before Mail ships; nightly Postgres backups with a tested restore before the first tenant; DPA template and a sub-processor page that reflects each tenant's chosen AI providers; no per-token billing to customers, internal metering only; an API key is never stored or logged in clear and is shown exactly once; the developer site at developer.freedomlabs.in carries security.txt, sets no cookies and no analytics, and claims only encrypted in transit and at rest; MCP on a public hostname authenticates with an API key and never falls back to the dev environment identifiers. For Shakespeare: ship only fonts under an open licence that permits embedding, and no font upload, until a font-licence attestation exists; exports carry provenance metadata saying the piece was made with AI assistance, and a visible AI label once any generated image, audio or video source is added; never clone a real person's voice or likeness, and add no generative voice or face source without written consent on file; deleting a scene or its tenant takes the uploaded assets and the rendered files off disk, not only their rows; scene ops from the model are validated against the typed op schema before they touch a document, and model output is never executed or rendered unsanitised. Shakespeare's asset library stays on licences that put no duty on the customer's output (MIT, ISC, Apache-2.0, OFL), with no CC BY-SA or attribution-required art, and its index records set, licence and source; SVG upload and paste shipped 2026-09-21: every drawing goes through the whitelist importer with a 300 KB cap, is refused by name when it needs anything unread, and only the engine's own re-serialization is stored, served or shown, with thumbnails rendered as images and never as inline markup; an asset the agent drew is recorded as made by the agent and labelled AI in the library. Shakespeare asset_imagine (2026-09-22) sends the person's description and the scene's palette to the tenant's own image model; the picture is traced to vector shapes and only that serialization is stored; the asset is recorded as made by that model and labelled AI; the provider egress page must name asset descriptions for the image role; reps: a voice call starts only after the person ticks an unticked, versioned consent; the socket closes with 4409 without it, and the consent is withdrawable in the app; reps: every voice agent is told it is an AI and must say so when asked (EU AI Act Article 50); never write instructions that make one claim to be human; reps: stages are API providers only (Gemini, OpenAI, Groq, OpenRouter) from Settings, Voice; the egress page must name call audio (speech to text), transcript plus instructions plus document excerpts (chat model) and reply text (text to speech) per provider; reps: API tools run from the kernel, so they reach public addresses only (checked after DNS, no redirects); secret headers are encrypted and masked on every read; reps: no malware scan on document upload yet; add one before an external tenant uploads; reps: calls placed to the public over phone lines would bring TCPA, two-party recording consent and caller-ID rules; today Reps runs only in the browser for workspace members, and a telephony channel needs this entry updated first. Accounts and mail (2026-10-10): the privacy notice names connected mail accounts, what is copied, how long it is kept, and that disconnecting forgets the password; RM Mail checks Supernatural's names before creating an rmmail.in mailbox, or FS_MAIL_RESERVED_LOCALS is kept in sync; Gmail or Microsoft OAuth for connected accounts only after Google restricted-scope verification (CASA) and Microsoft publisher verification; own-domain receiving only with the Resend webhook secret set and the egress page naming Resend for inbound mail. Reps (2026-10-10): outbound AI calls only to people with recorded prior express consent, never to suppressed numbers, not to DND-registered Indian numbers, and this entry updated before any phone channel goes live; any site carrying the Reps button needs a privacy notice naming the providers that hear the call and how long the transcript is kept. Reps phone (2026-10-11): inbound only; the spoken notice must also name that a transcript is kept and how to stop (hang up), and a phone caller cannot tick a box, so staying on the line after the notice is the consent and the call record says so; before taking calls from two-party-consent US states or the EU, decide whether to ask for a spoken yes; the egress page names Twilio for call audio and caller numbers; outbound stays off until prior express consent, suppression and India DND are enforced at the dial path. Reps live (2026-10-11): the egress page names Google (Gemini Live) for call audio, transcripts, agent instructions, tool results and document excerpts; a workspace's Gemini key must be on Google's paid tier before real callers, because on the unpaid tier Google may use prompts and responses to improve its products. Bridge (2026-10-11): contacts are people who never signed up, so the privacy notice names the CRM and its sources, and erasure of a person must clear their Bridge profile, committee links, memos and follow-ups on them, not only the person row, and must purge soft-deleted rows; a workspace that imports a bought list attests a lawful basis before the import button is offered to external tenants; LinkedIn stays a URL a person typed, never fetched or scraped; enrichment only through a provider key the workspace brings, under that provider's terms. Bridge smart import: the egress page names the AI provider as receiving column shape for import planning, and sample rows when the person shares them; module fields can hold anything a workspace defines, so the P-class of a module is the workspace's to declare (DPA note). Bridge funnels: a workspace's form must carry its own privacy notice and consent wording (Bridge stores what it sends, it does not show one); TCPA, PECR, DPDP consent is the workspace's to collect before any call or marketing mail to a funnel lead; Meta and LinkedIn lead forms come through Zapier or Make under those platforms' terms, never scraped. Blue pictures (2026-10-11): the egress page names picture descriptions for the image role; the tool refuses a real person's likeness by instruction, and the provider's own policy is the second check; an image leaving Drive keeps its AI generated tag. Query layer: the egress page names query results (including mail bodies from the person's own mailboxes) for the chat model role; a new view ships only with a test that it shows each person exactly what the app does, and never a sealed or secret column; the fs_query password derives from FS_SECRET_KEY, so rotating that key rotates it. Calls meet the CRM: the privacy notice says calls are matched to the CRM by number and that a new number becomes a contact (no extra spoken notice, by the founder's decision 2026-10-11); the egress page names CRM facts about the caller for the voice and chat model roles; erasure of a person must also clear the person id on handoffs. Scribe: the egress page names author profile, verified facts, the identity anchor (including work-authorisation status when the author entered it) and post text for the drafting and scoring roles; nothing is posted outward without a person's yes until the publishing slice has its own entry; AI-drafted posts are reviewed by a person before going out and the integrity verdict is advisory, never a legal clearance; erasure of a person clears their Scribe profile, posts, samples, facts and anchor. Scribe, the rest (2026-10-13): posting to LinkedIn only through official APIs with the author's own token, never scraping, search-engine harvesting or a browser extension, and nothing reads LinkedIn; a person approves every post before it goes out, autopilot only writes drafts into review and is off until the author turns it on for themselves; a post is claimed before it is sent and never retried by itself, so nothing posts twice; a company post goes out by itself only when that account's own switch is on and the integrity verdict is safe; the egress page names interview answers, stories, pasted third-party posts and comments, feed items and queue facts for the drafting role; feeds are fetched only from public https addresses the author lists, checked against private addresses on every hop; newsletter sending to readers stays off (fs_scribe_letters_on) until there is a separate marketing mail stream, region-aware consent and a postal line, and unsubscribe is a confirm page with a POST; boost squad mail goes only through Mail's own send path, to addresses the workspace's outside-mail policy allows, once per member per post, with a reason and a stop link, and a consent record for members is owed before an external tenant uses it; the public blog needs privacy, terms and a takedown path before it is indexed or offered to an external tenant, and never prints an admin's email; no malware scan on document or PDF upload yet; the reach rules' cited sources are carried from the original and unverified, so verify or strip them before an external tenant (red line 10); erasure of a person clears their LinkedIn tokens, results, stories, readers, squad, comment queue, pictures on disk and public pages; retention for imported results and for readers who unsubscribed is still to be set. Ping chat AI (2026-10-14): the egress page names chat message text for the workspace's chat model; no screen may say messages stay on this server or that the model is local; the privacy notice says conversation text is sent to the workspace's provider when AI features are used. Calls from Bridge (2026-10-16): before an external tenant uses it, decide with counsel whether the spoken recording notice (Twilio text-to-speech) counts as an artificial voice under the TCPA for calls to US mobiles, and whether staying on after the notice is enough consent in two-party-consent US states and the EU or a spoken yes is needed; telemarketing calls must be checked against the US National Do Not Call Registry and India's NCPR (DND) at the dial path, which today only honours a do-not-call tag; a phone suppression list with opt-out capture is owed; the egress page names Twilio for outbound call audio and dialled numbers; the privacy notice says calls from the workspace are recorded and transcribed and for how long; erasure of a person must delete their call recordings, not only the rows. Champagne (2026-10-16): the privacy notice names campaign mail, the consent register, reply sorting by the workspace's model, and the checks across apps before each step; the egress page names reply text, briefs and the personalisation fields for the chat model role; a workspace sending campaigns uses a domain it verified, not rmmail.in (M10); erasure of a person deletes their enrolments, touches, recipients and reviews but keeps consent withdrawals and the suppression as the record of their objection (counsel to confirm the retention basis); the region table (US opt-out; UK and EU sales on legitimate interest, marketing on consent or soft opt-in; India, Canada and unknown on consent) needs counsel sign-off before an external tenant; CASL and the US state telemarketing rules are not modelled beyond consent; SMS steps are not built and need DLT templates (India) and TCPA consent with STOP (US) before they are; Designer: a takedown that stops a picture drawing everywhere, sent emails included (removal today only leaves the library), and terms that make a workspace uploading a font warrant its licence; Designer: name Openverse/StockSnap, Unsplash, Pexels, GIPHY and Poly Haven on the sub-processor page as services a viewer's browser contacts directly; keep the photographer credit with every hotlinked photo. DevStudio: name in the privacy notice that a project's chat, brief and attached records go to the founder's own coding tool provider; export and erasure walk studio_brief, studio_person and message refs. Integrations: a register line per provider before it is offered; Takeout and Gmail app-password imports say whose mailbox is copied and need that person's consent when it is not the admin's own; before the beta opens (FS_BETA_SIGNUP=1): reviewed beta terms and a privacy notice section for beta workspaces published (drafts in FounderStack/legal-drafts/), a DPA for business customers, the India grievance officer page; Google verification and the security assessment for its restricted scopes (Gmail read, Drive read) before any public tenant connects them; each provider named on the provider-egress page with its DPA; the undo log must not capture the credential audit or sign-in state tables; the remove confirmation says copies already made stay. Test accounts: a terms page before FS_TEST_SIGNUP is set; the AI receipt retention period per region; the backup window in the deletion notice; an approved exception before any RM-paid model key serves test accounts (FS_TEST_ACCOUNT_AI_*), since the entry says no RM-paid key; the shared Resend cap (100 a day) before opening sign-up. App gateway: purge the call log after 180 days; the workspace network allowlist does not yet apply to app tokens.

Shakespeare Cinema Library addition (2026-10-20)#

• Status: implemented and tested locally inside FounderStack. Production migration was not applied by this change. No launch or human content approval is implied.
• Data map: P1 bibliographic URLs, creator credits, region/language/period/medium, self-declared rights and restrictions, review state, observation evidence, creative notes and technique links in shakespeare_cinema_entry.content; existing tenant, owner and optional project identifiers plus version/timestamps identify and file each entry. Purpose: private creative research and studies. Location: existing India PostgreSQL. Forced tenant RLS plus strict owner/project checks. No added field-level encryption. No sensitive personal data, credentials, signed private links or confidential third-party work should be entered; the form says so. Full field map in FounderStack/docs/shakespeare-cinema.md.
• Retention and rights: entry until explicit hard deletion or tenant erasure; owner export of currently accessible entries; existing privileged tenant export/erasure includes the table. Earlier Blue plans/chats, downloaded exports and backups are separate copies under existing retention. Project access loss hides rather than deletes notes. No private localStorage, IndexedDB or offline-cache fallback. Audit events contain identifiers/version, not note bodies or URLs.
• AI/content: M6, M5 and M16 apply within the existing module list. Bundled technique text is original AI-assisted instruction, explicitly unreviewed by practitioners. Institution links are reference-only research starting points, not verified supporting citations or licences. Three original geometric studies demonstrate visual principles without source footage. No scraping, uploads, embedded media, automatic URL fetches, new providers or runtime Cinema model calls. Existing Blue may send retrieved notes and proposed writes to the tenant-selected BYOK provider when asked; the UI discloses it. Clicking an external link visits that site's own service.
• Controls: authenticated routes, owner/project authorization, forced RLS, version conflicts, export/deletion, no-store and private audit redaction tested. Per-process tenant/actor limits are 120 reads, 30 writes and 6 exports per rolling minute, reset by worker restart; not deployment-wide limits. Rights and observation assertions remain user-declared, never independently verified by the product.
• Before external activation: apply the reviewed migration through normal release operations with backup; verify multi-worker ingress limits and retention of plans/chats/backups; name a human owner; practitioner and copyright review of the catalog; security/flow/claims and screen-reader review. This addition preserves FounderStack's existing status, regional requirements and BYOK exception. No compliance certification is claimed.

Sharing outside the workspace addition (2026-10-28)#

• Status: built and tested locally (migrations 0207 and 0208, capabilities/share); not live until the kernel restarts. Plan: RM Orbit/FounderStack/SHARING_PLAN.md.
• What it does: a member with the "Share outside the workspace" permission makes a link to one document, sheet, deck, Drive file, design or film. A view link shows the app's own export (PDF, picture, video). A comment or edit link (Word, Matrix, Present; edit for Designer) opens that one record in its app for the guest, and nothing else; an edit link to a Drive file lets the guest upload a new version, virus scanned. Links last 7 days by default, can be revoked at once, and all stop when an admin turns the workspace switch off or when their maker loses access to the record. The switch also stops Present's, Charts' and Chalkboard's own links. Designer and Shakespeare now keep version history (migration 0208), so a guest's change can be undone.
• Data map: P1 share_guest.name, share_guest.email (asked before opening by default; the sharer can turn the asking off), first_seen, last_seen, opens, edits. Purpose: the sharer sees who opened and changed what, and a guest's comments and versions are attributed to them. share_link keeps only a SHA-256 of the token, never the token. Guests' comments and version rows in Word, Matrix, Present and Designer, and file versions in Drive, carry their shg_ id. A guest gets no AI, no workspace library, no search and no Blue, so no guest content goes to an AI provider.
• Controls: the visitor page is noindex and no-store, rate limited to 60 requests a minute per address, and changes nothing on a GET. Content needs a signed 12-hour pass from the form, so the name and email cannot be skipped. A guest's token has its own issuer that no member route accepts; every request re-checks the link and an allowlist of routes for that one record. Drive files that could run a script (HTML, SVG) are only ever a sandboxed download. Tests: Backend/tests/test_share_links.py.
• Retention: a guest's name and email are cleared 30 days after their link stops working (revoked or run out), by a kernel clock every 6 hours (share/service.purge); the counts stay and their comments and versions read "A guest". A link with no end keeps its guests while it works.
• Rights: an admin finds what a guest left by their email and erases it (Blue tools share.guestbook, share.guestbook_forget); erasing a contact in Bridge clears them as a guest too. The page a link opens says what is kept, for whom, for how long, how to ask (the sharer, or [email protected]) and the right to complain; no AI reads it and no tracking cookies are set.
• Notice and action: every link page has "Report this link", a mail to [email protected] naming the link id (never its token). A human reads it; there is no in-product queue yet.
• Before external activation: a named person who answers [email protected] reports within the DSA's timelines; the Supernatural privacy notice (today only for early access) covers guests.

Legal reads the business (2026-10-28)#

• Status: built and tested locally (Legal migration 0210 after 0209); not live until the kernel restarts. Plan: RM Orbit/_builds/legal/source/LEGAL_PLAN.md, "The redesign".
• What it reads: as the person, never wider: names of the Drive files they can open and the first 3 pages of those that are PDFs; subject and body of inbound mail in their own and shared mailboxes that names a registry or tax term; completed Sign envelopes; Capital customers' billing addresses. On this server with pypdf and pattern matching. No AI, nothing leaves the workspace.
• Data map: P1 legal_record: the proposal, its title, the source's name and id, and an evidence snippet of up to 400 characters around what was found (it can quote a mail). P0/P1 tax and registry numbers (EIN, PAN, TAN, GSTIN, CIN, UK company number, UTR, VAT) once accepted, on legal_company.identifiers. legal_fact_log.source records which record an answer was read from. legal_matter holds a raise's investor, amount and terms, or a hire's name, start date and country. Kept until the workspace deletes them or is erased.
• Controls: an identifier is read only with its label within 200 characters. Every finding waits for a yes or no; a no is never proposed again. Equity papers and raise matters need "See the cap table". A binder section shared outside sends a guest's upload to "What Legal found", never straight into the binder.
• Before external activation: the privacy notice says Legal reads the person's own Drive and mail for registry and tax documents; evidence snippets are included in rights export and erasure; retention for dismissed findings is decided.

Search: Reps calls, Mail's about filter, vectors kept once (2026-10-28)#

• Status: committed; live after the kernel restart (migration 0212_search_vec_only).
• Data map: search_doc now holds a Reps call when it ends: the caller's label (a name or a number), the outcome and the direction, never the transcript. Words only: a call is in UNEMBEDDED, so no caller label goes to an embedding provider. Visible to people with Reps' read permission, the app's own rule. The event log gains reps.call_ended with the outcome, length and channel.
• Vectors: for the embedding models pgvector indexes (Gemini, OpenAI 3-small, nomic), a vector is now stored once, as its half-precision copy; the full-precision JSON copy is dropped (about 1.8 GB on the live database). Nothing new leaves the server: Mail's "about" filter is scored in Postgres from the stored copies instead of in Python.
• Erasure: erasing a call or a mail removes its index row as before; dumps no longer carry a second copy of each vector.

Talking to Blue: dictation and voice calls (2026-10-28)#

• Status: committed; live after the kernel restart (app/agent/voice.py, routes under /capi/blue/voice).
• What it does: in the chat box, Dictate records speech and returns the text to the box; Talk opens a voice call with Blue on the workspace's live voice model (Gemini Live, as Reps), which hands every real request to Blue as an ordinary chat turn.
• Data map: audio (P0 recording) is streamed to the workspace's own provider (Gemini, OpenAI or Groq for dictation; Gemini Live for calls) and never stored by us. What is kept is the chat: the person's words as their message and Blue's answer, as for typed chat. Usage rows voice.dictation and voice.live in the ledger (tokens and cost, no content).
• Controls: the call panel is the visible indicator while the mic is live and names the provider; mute and end are one tap; the browser's own mic permission applies. The socket accepts only the shell's signed session, and the person's role must include chat. Calls end after 30 minutes. Blue's voice says it is an AI when asked; a plan still needs an explicit yes, by voice or button.
• Before external activation: the provider-egress page names call audio and dictation audio for the voice role; a workspace's Gemini key must be on Google's paid tier (as for Reps live); the privacy notice says voice is processed by the workspace's provider and not recorded.

Capital: quotes, payment links, time into invoices, weekly repeats, paid-on-the-spot sales; Reps booking on the call (2026-10-28)#

• Status: committed; live after the kernel restart at migration 0216 (paid-on-the-spot sales need no migration). Demo workspace only, no outside tenant.
• Quotes (capital/quotes.py, table capital_quote, forced RLS): number (Q- series, apart from invoices), customer, lines, tax and totals computed by the kernel, valid-until day, state, who drafted it. Never counted as money owed. Sent for acceptance, the quote PDF goes to Sign as a draft envelope with the customer as signer (their name and billing email, P1, kept by Sign with its audit trail as for any envelope). A signed quote is the executed contract its invoice is issued against.
• Payment link (capital_settings.pay_link): a workspace's own https link template; the kernel fills in the amount, currency, invoice number and reference and prints it on the invoice, its PDF and its mail. We never touch the money, see card data or route funds (red line 3): the customer pays the workspace's own provider. A Stripe Checkout connection is not built.
• Time into invoices (Atlas rate_minor, rate_currency, client_org_id on a project; billable, invoice_id on a time entry): a project's unbilled billable time is drafted as one invoice line per task. Only someone who can open the project in Atlas and holds Capital's write permission can do it. Billed hours name their invoice and cannot be billed twice; discarding the draft frees them. Per-person time entries already existed; nothing new is collected about people.
• Weekly and fortnightly repeating invoices: a wider check constraint only; repeats still issue themselves only against a signed contract.
• Law 5 exception, paid on the spot (invoices.issue_paid): a draft can be issued and paid in one step with no contract, for a sale paid in full as it is made (a walk-in, a job paid at the counter). It bills no one, so the rule's purpose holds. It cannot become owed: voiding its payment issues a credit note that cancels it. It needs both the issue and the record-payments permissions; a draft with no customer is allowed only when marked walk-in, and that draft can be issued no other way. Same gapless invoice series, so tax records stay consecutive.
• Reps booking on the call (reps/booking.py, agent field may_book, off by default): with the owner's switch on, an agent offers the owner's free times inside the workspace's working days and hours (two hours ahead at least) and books one as a Meet meeting in the owner's calendar, through Meet's own scheduling as the owner, so the owner's permissions apply. Data: the caller's name and email as they say them on the call (P1), the meeting title from what the call is about, the agenda line "Booked on a call by ". The invite goes by email to the address the caller gave and spelled back (transactional, one per call). No text messages. The AI books only a time the caller chose, rechecked free at that moment; it decides nothing about the caller beyond that.
• Before external activation: the privacy notice names quotes, payment links and booked meetings from calls; the Reps consent text says an agent may book a meeting and send an invite to the email given (consent text version bump); tax review of a paid-on-the-spot invoice with no named customer for each region (India B2C invoices above the GST threshold need the buyer's details; check US and UK receipt rules); counsel to confirm the Law 5 exception wording on the trust pages.

Automations: the store of responsibilities, and what an automation may now do (2026-10-29)#

• Status: committed (FounderStack 089f185d, 1074290a; migration 0217 already live); live after the next kernel restart. Demo workspace only, no outside tenant.
• What it does: Automations has a store (Discover) of 2,125 ready-made automations, one for each workflow that workflows/ marks as working, ordered by the workspace's industry (onboarding answer) and the person's role names. A person reads each step before picking it ("What it does": the app it happens in, and whether it reads, makes, has Blue write, or sends after a yes), picks into a basket priced from the actions plan, and hands off: each becomes their own automation, running as them with their permissions.
• What changed in what an automation may do: it may start on a schedule (daily to yearly), on an event, or when its owner starts it with a line of input; steps may be conditions, waits, a step where the workspace's own model writes or decides one bounded thing, a notice, or an "ask me" step. Sending, reminding, issuing, inviting, sharing, publishing and paying are allowed only after an "ask me" step: the run stops, the owner gets a notice naming what was written and the items it will act on, and nothing happens until their yes. A tool that always proposes a plan is confirmed by that yes. Deleting, erasing and access changes are never allowed (unchanged).
• Data map: no new personal-data fields. Runs read and write the workspace's own records through the existing tools, as the owner (automation_run.state keeps a paused run's step outputs until it resumes or ends; input.text is the owner's line). AI steps send the facts a template names (invoice customer and days late, task titles, a P&L, the owner's typed line) to the workspace's own provider, metered as AI steps.
• Limits written into the library and held by a test: health templates have no AI step on clinical or patient records and send nothing about patients; school templates have no AI step on a student's or child's details; recruitment templates never screen or rank candidates; immigration, legal, tax, money and housing templates draft or list and a person decides, never a promised outcome; a month pack is never sent to a placeholder address.
• Before external activation: the privacy notice says automations act as their owner and what AI steps send to the workspace's provider; the provider-egress page names the automation AI step role (Role.DRAFTER); counsel to confirm that a yes on a notice is adequate consent for each send class (mail to customers, reminders, publishing) in each region; a review of the health and school sector templates by someone in those fields before a tenant in them.

RM Drive#

• What: file storage, sharing, data rooms, file requests, AI tagging, locked notes; RM Orbit/drive; drive.freedomlabs.in. Status: live.
• Users and regions: Orbit users and their external viewers, global.
• Data: P0 and P1 user files, viewer analytics (email, IP, time per page), locked-note ciphertext.
• Modules: M5, M7 (data rooms), M16.
• Regimes: DMCA 512 (register the agent), IT Rules, DSA notice-and-action for EU viewers, PECR and GDPR for viewer tracking, CSAM reporting duties, Online Safety Act if UK viewers can upload (file requests).
• Red flags: per-viewer analytics without a notice on the gate page would be covert tracking; file requests accept uploads from anonymous people.
• Must do: tracking notice and consent on data-room gates; DMCA agent and takedown page; malware and hash scanning on upload; share-link expiry defaults; quota-ledger accuracy; locked-notes copy must say exactly what the server can and cannot read (it holds ciphertext, salt, iv; it cannot read content; it can see titles if title search is server-side).

RM Editor-Pro (Chalkboard)#

• What: a teaching whiteboard: draw, lay a lesson out, animate it, export it, and share a live board. Two deployments of one frontend: inside Supernatural (FounderStack) as the capability chalkboard, backend in the kernel (FounderStack/Backend/app/capabilities/chalkboard, migration 0125, added 2026-10-13); and its own host, editor.freedomlabs.in, on its own older backend (FounderStack/01-Productivity/Chalkboard, its COMPLIANCE.md holds that deployment's data map). Status: live on its own host; building inside Supernatural (no external tenant yet).
• Users and regions: workspace members (adults: founders, staff, teachers), global; and anyone a board's owner hands a view-only link to, who needs no account. No accounts for under-18s. Inside Supernatural a link only lets a visitor watch, and tells them nobody's name; on its own host an owner may also make a link a guest can draw through. Unknown region gets the strict path.
• Data map, kernel tables (all tenant-scoped under forced row-level security, stored in India, no processor):

• Modules: M5 (hosted user content and sharing), M2 where a teacher puts children's information on a board (the workspace is the fiduciary, we are the processor; no child accounts, no tracking, no ads), M6 (exported video is user-made, not generated).
• Regimes: DPDP, IT Rules 2021 (intermediary duties for shared boards), DMCA 512, Online Safety Act and DSA for UK and EU viewers of a shared board, CSAM reporting.
• AI: none inside Supernatural. The helper is not wired and says so; no board content goes to any model. On its own host it uses local Ollama only. No cloud exception exists for this app; adding one needs an entry here first.
• Red flags: a board may hold P0 and is not encrypted at rest beyond the disk; pasted pictures are sniffed, capped and checked but not scanned for malware or known CSAM hashes; a link with no end date is possible when its owner chooses it; the public board page's noindex is a meta tag set by script (the API answers carry the header, the HTML shell does not).
• Must do: malware and CSAM hash scanning for pictures on shared boards (belongs in Drive's shared intake); a scheduled trash purge (today it runs when someone in the workspace trashes a board); rights export and erasure must walk the six chalk_* tables; a server-side re-encode of pictures to strip metadata for clients that bypass the editor; screen-reader pass with a real user; before any school is a tenant, the M2 processor contract and a decision on boards that carry children's data.

RM Safe (was Wallet)#

• What: the workspace vault for credentials: API keys, passwords, tokens, certificates, SSH keys, plus a shared info list (domains, account names). Two deployments of one frontend: inside Supernatural (FounderStack) as the capability safe, backend in the kernel (FounderStack/Backend/app/capabilities/safe, migration 0127, added 2026-10-13); and the older standalone service (FounderStack/02-Operations/Safe/backend), internal only. This entry is the kernel one; nothing was imported from the standalone service. Status: building inside Supernatural (no external tenant yet); the threat model is in FounderStack/02-Operations/Safe/README.md.
• Users and regions: workspace members (adults), global. No outside party reaches it: no share links, no public page.
• Data map, kernel tables (all tenant-scoped under forced row-level security, stored in India, no processor):

• Modules: M16 (identity and secrets).
• Regimes: DPDP and SPDI Rules (passwords are sensitive personal data), CERT-In directions (180-day logs), GDPR and UK GDPR where a tenant is there, FTC Act section 5 for the one security claim the app makes.
• AI: none of its own. The workspace agent can list entries by name, type, project and tags, and can remove one as a plan the person confirms. No tool returns, takes or can reach a stored value or its notes, so no value goes to any model. Names and tags do go to the workspace's chosen model when the agent lists them.
• Claims: the app says "All values encrypted at rest" and "This value is encrypted at rest". Both are literally true of the kernel capability as of migration 0127 (values, notes and shared info values). Nothing stronger may be said: not "zero-knowledge", not "end-to-end", not "bank-grade".
• Red flags: one kernel key encrypts every workspace's values and also signs sessions, so it is not envelope encryption and has no rotation path (M16 asks for envelope encryption); anyone with safe.write reveals any entry in the workspace (M16 asks for per-secret policies and a two-person break-glass); reveals are logged but nobody is alerted; the audit log is append-only for the app's database role, not for the database owner, and is not hash-chained; the reveal limit lives in one process's memory; while the kernel accepts development identity headers, a person who can reach it directly can reveal as anyone.
• Must do: before any customer stores a real credential: close the development identity path for the suite; envelope encryption with a key per workspace, held outside the database host, and a tested rotation; re-authentication or a second factor before reveal; an alert to an admin on reveal and on the limit being hit; per-entry access and break-glass with two people; decide and publish audit retention; add the vault to the provider-egress page (names and tags only); a screen-reader pass of the reveal dialog with a real user.

RM Writer (Docs, Sheets, Slides)#

• What: the Orbit document suite: rich-text documents with realtime collaboration, spreadsheets (Univer), slide decks, an infinite canvas, comments, mentions, share links, and local-AI assist and grammar; RM Orbit/Writer.tmp (the Writer/ directory is a dead prototype); docs.freedomlabs.in :45010, API :6011. Status: live.
• Users and regions: Orbit users and anyone holding a share link, global.
• Data: P0 and P1 whatever users write, uploaded images, comment and mention text, document titles, read receipts (who opened a document and when), audit log, per-user Gate identity.
• Modules: M5 (hosted user content and sharing), M16 (Gate client).
• Regimes: DPDP and SPDI, CERT-In (180-day logs), IT Rules 2021 once a document is shared outside the org, GDPR and UK GDPR where a share link reaches EU or UK readers, DSA notice-and-action for EU readers, Online Safety Act if UK readers can post content into a shared document.
• Red flags: shipped for months with authentication switched off. WRITER_AUTH_REQUIRED defaulted to false, no .env existed, and the only thing standing between the public internet and the document API was a guessable X-Workspace-Id header. The AI endpoints and image upload were open on the same host. Fixed 2026-08-23: Gate SSO with PKCE, blanket API authentication, workspaces scoped to the caller's Gate org. Content in the database at the time was smoke-test fixtures only, so nothing real was exposed, but assume the write surface was reachable. Second red flag: the app ran on a Vite dev server against a public hostname until the same date. Third: Writer.tmp is gitignored, so the live application is not in version control.
• Must do: keep WRITER_AUTH_REQUIRED=true and ALLOW_LOCAL_HS256_FALLBACK=false in production, with a regression test for both (present); share links expire by default; read receipts need a notice to the people being counted, they are per-viewer analytics; AI disclosure where AI output appears and no user content to any cloud model (Writer is local Ollama only); retention and delete-my-data path in settings; malware scanning on image upload; DMCA and grievance route inherited from the suite legal pages; get Writer.tmp into version control or move the app to a tracked path; back up Writer.tmp/data/writer.db, there is no backup today.

RM Tour#

• What: Chrome extension plus service that records a click-by-click workflow and publishes it as a step-by-step guide into RM Docs (Writer); RM Orbit/Tour; :45041 web, :46041 api. Status: design, nothing built, no users.
• Users and regions: internal operators first, global if productised.
• Data: screen captures of whatever the operator has on screen, so any class up to P0 can appear; step text; page URLs and selectors; operator identity from Gate.
• Modules: M5 (hosted user content and sharing), M16 (Gate client).
• Regimes: DPDP, CERT-In, IT Rules 2021 once guides are shared outside the org, GDPR and UK GDPR where a guide reaches EU or UK viewers, plus the terms of any third-party product being recorded.
• Red flags: capture is the risk, not storage. A screenshot of a live admin screen carries customer data that the operator did not choose to share, and a published guide is shareable. Recording a third party's product and republishing it may breach that vendor's terms.
• Must do: visible recording indicator for the whole session; blank credential, card, and one-time-code fields in the page before the screenshot is taken, with a regression test; manual blur and crop before publish, baked into the published asset; 90-day retention on raw captures then purge; assets stored outside the web root and authorised against the owning workspace; data map before the first stored capture; share links inherit Writer expiry defaults; no end-to-end encryption claim; update this entry to the real status before the first real user.

Nest (Connect)#

• What: team chat with agents; RM Orbit/Connect; chat.freedomlabs.in. Status: live internally.
• Data: P0 message content; agent outputs.
• Modules: M5.
• Regimes: IT Rules, DPDP, Online Safety Act if UK users, DSA if EU.
• Must do: agent disclosure in channel; tenant scoping tests; export and deletion; retention policy; abuse reporting.

Gate (AuthX), RM Authenticator, Gate Admin#

• What: SSO and MFA for every Orbit app; RM Orbit/Gate, RM Orbit/Authenticator; sso.freedomlabs.in, auth.freedomlabs.in, admin.freedomlabs.in. Status: live.
• Data: P0 credentials, MFA seeds, push subscriptions, org membership.
• Modules: M16.
• Regimes: NIST 800-63B as the benchmark, RFC 9700, DPDP and UK GDPR (account data), CERT-In logs.
• Red flags: ephemeral JWKS bug (fixed), refresh grant unsupported (apps align TTLs), 2.5 GB untracked Authenticator tree.
• Must do: key rotation runbook with JWKS overlap; consent screen per client; audit log of issuance and revocation; admin MFA enforced; breached-password check; account recovery that does not bypass MFA; security page.

Folio (RMBook + Calendar)#

• What: booking links, public profiles, Meet rooms; folio.freedomlabs.in, calendar.freedomlabs.in. Status: live.
• Data: P1 calendars, contacts, bookings, Google OAuth tokens, video intros.
• Modules: M5, M11, M10 (reminders).
• Regimes: Google API Services User Data Policy (Calendar scopes, verification), CalOPPA, PECR for reminder emails, DPDP.
• Red flags: Calendar/server/.env secrets were committed to a repo with a GitHub remote (rotate all); token in localStorage; no CSRF or rate limits on public endpoints; email from a Spamhaus-listed IP.
• Must do: rotate Google client secret, SECRET_KEY, mail password; move tokens to httpOnly cookies; rate limits; send via Resend; Google verification for Calendar scopes; delete-account flow that revokes Google tokens.

RM Sign#

• What: e-signature; RM External/RM Sign; sign.freedomlabs.in. Status: live.
• Data: P0 documents and signatures, signer identities.
• Modules: M7, M16.
• Regimes: ESIGN and UETA, UK eIDAS, India IT Act and BSA presumptions, DPDP for external signers.
• Must do: region-aware signature-level statement; ESIGN consumer consent flow for US consumers; First Schedule exclusions shown for Indian documents; PAdES-LTV and RFC 3161 timestamps; public verification page; retention default and deletion; external-signer notice.

RM Bills#

• What: invoicing and receivables; bills.freedomlabs.in. Status: live.
• Data: P1 client and invoice data, payments. P0 processor credentials (Razorpay and Paddle keys) entered in the console since 2026-08-21: Fernet-encrypted at rest under RMBILLS_CREDENTIALS_KEY, never returned by any endpoint, every save, removal and test audit-logged by field name only. The env file still takes precedence.
• Modules: M4, M16 (credential store).
• Regimes: GST invoice rules, LUT exports, Companies Act record retention, Consumer Protection (receipts), Resend deliverability.
• Must do: keep the state code 37 correct; immutable numbering; GST fields complete; e-invoice readiness; FIRC references on export invoices; client-portal tokens short-lived; backups (proven) on schedule; RMBILLS_CREDENTIALS_KEY set and backed up with the env file, rotation re-enters every saved credential.

RM Cloud console and RM Cloud hosting#

• What: private cloud on owned hardware for startup clients; console :7001 cloud.freedomlabs.in. Status: live clients.
• Data: P1 client contacts and billing, P0 everything clients store.
• Modules: M9, M4.
• Regimes: CERT-In 5-year KYC and 180-day logs, DPDP processor, contracts and SLA, GST.
• Must do: client KYC register; DPA and acceptable-use policy signed by each client; tenant isolation documented; backups off-site and tested; status page; incident notification clause; no unmeasured uptime claims.

ServerPro (host control panel)#

• What: internal panel and MCP server for the main host: libvirt VMs, systemd, PM2, Docker, ports, host resources, Cloudflare DNS and the cloudflared tunnel; :8090 on localhost. Status: internal.
• Data: P0 admin password hash (argon2id) and TOTP seed, hashed API keys, Cloudflare API token in .env (mode 600); P1 audit log with actor, action, target and IP, kept 180 days.
• Modules: M16, M9 (it can stop or delete client VMs such as tenant1).
• Regimes: CERT-In 180-day logs, OWASP ASVS L2.
• Must do: TOTP on the admin account before the panel is exposed through the tunnel; API keys rotated when a Claude session is shared; MCP_ALLOW_DESTRUCTIVE off by default; sudoers limited to systemctl actions; Cloudflare token scoped to DNS:Edit on owned zones.

Planet (CRM)#

• What: CRM and GTM OS; planet.freedomlabs.in. Status: building.
• Data: P1 contacts and companies, outreach content, AI scores.
• Modules: M10.
• Regimes: UK GDPR legitimate interest and PECR, CAN-SPAM, CASL, DPDP (publicly available data exemption is narrow), LinkedIn terms (no scraping), FTC fake-reviews rule.
• Must do: source field on every contact; suppression list; opt-out in every sequence; no scraped enrichment; AI scoring explained and exportable.

Atlas, Learn, Search, VSearch, Writer, Writer-X, Fonts, orbit-ui, OrbitShell, TurboTick, Wallet, Card, Capital Hub, Secure, Snitch, Control Center#

• What: internal productivity and platform pieces of Orbit.
• Data: mostly P1 work data; Wallet is P0 secrets; VSearch holds confidential manuscripts; OrbitShell calls a cloud LLM (Claude API) by design.
• Modules: M16 (Wallet, Card), M13 (VSearch), M10 (Writer-X posting via tweepy).
• Must do: Wallet threat model before any external use; VSearch manuscript confidentiality and retention; Writer-X follows X automation rules and labels automated posts; OrbitShell disclosed as cloud AI with no P0 data; Fonts only ship licensed faces; every public one has trust pages.

Tier 3: consumer SaaS with paying US and UK customers#

Scribe#

• What: AI content engine publishing to LinkedIn, X, and pages on behalf of customers; RM Portfolio/Scribe; Gemini Flash Lite primary, Groq fallback. Status: live, 3 users, revenue wrapper missing.
• Users and regions: US and UK professionals.
• Data: P1 customer profiles, OAuth tokens for LinkedIn and X, drafts, engagement data, third parties mentioned in posts.
• Modules: M10, M6, M11.
• Regimes: LinkedIn API terms and user agreement, X developer agreement and automation rules, FTC Endorsement Guides and fake-reviews rule, ASCI influencer guidelines, CAP Code, UK GDPR with IDTA (Indian servers), PECR, CalOPPA, ROSCA and CA ARL once billing exists, Gemini and Groq data terms.
• Red flags: one LinkedIn token per install (customer #2 would post to customer #1's feed: a security incident and a platform-terms breach); singleton scheduler; no billing, email verification, or plan enforcement; practice mode leaks REVIEW rows; no Postgres backups.
• Must do: per-profile channel_credentials with encryption; per-tenant jobs; customer approval before publish with audit; AI disclosure where the platform requires; never fabricate engagement or reviews; DPA with UK IDTA for UK customers; privacy and terms pages rewritten 2026-08-21 to match the hosted service (Gemini, Groq, Ollama, Pexels, Resend, ntfy, Indian storage, grievance contact) plus security.txt; keep them in sync with code; backups before the next customer; billing with clear terms and easy cancellation.

AIBookly#

• What: autonomous book-writing workbench (BYOK, managed, filesystem hand-off); RM Portfolio/AIBookly; aibookly.freedomlabs.in (frontend :10006, backend :46015). Status: live; paid plans on (Book $199, Petition Edition $499, one-time, Paddle as merchant of record via RM Bills).
• Users and regions: US and UK authors.
• Data: P1 manuscripts (authors' IP), provider keys (BYOK, Fernet-encrypted at rest), billing subject id (card data never touches us; Paddle holds it). Planned before first external user of the chat front door (2026-09-13 plan, phases 1-3): P1 uploaded source material (notes, transcripts, prior writing -- may contain third-party personal data the author holds), P1 interview and change-request chat transcripts, P1 claims ledger and author-answer records. All three are book-scoped, exported with the book, and deleted with it. Added 2026-10-28 (fiction path): P1 story plan per book (book_memory.story_json: premise, cast, scene cards, running canon), written by the managed model from the author's premise and drafts; book-scoped, in the account export, deleted with the book.
• AI: managed mode is CLOUD by register exception. As of 2026-09-14 the managed provider in production is Google Gemini 2.5 Flash, with Groq, OpenRouter and local Ollama behind it (Cerebras is in the chain and out of credit). The privacy notice and sub-processors page name exactly those. Anthropic Claude (Opus 5 for planning, evaluation and the whole-book read; Sonnet 5 for prose) is wired in code via the official SDK and leads the chain the moment an AIBookly-scoped ANTHROPIC_API_KEY is provisioned; none has been, and the only Anthropic key on the box belongs to Lakshmi and is not shared (key hygiene). When it is provisioned, the sub-processors page and the privacy notice gain Anthropic the same day. BYOK runs on the customer's own key with the same fallback-to-Ollama tail (open decision: a throttled BYOK key silently falls to a local 12B model). Uploads, interview transcripts and the claims ledger went live 2026-09-14 and are named in the notice.
• Modules: M6, M13, M11.
• Regimes: copyright of AI-assisted works (US Copyright Office 2025 guidance; UK CDPA section 9(3); India section 2(d)(vi)), Amazon KDP AI disclosure, provider terms, UK GDPR with IDTA, ROSCA and Consumer Contracts Regulations (one-time purchase with the 14-day digital-content waiver un-pre-ticked), CalOPPA.
• Red flags: none structural; the legal risk is in what customers do with output and in claims we make about ownership. Landing copy said "autonomously" while the release gate requires a human review verdict; corrected 2026-09-13 to describe interview -> plan -> research -> draft -> gates -> your review (M11).
• Must do: tell authors plainly what is and is not copyrightable and to keep human-authorship evidence; KDP disclosure reminder at export; plagiarism and quotation checks; BYOK keys encrypted and scoped; managed mode names Anthropic and the fallback chain and the no-training setting in the privacy notice; manuscript deletion and export cover uploads, transcripts and ledger once those ship; no claims that output is "original" without the check; uploads flow: tell the author that material they upload may contain other people's data and that they are responsible for having it.

Rollout#

• What: release OS for independent musicians; rollout.freedomlabs.in; Stripe and RevenueCat; MinIO assets. Status: live demo.
• Users and regions: US artists.
• Data: P1 artist and creator contacts, unreleased masters and artwork (trade secrets), billing.
• Modules: M6, M10, M11, M4.
• Regimes: copyright and confidentiality of assets, CAN-SPAM and PECR for creator outreach, Apple and Google in-app purchase rules (RevenueCat), ROSCA, CalOPPA.
• Must do: signed short-lived asset URLs; licence from artist limited to service; no training on assets; outreach suppression and opt-out; store billing compliance; account deletion in app.

Dwell (isdwell.com)#

• What: SMB property-management SaaS; RM Portfolio/Dwell; Stripe Connect, Documenso, SmartMove. Status: pre-launch, zero customers.
• Users and regions: US landlords and residents.
• Data: P0 tenant screening results, SSNs handled by the CRA, payment data via Stripe, leases; P1 resident contacts.
• Modules: M15, M4, M7, M10 (resident texts), M5 (maintenance comms).
• Regimes: Fair Housing Act and HUD AI guidance, FCRA (adverse action), state landlord-tenant law, ESIGN, Stripe Connect platform agreement, TCPA, CalOPPA and state privacy laws, Colorado AI Act (housing), Documenso AGPL if self-hosted and modified.
• Red flags: homepage once had fabricated logos and metrics (removed); Resend burst to fake seed addresses from a worker; migration chain fragile.
• Must do: adverse-action flow with CRA contact; no cross-landlord pricing features; state-aware lease templates with counsel note; suppression list enforced in workers; TCPA consent for texts; trust-account disclaimer; Documenso licence posture documented.

Gulgul#

• What: hyperlocal delivery platform, 4 mobile apps + backend; RM Portfolio/Gulgul. Status: dormant build.
• Data: P1 customer and driver identity, P0 precise location, payments and ledgers.
• Modules: M4, M11, M8 (gig workers).
• Regimes: DPDP, Motor Vehicles Aggregator Guidelines 2020 (state licences for aggregators), Code on Social Security 2020 (gig-worker provisions), state gig-worker acts (Rajasthan 2023, Karnataka 2024), FSSAI for food delivery, RBI PA rules, Consumer Protection E-Commerce Rules.
• Must do: before revival, an aggregator-licence and gig-worker compliance review; location retention minimised; driver background checks lawful.

Aleet (external audit only)#

• What: third-party chauffeur marketplace under CTO review; RM External/Aleet. Status: not ours to operate.
• Rule: review findings only; we are not the controller. If Rang & Mall ever operates it: Motor Vehicles Aggregator Guidelines, driver KYC, location data, payments.

Tier 4: India civic and government#

isdwell (MES maintenance, Ezhimala pilot)#

• What: zero-PII fob-based maintenance platform for government and defence staff quarters; RM External/isdwell; per-station instances. Status: pilot prep.
• Data: P2 by design (units, not people), job cards, vendor dockets; establishment charts of defence stations (restricted).
• Modules: M14, M7, M15.
• Regimes: Official Secrets Act handling of station data, MoD and CERT-In audit requirements, GIGW 3.0, Official Languages Act, GeM procurement, DPDP (processor), BSA for job-card records.
• Must do: keep zero-PII (test that no name, phone, email fields exist); station data never in public repos or cloud prompts; on-premise default; CERT-In empanelled audit before go-live; bilingual UI; vendor can never close a job (structural); legal drafts reviewed by counsel.

MyJanata#

• What: civic-issue reporting and triage; RM External/MyJanata; myjanata.freedomlabs.in. Status: live prototype.
• Data: P1 citizen contact, P0 location and photos of issues (may include faces), staff identities.
• Modules: M5, M14.
• Regimes: IT Rules (UGC), DPDP, TRAI DLT for SMS OTP, WhatsApp policy, defamation exposure, GIGW for municipal use, Anthropic terms only if a key is added.
• Must do: blur faces and plates on public views; location precision reduced publicly; complaint and takedown path; OTP templates registered; email OTP sender moved off GoDaddy to Resend; controller agreement with municipal partners.

BuilderStudio#

• What: construction project management for Indian government contractors. Status: dormant build.
• Regimes: DPDP, Prevention of Corruption Act (tender workflows), GST and TDS on works contracts, Contract Labour and BOCW Act records if labour modules exist.
• Must do: before revival, make sure AI guidance cites live circulars with dates and carries the "not legal or financial advice" line.

Tier 5: internal, private, or not yet products#

FreeTunes (was RM Music; renamed 2026-09-14)#

• What: household music player on YouTube audio through yt-dlp and ytmusicapi; music.freedomlabs.in; source at RM Internal/Music. Status: private, live.
• Data: P1 listening history; P1 session device label and last IP address (recorded at login, kept 180 days or until the account signs in elsewhere, shown only to the account holder on their Profile, never used to decide access).
• Auth: seeded accounts only, no sign-up, no SSO (the Orbit door was removed 2026-09-14). One session per account: a second sign-in evicts the first and the evicted device is told. Login rate-limited (10 failures per 15 minutes per account and per address).
• Rule: private household use only; no public signup, no marketing, no client demos, no monetisation; cached audio capped and short-lived; remove lyrics if a licensing review says so; rebuild on a licensed path before any external user. See M6. The rename does not change this: sharing beyond the household waits for the licensed path.

Imprint (cognitive twin)#

• What: personal cognitive graph and "talk as Sasi" chat; architect.freedomlabs.in; Gemini primary, Groq, Ollama fallback.
• Data: P0 beliefs, values, emotional state of one person; cloud LLMs see it.
• Modules: M11 (companion-bot laws), M16.
• Rule: single-user personal tool; if ever multi-user: companion-chatbot disclosure and self-harm protocol (California SB 243, New York), minors blocked, provider no-training settings, export and delete.

PM Pilot (AI program manager command center)#

• What: standalone web app for one project manager: projects and AI initiatives, uploaded meeting transcripts and notes, evidence-linked actions, decisions, risks and commitments, a Today view, pre-meeting briefs, coaching and a PM handbook. Source at RM External/PM Pilot; backend :6710, frontend :3560. Status: building, single-user (founder), no public signup, no billing.
• Data: P0 meeting transcripts and notes (message content of third parties: colleagues, vendors, sponsors), uploaded by the user; P1 project, stakeholder names and roles, decisions, risks, commitments; P1 growth profile and coaching reflections of the one user; P0 optional BYOK API key (Fernet at rest). Every project, meeting and note carries a classification (public, internal, confidential, security-sensitive, OT) that retrieval filters on.
• AI: Google Gemini Flash-Lite and Flash on the paid tier under the operator's own key, BYOK optional. Operator-requested cloud exception 2026-09-15 for accuracy: transcript text and notes go to Google; audio never enters the app. AI is disclosed where output appears. Every extracted claim carries a verbatim quote verified mechanically against the transcript; nothing enters the record until the user accepts it; abstain rather than infer owners, dates or stances. No emotion inference: stakeholder stance is a user-confirmed field.
• Modules: M5 (transcripts are third-party communications; upload requires the user to confirm the recording and transcript were made with the consent the meeting's jurisdiction requires; Florida is all-party consent), M14 (the user's employer is a US public utility: no employer data enters the app until the employer authorises the tool and data flow; retention follows the employer's records policy, and provenance survives deletion of raw text), M16 (session cookie auth copied from Reach).
• Rule: single-user personal tool on synthetic and sanitised data until the employer authorises real data. No audio capture or recording (a policy feature, not UX). Before any second user: privacy notice naming Google as processor, AI page, consent ledger, export and delete in settings, region tag and the first-launch checklist.

Research and research-papers, Plume, ENTROPIA-VDI, Novus AI research#

• What: autonomous paper pipeline, viewer, methane-event research, VDI security research. Status: live viewer, research repos.
• Modules: M13.
• Rule: verified references, AI disclosure per venue, human-subjects consent where applicable, cloud LLM minimisation, clean history and no AI-tool fingerprints in submissions where the venue requires disclosure instead.

RM Papers (inside Supernatural)#

• What: the research-paper app (feed, new paper, pipeline, reader, exports) inside Supernatural (FounderStack) as the capability papers. Backend in the kernel (FounderStack/Backend/app/capabilities/papers, migration 0128, added 2026-10-13). The research pipeline is the Research entry's own code (FounderStack/01-Productivity/Papers/backend), run unchanged in a worker process the kernel starts per run; the worker holds no database address, secret or model key. The standalone site research.freedomlabs.in keeps its own backend and its own data: nothing was imported. Status: built; on once the migration is applied and the kernel restarted. No external tenant yet.
• Users and regions: workspace members (adults), global. No guest access: an invitation is accepted only by a signed-in member of the same workspace whose address is the one invited. Unknown region gets the strict path.
• AI: cloud exception inherited from Research (cloud primary, local fallback), narrowed here: only the workspace's own configured provider, through the kernel's model runtime, budget checked and metered per person. No RM key. With no provider set up the app says so and writes nothing. Sent to the provider: the topic, the uploaded source text and the draft. Not sent: files as files, names of other members, anything from another paper. Search words derived from the paper, and candidate reference titles, go to CrossRef, OpenAlex, Semantic Scholar and arXiv (public bibliographic indexes) to find and check references.
• Research rules, held in code (M13): an AI is refused as an author (safeguards.author_name); a reference is stored only if matched in an index, the rest are dropped and listed for the person (worker.checked_citations, again at engine._paper_update through safeguards.checked_references); with no results in the source material the Results section is a fixed sentence and no model writes one; a table or chart is kept only if every figure in it is in the uploaded material; numbers not found in the uploaded material are listed on the paper with a warning; the AI disclosure is on the reader and in every export's acknowledgements. No code a model wrote is run: the experiment loop and the math sandbox are off here.
• Data map, kernel tables (all tenant-scoped under forced row-level security, stored in India):

• Access: every route needs a session and the app permission (papers.read, papers.write, papers.share), then asks the paper: owner; coauthor (may change); reviewer or reader (may read). No role opens another person's paper, the admin's included. The one route with no session is the invitation lookup: rate limited per address, says the paper's title, the role and the inviter's name, nothing else.
• Uploads: judged by bytes (PDF, DOCX, plain text, Markdown, JSON, CSV, PNG, JPEG), 50 MB a file, 20 files and 200 MB a paper, kept in the blob store outside any web root, never executed. Not yet: malware scan, re-encoding of pictures.
• Modules: M13 (research integrity, confidential manuscripts, cloud LLM exception), M6 (generated media: a figure is a chart of numbers found in the author's own source material, laid out by the model and drawn by the pipeline; the export's AI statement says so; the reader does not yet label each figure).
• Red flags: manuscript and source text are not encrypted beyond the disk; uploaded text goes to the workspace's cloud provider with no anonymisation step (M13 asks for it "where possible", and for no unpublished third-party data to be sent: today that is the author's judgement, said nowhere in the UI); prose outside the Results section can still carry a number the model made up, which is listed for the person but not removed; an in-text citation whose reference was dropped stays in the prose and is listed, not removed; no similarity check before export; no human-subjects prompt.
• Must do before an external tenant: a notice at upload saying what is sent to the workspace's AI provider, with a tick for "this is mine to send"; rights export and erasure must walk the papers_* tables and the blobs; malware scan on upload; a similarity check; per-venue AI disclosure wording; a human-subjects question at intake; a read of the access rule by someone who did not write it.

Charts (inside Supernatural)#

• What: the data studio inside Supernatural (FounderStack) as the capability charts: ask a question and get a chart, build charts and dashboards, metrics, alerts, scheduled reports, public and embedded links, uploads and outside data. Kernel FounderStack/Backend/app/capabilities/charts (migration 0143, added 2026-10-14), app FounderStack/Frontend/Apps/Charts at /x/charts. Plan: FounderStack/CHARTS_PLAN.md. Status: built and in the launcher; walked live in the demo workspace only. No external tenant yet.
• Users and regions: workspace members (adults), global; unknown region gets the strict path. Readers of a public link are anonymous.
• How numbers are computed: never copied. Every chart, dashboard tile, alert and scheduled report is a query compiled to SQL over the query layer's views (schema q) and run as a person, so their record scope decides what they see. A dashboard shared with someone is computed as them. A public or embedded link is computed as the person who published it, runs only that dashboard's own tiles with its own filters, ends after 30 days by default, and says who published it. Pages are noindex.
• AI: no cloud exception of its own. Ask and "write it up" use the workspace's own configured provider through the kernel runtime, budgeted and metered per person; none configured means the feature says so. Sent: the question, the names and kinds of the fields the person can chart, the workspace's metric names and remembered meanings, and for a follow-up the chart's query; for "write it up", the dashboard's computed per-chart summaries (numbers). The model writes a query, never a number; the numbers come from running it. Shown with every answer: the metric or source, filters, rows read and the SQL, and that a model built it. Forecasts, trends, anomalies and change explanations are computed with numpy, not a model, and each says how.
• Data map (all tenant-scoped under forced row-level security, stored in India):

• Red flags: uploads may hold P0 and are not encrypted beyond the disk; original uploaded files are never kept (only the values read from them); every upload is scanned by ClamAV before it is read (a flagged file is refused); zip-bomb spreadsheets, files over 1,000 columns and workspaces past 500 datasets or 20 GB are refused; DuckDB is locked to the dataset's own file (no other file, network or writing); a signed embed's key uses the one kernel key like database passwords; database passwords use the one kernel key (no envelope encryption, no rotation path, as Safe); a public link shows whatever its publisher could see to anyone holding it; scheduled reports carry numbers out of the suite by mail; the demo workspace holds made-up records marked demo-seed (scripts/demo_business.py).
• Must do before the first outside customer: register here (done); accessibility conformance report drafted (FounderStack/Frontend/Apps/Charts/ACCESSIBILITY_CONFORMANCE.md), still needs NVDA, JAWS and VoiceOver sessions before it is given to anyone; privacy notice to name uploads, extracts, alerts, scheduled reports, signed embeds, imports and what Ask sends; uploads are scanned by ClamAV (Docker container clamav, localhost only, signatures refreshed by freshclam); retention setting for extracts; public pages to carry privacy and terms links; never "SOC 2" wording.
• Modules: M5 (sharing and public links), M16 (stored credentials). Regimes: DPDP, GDPR and UK GDPR for uploads with personal data, IT Rules for published content.

Word (inside Supernatural)#

• What: the word processor inside Supernatural (FounderStack) as the capability word: documents laid out on real pages (paper, margins, headers and footers, page numbers), the full set of formatting, tables, pictures, equations, footnotes, a table of contents, comments, version history, Blue's suggested changes, sharing, and files in and out (.docx, .odt, .rtf, Markdown, HTML, text and the text of a PDF in; .docx, PDF, .odt, Markdown and HTML out). Every document is also a file in the person's Drive. Kernel FounderStack/Backend/app/capabilities/word (migration 0150, added 2026-10-14), app FounderStack/Frontend/Apps/Word at /x/word. Plan: FounderStack/WORD_PLAN.md. Status: step 1 built and in the launcher; walked live in the demo workspace only. No external tenant yet.
• Users and regions: workspace members (adults), global; unknown region gets the strict path. No public or outside-reader page yet.
• Who reads what: a document is read within each person's record scope (own, team, all) and by people it is shared with (read, comment or edit), or by the whole workspace when its owner opens it; a private document is its owner's and its shares' only. Search shows a document only to someone who may open it (word/access.py, search_reach).
• AI: no cloud exception of its own. Blue uses the workspace's own configured provider through the kernel runtime. When Blue reads a document, the blocks of text the person can read go to that provider. Blue changes a document only by suggestion: the change waits on the page until a person accepts it, and an accepted AI change is marked in the version history. "Ask Blue" hands the question and the document's id to Blue; nothing is sent until the person asks.
• Data map (all tenant-scoped under forced row-level security, stored in India):

• Files: every import and picture is checked by ClamAV first (refused if flagged), sniffed by its bytes, capped (50 MB a file, 15 MB a picture, SVG with script refused); conversion runs in Pandoc's sandbox (it reads only the file named and fetches nothing); a PDF is printed by headless Chrome from a page with every picture inlined and nothing fetched from elsewhere; styles reaching a page or a .docx are checked values only (colours, sizes, font names), never markup. Fonts are open (OFL, Apache 2.0) and shipped with the app.
• Red flags: a mention never opens a document to anyone (a person who cannot open it is not told, and the writer is asked to share it); a frozen live figure shows the value it had to everyone who can open the document, as if its author had typed it, so freezing is a choice to publish that number; a document can hold P0 and is not encrypted beyond the disk (end-to-end encrypted documents are step 7, not built: never claim them); a picture is fetched with the reader's token in its address, so it can appear in access logs; exports and downloads take a document's text out of the suite; read receipts are planned on by default (WORD_PLAN.md) and need the reader notice before they ship.
• Must do before the first outside customer: register here (done); privacy notice to name documents, pictures, imports, exports and what Blue sends; read-receipt notice on the page before receipts ship; retention setting for trashed documents (trash is kept until restored); accessibility pass with NVDA, JAWS and VoiceOver; never "SOC 2" or "end-to-end encrypted" wording.
• Modules: M5 (file sharing and documents with other people's data). Regimes: DPDP, GDPR and UK GDPR for documents with personal data.

Matrix (inside Supernatural)#

• What: the spreadsheet inside Supernatural (FounderStack) as the capability matrix: workbooks of many sheets on IronCalc's engine (MIT or Apache 2.0, the same engine in the page as WebAssembly and in the kernel), formulas, formats, conditional formatting, named ranges, frozen rows, people editing together live, comments on cells, versions, Blue's suggested cells, templates, sharing, and files in and out (.xlsx, .xls, .ods, .csv and .tsv in; .xlsx, CSV and PDF out), charts over the grid, pivots, checks, live tables of the workspace's own records. Every workbook is also a file in the person's Drive, and a spreadsheet file in Drive opens in Matrix as a workbook beside it. Kernel FounderStack/Backend/app/capabilities/matrix (migration 0154, added 2026-10-15), app FounderStack/Frontend/Apps/Matrix at /x/matrix. Plan: FounderStack/MATRIX_PLAN.md. Status: step 1 built and in the launcher; walked live in the demo workspace only. No external tenant yet.
• Users and regions: workspace members (adults), global; unknown region gets the strict path. No public or outside-reader page yet.
• Who reads what: a workbook is private to its owner and the people it is shared with (read, comment or edit) until its owner turns Private off; then it is read within each person's record scope (own, team, all). Search shows a workbook only to someone who may open it (matrix/access.py, search_reach).
• AI: no cloud exception of its own. Blue uses the workspace's own configured provider through the kernel runtime. When Blue reads a workbook, or is asked in the workbook's Blue panel for a formula, an explanation, an answer, a clean-up or a whole new workbook, the sheet (first 80 rows by 24 columns) and the selection go to that provider. Blue tries formulas on a throwaway copy, and changes cells only by suggestion: the cells wait on the page with a dashed outline until a person accepts, and accepted cells keep a mark. A formula that fetches from or sends to the web (IMPORTDATA, WEBSERVICE and the like) needs a person to allow it on the page; Blue cannot allow it.
• Data map (all tenant-scoped under forced row-level security, stored in India):

• Files: every import is checked by ClamAV first (refused if flagged) and capped (200 MB); .xls is read by xlrd and .ods by odfpy (values only, formulas arrive as their last values); Numbers files are refused with a request to export them as .xlsx; PDF is printed by headless Chrome from a self-contained page; CSV delimiters are detected and numbers written with leading zeros (phone numbers, PIN codes) stay as written. The live connection (a websocket) carries the reader's token in its address because browsers cannot set headers on one.
• Red flags: a live table writes records into cells as the person who refreshed it sees them, and every reader of the workbook then sees those values (the sheet says who refreshed and when; event refreshes run as that person, at most once a minute); a workbook can hold P0 and is not encrypted beyond the disk (never claim end-to-end encryption); the live connection's address holds the token, so it can appear in access logs; exports and downloads take a workbook's cells out of the suite; a web formula, once a person allows it, can send cell values to an outside address on every recalculation.
• Must do before the first outside customer: register here (done); privacy notice to name workbooks, imports, exports, presence and what Blue sends; retention setting for trashed workbooks; accessibility pass with NVDA, JAWS and VoiceOver (the grid is drawn on a canvas, so a screen-reader layer is a step of its own); an allow list for web formulas before they are evaluated; never "SOC 2" or "end-to-end encrypted" wording.
• Modules: M5 (file sharing and documents with other people's data). Regimes: DPDP, GDPR and UK GDPR for workbooks with personal data.

Present (inside Supernatural)#

• What: the slides app inside Supernatural (FounderStack) as the capability present: decks made of typed parts (heading, bullets, numbers, charts, tables, timelines, steps, comparisons, quotes, pictures, the ask) placed in a layout's regions; the kernel lays text out with the real font files and checks every slide (fit, contrast, crowding, titles) and the deck's story (an opening, an ask, sourced numbers). Numbers and charts can stay live from Matrix spreadsheets and the workspace's own records, read as each viewer may. Blue drafts a whole deck from a brief, and changes a person's deck only by suggestion. Presenting full screen with builds and Morph, a presenter view, comments, versions, sharing. Every deck is also a file in the person's Drive. Kernel FounderStack/Backend/app/capabilities/present (migration 0156, added 2026-10-16), app FounderStack/Frontend/Apps/Present at /x/present. Plan: FounderStack/PRESENT_PLAN.md. Status: step 1 built and in the launcher; walked live in the demo workspace only. No external tenant yet. Since 2026-10-16 also: links for outside viewers, live sessions the audience follows from their own screens (polls, questions, reactions, captions), recordings, viewing analytics with consent, brand kits, import from PowerPoint, openly licensed pictures from Openverse, 3D models.
• Users and regions: workspace members (adults), global; unknown region gets the strict path. No public or outside-viewer page yet.
• Who reads what: a deck is private to its owner and the people it is shared with (read, comment or edit) until its owner opens it to the team; then it is read within each person's record scope (own, team, all). Search shows a deck only to someone who may open it (present/access.py, search_reach). Live numbers on a slide are read as the viewer: someone who cannot read the spreadsheet or records behind a number sees that it could not be read, never the owner's figure.
• AI: no cloud exception of its own. Blue uses the workspace's own configured provider through the kernel runtime. Drafting a deck sends the brief, any material the person pastes, the names and columns of the data views they may read, and the first 40 rows by 14 columns of up to three of their Matrix workbooks the brief is most likely about. Asking Blue on a slide sends the deck outline and that slide. Every figure in a draft must appear in the brief, the material or that data (or be worked out from two of them); one that is not is sent back to the model, and if it survives it is named in the slide's speaker notes for the person to check. Blue's changes to a person's own deck wait as suggestions until accepted; a draft Blue made is changed directly only until a person edits it.
• Data map (all tenant-scoped under forced row-level security, stored in India):

• Files: pictures are linked by address in step 1 (no upload yet). The slide fonts are open-licensed files served by the app (OFL). The live connection (a websocket) carries the reader's token in its address because browsers cannot set headers on one. The presenter view talks to the show only inside the same browser (BroadcastChannel); nothing leaves the machine for it.
• Red flags: a deck can hold P0 and is not encrypted beyond the disk (never claim end-to-end encryption); live numbers show records to every reader who may read them, so sharing a deck can show more than its owner expects to readers with wider reach (each viewer sees only what they may read); the live connection's address holds the token, so it can appear in access logs; drafting sends the first rows of the person's matching workbooks to the AI provider.
• Must do before the first outside customer: register here (done); privacy notice to name decks, live numbers, presence, links and viewing time, live sessions, captions (Google via the browser), recordings, Openverse and what Blue sends; retention setting for trashed decks and for viewing data; outside links expire by default and are revocable (done); recording shows an indicator and captions are opt-in with a disclosure (done), but a talk recorded with the audience's voices or faces needs their notice too; accessibility pass with NVDA, JAWS and VoiceOver on the editor and the player (slides are HTML with a label per slide; reading order and alt text checks are next); never "SOC 2" or "end-to-end encrypted" wording.
• Modules: M5 (sharing and documents with other people's data; meetings and recordings when presenting live ships). Regimes: DPDP, GDPR and UK GDPR for decks with personal data.

RM Home#

• What: internal portal and secure-docs vault holding company incorporation documents; :5555.
• Data: P0 company identity documents (PAN, CIN, MOA, AOA).
• Rule: internal only, MFA, access-logged, encrypted backups, never linked from public pages.

Wardro, Bazaar, AnyPickles, Zoopolis, kiwi-mvp, Tether, Discovery OS, Operator, Varuna, Gulgul, agent-runtime, AgentTheatre, ContentMachine#

• Status: dormant, planned, or prototypes without users.
• Rule: before any of these takes a real user, add an entry here with data classes and modules. Tether (relationship science) will be M1-adjacent (sex life and sexual orientation are special category everywhere) and an Online Safety Act user-to-user service if UK users can message; Bazaar and AnyPickles are e-commerce (Consumer Protection E-Commerce Rules, FSSAI for pickles, Legal Metrology, GST); ContentMachine is M6 (synthetic-media labelling, YouTube inauthentic-content policy); Varuna is a defence-adjacent concept (SCOMET export controls and MoD rules before any disclosure).