PropFlow Compliance Audit

What's right: propflowai.co/privacy is live, conspicuous, current (eff. 2025-03-01, upd. 2026-05-07), and matches the repo exactly. §2 discloses collection (contact info, SMS + call content and metadata, usage, IP, visit logs). §1 and §6 disclose Clara, Anthropic, ElevenLabs and Twilio by name. §6 states we don't sell personal information. §7 states retention windows. Terms §5 discloses AI-generated content limits.

Gaps:

• Third parties (item 4): only Twilio, ElevenLabs, Anthropic are named. Not named: AWS (where all tenant data actually lives), AppFolio (bidirectional tenant-data sync — the most material omission), Stripe, Vercel, Browserbase, SendGrid. Worse: /security promises a subprocessor list on the Trust Center, and /trust-center doesn't have one — a promise pointing at a page that doesn't fulfill it.
• CCPA/CPRA specificity (item 2): §9 "Your Rights" is jurisdiction-generic. No "categories of personal information" framing, no right-to-know / opt-out-of-sharing statement, no non-discrimination clause.
• ADMT (item 3): policy discloses AI use but not automated decision-making (Clara autonomously classifies, creates work orders, sends outreach). CPPA ADMT regs phase in through 2027 — cheap to get ahead of.

The problem isn't that we lack a mechanism. It's that we publish promises no code enforces:

• Privacy §7 says conversation + work-order data is retained "for the duration of your tenancy plus 12 months." Nothing enforces this. Conversations, Person rows, photos have no TTL and never expire.
• /data-protection says "Delete requests are actioned on request." There is no subject-erasure path for a tenant/prospect — no deletePerson, IdentityClaims are append-only, no purge script (the only one built, purge-traffic-subject.ts, covers web-visit logs only).
• deletePhoto() exists in the S3 client with zero callers. The code comments promise a 30-day inbox-photo cleanup cron that was never built. Bucket lifecycle rules cover executed-leases and eval runs — nothing covers photos/.
• ElevenLabs call recordings: no retention setting pinned, no delete call anywhere. Transcripts are duplicated into eval corpora with no purge story.
• The /data-protection page references a DPA with "exact windows by data type" — no DPA or retention schedule exists in docs/.

What IS enforced: visit logs really do delete after 90 days (TTL + purge script) — the one published claim with a mechanism behind it.

All 8 buckets in account 194925971150 have the full four-flag Public Access Block, AND the account-level block is on — so even a future misconfigured bucket policy can't open public access. Anonymous probe of propflow-photos → HTTP 403 (verified live, not just config). Every photo serve path is auth-gated + presigned (1h expiry); a test explicitly pins that no signed URL leaks to the client. Zero public object URLs in product code. Nothing to fix.

The site's posture is exemplary — testimonials and case studies were consciously withheld until we have real, consented, attributed customers, and that policy is written into the code and the live case-studies page ("We'd rather ship one real case study than four anonymized ones").

The exposure is confined to blog editorial (src/app/(public)/blog/posts.ts, live at /blog/*):

• "One regional we work with reassigned their after-hours pager entirely…" — an implied real-customer anecdote. Our only live customer is one property, not a "regional." This is the invented-customer-experience pattern the FTC rule targets, narrated by us instead of quoted.
• "Across the first-access cohort, deflection is tracking at 34–42%" / "time-to-first-response dropped from 8 hours to under 30 seconds… tour-book rates roughly doubled" — presented as production data across "properties," unsupportable with one live property.

Mockup personas (Sarah Martinez / Mike Torres) are fine — product-UI demos, never quoted as customers — though a small "simulated conversation" caption would harden them. NOI ranges on the marketing pages are properly labeled estimates with disclosed assumptions.

Designed right, broken in prod. Signup: self-serve Stripe Checkout from /settings ($10/unit/mo, recurring amount disclosed at consent). Cancel: a "Manage Subscription" button on the same page opens the Stripe Billing Portal — on paper, exactly as easy as signup.

But POST /api/billing/portal is gated by requireAdmin, which in production only accepts PropFlow staff. A paying customer clicking "Manage Subscription" gets a 403 — and the client only acts on data.url, so the button silently does nothing. Effective cancel path today: email us. That's the exact ROSCA "harder to cancel than sign up" shape. Undetected because our live relationships are hand-managed.

Secondary: the route trusts a client-supplied customerId — must be resolved server-side when the gate is fixed, or any user could open another customer's portal.

Fix: swap requireAdmin → requireUser, resolve the Stripe customer from the caller's email server-side, surface non-OK responses in the client. Also verify the Stripe Dashboard portal config has cancellation enabled.

Monthly B2B billing = the low-risk quadrant (CA ARL is consumer-scoped and bites on annual terms; the FTC click-to-cancel rule was vacated July 2025, ROSCA baseline still applies). Settings shows the renewal date; checkout discloses the recurring amount. Gaps: no pre-renewal reminder anywhere (no invoice.upcoming handler), and the Terms page has zero mention of subscription, billing, fees, auto-renewal, or cancellation — the recurring charge has no contractual disclosure outside the Stripe Checkout screen. If an annual plan ever ships, a 15–45-day reminder becomes mandatory before launch.

Legal scope: likely OUT — SB 243 targets companion chatbots "meeting a user's social needs" (Replika/Character.AI class) and carves out customer-service bots, which is squarely what Clara is. But the private right of action ($1,000/violation) means plaintiffs, not regulators, test that exclusion — and "anthropomorphic named persona + months-long tenant threads + collections conversations" is the fact pattern a complaint would lead with. Worth a one-time counsel confirmation in writing.

Factual finding: Clara has zero crisis/self-harm handling. Repo-wide grep for self-harm / suicide / crisis / 988 / hotline: no hits. What exists is physical life-safety only (gas, fire, "anyone hurt or trapped" → 911 + escalate), which is genuinely good — but a tenant texting "I can't take this anymore" mid-collections gets whatever the base model improvises, unmeasured, on a channel where the escalation email may not be read until morning. No eval case simulates it.

Recommendation (independent of legal scope): a crisis playbook is ~a day of work — prompt block (recognize ideation → share 988 → escalate_to_human high urgency → stop the business flow) + adversarial eval cases (SMS + voice, including a mid-collections shape).