Trust, documented

Every record in Vort Social is owner-scoped. The database model is keyed by user, the query layer filters by user, and there is no cross-tenant read path in the codebase or in the migrations. Two accounts on the same plan cannot see each other even by an authenticated query.

• One Postgres database, one schema, one tenant per row — keyed on userId, indexed, and read with a where-clause scope.
• The full model catalog is documented in AGENTS.md ("Data ownership") so a reviewer can audit which fields carry per-user data.
• The review queue, the calendar, and the published-posts store are all owner-scoped — the join surface is the same as the auth surface.

All traffic in transit is TLS-terminated at the managed hosting layer. Records at rest are encrypted via the managed Postgres infra — Vort does not run a self-managed database. No production data is held in client-side storage or browser-local storage unpinned.

• TLS 1.2+ at the edge — HSTS, modern cipher list, no insecure fall-back.
• At-rest encryption via the managed Postgres infra; nightly point-in-time backups, retained 30 days.
• Secrets live in vault-backed app secrets (set_app_secret) — not in process.env in the codebase and not in committed .env files.

Authentication is Better Auth with an admin role plugin. Org boundaries are enforced server-side: data is read by userId, every per-user /api route is gated with requireAuth(), and every admin surface is re-gated with requireAdmin() after a session read. There is no shared admin password, no custom-admin cookie, and no manual privilege escalation path in the code.

• Sessions are server-issued, scoped per request, and gated on every per-user /api route.
• Admin-only surfaces are gated via the auth module role + requireAdmin() helper, not via hand-rolled auth code.
• No shared password or static fallback for "the founder login"; the admin role is the only authority and it is the same surface the product uses.

Billing is Stripe-on-pay: every checkout goes through Stripe Checkout under the company Stripe Connect account, and no card data ever touches the Vort app. The app reads tier and computes prices server-side from the active catalog — the browser has no influence on what is charged.

• Card data is captured and held only by Stripe; nothing in the Vort database identifies a card.
• Subscription state is re-read on a heartbeat against the Stripe dashboard — the app stays accurate after a renewal, a refund, or a chargeback.
• Webhooks are verified end-to-end; the build never reads payment status from the browser.

Five sub-processors touch a record at Vort Social. They are listed below in the table below — name, what data they receive, and why they are listed. Any new sub-processor publishes to this page before the integration is wired in code.

• A new sub-processor only ships after it has been added to this page — the AGENTS.md change log is the loading surface.
• Each row is a one-line sub-processor + purpose — the table is the audit surface, not a marketing surface.

Vort Social is GDPR- and CCPA-aligned. Per-user data is owner-scoped, exportable, and deletable on request. A data subject request — export, deletion, or correction — sends a redacted copy of the record to the user and a confirmation email; nothing is silently held.

• GDPR rights: access, rectification, erasure, restriction of processing, data portability, and objection — all routed through a single email address.
• CCPA rights: know, delete, opt-out of sale, and non-discrimination for exercising a right — same route, same contact.
• Data subject requests are answered within 30 days; the requester is notified with a same-day acknowledgement email.

A registered incident response process: a security-affecting bug (auth bypass, cross-tenant read, signed-cookie forge) is acknowledged within one business day, mitigated the same week, and disclosed to affected customers at the same time the fix ships. Acceptable-use is also documented here so an evaluator can read the policy alongside the engineering posture.

• Incident acknowledgement within one business day — a reply to the reporter and a status post on the public changelog.
• Per-tenant blast-radius on every incident — we report the credentials compromised, not the headline result.
• A documented acceptable-use policy covering content, account takeover, and the abuse-handling path.