tgss-mem

Memory #149 CURRENT

WhatsApp → pria-relate Integration (Parked) Architectural decision parked 2026-04-28 — Mark agreed with the WhatsApp Business Cloud API + agent-layer-on-pria-relate path; waiting to resume after pria-relate's Milken import and CRUD layer land. Mark's primary WhatsApp is already a Business account listed as "Lydian Foundation". **Status as of 2026-04-28:** Parked. Architecture agreed; implementation deferred until pria-relate matures. ## Decision (agreed) **Architecture:** WhatsApp Business Cloud API → webhook → pria-relate ingestion → agent layer for message categorization, action-extraction, follow-up nudging against person/org records. **Rejected paths:** - Unofficial reverse-engineered libraries (Baileys, whatsapp-web.js) — ToS violation, wrong posture for a privacy/identity infrastructure company. - Manual export + batch ingestion — fallback only, lags real-time. ## Existing posture (verify when resuming) Mark's primary WhatsApp is already a Business account, listed publicly as **"Lydian Foundation"**. This means a separate Business number is **not** needed (the original main friction point is removed). **Verification step to perform first when resuming:** The "Business account" status needs to be confirmed as the right tier: - **Tier A — WhatsApp Business app** (free smartphone app): no API access, common path for SMBs. If Mark is here, the number must be migrated up to Tier B before integration is possible. - **Tier B — WhatsApp Business Platform / Cloud API** (Meta Business Suite, requires verification): provides the webhook + send/receive API. Required for the agreed architecture. Fastest check: log into business.facebook.com → WhatsApp Manager → look for a phone-number ID against the Lydian Foundation number. If present, Tier B is active. If absent, the number must be registered through Meta Business Suite first (brief consumer-app outage during switchover). ## Display-name mismatch flag (raised 2026-04-28) The WhatsApp display name "Lydian Foundation" does not match any of the four canonical entities (TTI / TTF / GCE / GCD). It is a stylistic shorthand, not a registered entity. Counterparties seeing WhatsApp messages from "Lydian Foundation" alongside briefs bylined GCD/TTF may read the entity story as fuzzier than it is. **Decision deferred:** whether to update the display name (e.g., to "Tribernachi Foundation" or "Mark S. Hewitt — TTF") or to keep "Lydian Foundation" as canonical shorthand and add an entry in `tribernachi-skills/general/personal-business-info.md` explaining it. Mark to decide before the next major counterparty WhatsApp engagement. ## Resumption triggers Pick this thread back up when **any** of the following land: 1. pria-relate Milken import + CRUD layer complete (the natural data-home is then ready to receive WhatsApp ingestion). 2. WhatsApp counterparty volume crosses ~20% of all counterparty conversations (manual tracking gets unsustainable). 3. A specific counterparty thread (Ken Yang/Floyd, or another) generates enough action items that automated extraction would pay back. 4. Mark builds the broader "messaging-channel ingestion" abstraction — at which point WhatsApp is one channel among iMessage / Signal / Telegram. ## Open architectural questions (to revisit) - **Channel scope:** WhatsApp-only, or generalize to "messaging channel ingestion" with WhatsApp + iMessage + Signal + Telegram + email behind one abstraction? The latter is more work but doesn't bind pria-relate to one channel. - **Agent action gates:** what does the agent do autonomously vs queue for Mark's approval? Categorization and tagging seem safe-autonomous; reply drafts must be approval-gated; outbound sends should require explicit Mark-confirmation in early phases. - **Per-counterparty consent:** are inbound message contents stored against pria-relate person records, or just metadata + Mark-curated summaries? Storing full message contents has privacy/discoverability implications. - **PrIA binding:** does the WhatsApp counterparty get a stub PrIA record on first contact? Aligns with the broader Conductor + PrIA architecture but adds complexity early. ## Cross-references - `project_pria_relate.md` — the CRM that would host this. - `project_session_continuation.md` — parked alongside other decisions. - `domains/lydian-currency.md` — for the entity-name disambiguation context. — [project_whatsapp_integration_parked.md]

Outgoing Edges

No outgoing edges.

Link to Another Memory