Syntropy Health Product Vision
Core Platform: Protocol-Driven Wellness Commerce
Syntropy Health is a protocol-driven wellness platform that bridges commerce and outcomes. DTC supplement and wellness brands create structured usage protocols tied to their products. Consumers adopt these protocols into their profile, receive AI-managed reminders, track adherence through daily check-ins, and build longitudinal evidence of what works. Both sides see their data in The Lounge — consumers see personal adherence and outcomes, partners see aggregate compliance and feedback.Three Pillars, One Ecosystem
Protocol System Architecture
Data Models
The protocol system introduces three core models that extend the existing database schema:Vendor-Agnostic Product References
Protocols reference products viaCatalogItem which already supports multiple vendors:
Data Flow
Protocol Creation (Partner Side — via Integration API)
Protocol Adoption (Consumer Side)
Adherence Tracking
Data Sharing
Integration Points with Existing Infrastructure
Check-In System Extension
The existingCheckIn model (syntropy_journals/app/data/schemas/db/models/checkins.py) tracks general health check-ins. Protocol check-ins are a new model (ProtocolCheckIn) but share the same notification infrastructure.
Notification System
The existing notification system (syntropy_journals/app/states/app/notification/) supports TIPS/SUGGESTION/ALERT levels. Protocol reminders use the TIPS level with protocol-specific content:
Settings
The existingSettings model needs one addition:
Partner Portal
The existing partner portal (syntropy_journals/app/states/partner/) has:
PartnerProtocolState— needs to connect to real Protocol DB model (currently uses demo data)AdherenceAnalyticsState— needs to consume real ProtocolCheckIn dataShopifyConnectionState— already handles OAuth, product import
CatalogItem
Protocols reference products viaCatalogItem.id. No changes needed to the catalog model — protocols are a layer on top of existing products.
The Lounge: Dual-View Architecture
Routing Logic
The Lounge renders different views based on user role:Consumer View Components
- Protocol Cards: Active protocols with progress ring, streak count, next reminder time
- Adherence Calendar: Month view with daily status indicators (green=taken, yellow=skipped, gray=missed)
- Response Timeline: Chronological feed of check-in notes and self-reported outcomes
- Trend Charts: Adherence % over time (weekly/monthly)
Partner View Components
- Protocol Dashboard: Cards per protocol showing adoption, active users, avg PDC
- Adherence Distribution: Histogram showing user clusters by compliance level
- Feedback Stream: Anonymized, time-stamped notes from opted-in users
- Retention Metrics: 30/60/90-day completion funnel
Shrine AI: Agent Capabilities for Protocols
Protocol-Aware Agent Behaviors
Shrine AI (the existing LangGraph agent atsyntropy_journals/app/functions/llm/agent.py) gains protocol-related capabilities:
- Protocol Q&A: “When should I take my Vitamin D?” → checks user’s active protocols and provides timing-specific advice
- Adherence Coaching: “You’ve been at 100% this week — keep it up!” or “You missed yesterday’s check-in. Want to log it now?”
- Interaction Awareness: “You’re taking Magnesium and Calcium — consider spacing them 2 hours apart”
- Reorder Nudges: “Your 90-day Omega-3 protocol ends in 5 days. Want to reorder?”
MVP Implementation Phases
| Phase | What | Depends On | Deliverables |
|---|---|---|---|
| 1 | Protocol Data Models | — | DB models, Alembic migration, CRUD db_utils |
| 2 | Partner Protocol CRUD | Phase 1 | Partner portal forms, protocol list/detail, real data replaces demo |
| 3 | User Protocol Adoption | Phase 1 | Public protocol page, “Add to My Protocols”, user dashboard |
| 4 | Adherence Tracking | Phase 1 | Check-in UI, notification integration, streaks, missed detection |
| 5 | Lounge Dual View | Phase 3+4 | Consumer adherence view, partner analytics view, data sharing settings |
Key Technical Decisions
| Decision | Choice | Why |
|---|---|---|
| Protocol references CatalogItem | Vendor-agnostic | Products come from Shopify, Amazon, WooCommerce — protocol shouldn’t care |
| Separate ProtocolCheckIn model | Not reusing existing CheckIn | Protocol check-ins have different schema (scheduled_date, protocol context) and different analytics needs |
| Opt-in data sharing | Default OFF | Privacy-first builds trust; FTC compliance for health-adjacent data |
| Streak calculation is real-time | Not cached | Simple count query; no need for materialized views at MVP scale |
| Missed detection via background job | Not client-side | Reliable even if user doesn’t open app; runs at midnight per user timezone |
Voice & Chat First (Retained)
The original voice/chat-first paradigm applies to protocol management:- Voice check-in: “Hey Shrine, I took my Vitamin D” → marks today’s check-in as taken
- Chat Q&A: “Can I take this with coffee?” → contextual answer from Shrine AI
- Proactive nudges: Shrine AI sends reminder at user’s configured time
- Natural language protocol discovery: “Show me protocols for sleep” → searches protocol library
Multi-Channel Presence
Shrine AI lives where users already are:- Web — Primary interface with full Lounge dashboard
- Mobile — Push notifications for check-in reminders
- Slack — Enterprise protocol management
- WhatsApp/SMS — Lightweight check-in confirmation (future)
Shopping Integration (Updated)
Protocol-First Commerce
Instead of just tracking purchases, we now lead with protocols:| Old Model | New Model |
|---|---|
| Buy product → auto-track purchase | See protocol → adopt protocol → buy product → track adherence |
| Purchase data enriches health profile | Adherence data enriches health profile AND partner analytics |
| Passive consumption tracking | Active protocol engagement |
| One-way (consumer to platform) | Two-way (consumer ↔ brand via The Lounge) |
Integration Flow
The OpenDiet Knowledge Graph
The proprietary intelligence behind Shrine AI’s dietary recommendations is the OpenDiet Knowledge Graph — a unified food-to-compound-to-symptom ontology developed in the open-diet-data research repository.What It Contains
| Layer | Scale | Source |
|---|---|---|
| Herbs | 2,376 plants | Dr. Duke’s Phytochemical Database (CC0) |
| Compounds | 94,512 bioactive molecules | Dr. Duke’s + FooDB + CMAUP |
| Herb-Compound Links | 99,280 associations | Dr. Duke’s (plant part, PPM concentrations) |
| Compound-Food Links | 4,149,541 mappings | FooDB cross-referenced with OpenNutrition (326K foods) |
| Symptoms | 47 categories | Seeded from Duke bioactivities |
| Molecular Targets | CMAUP + TTD databases | Protein targets for compounds |
| Disease Associations | CTD toxicogenomics | Compound-disease relationships |
How It Powers Shrine AI
Research MCP Servers
The research repository exposes 23 MCP tools across two servers:- mcp-herbal-botanicals (15 tools): Herb search, compound lookup, food-herb overlap, symptom-to-herb mapping, molecular target queries, semantic search via LightRAG/Neo4j
- mcp-opennutrition (8 tools): 326K food database with 90-nutrient profiles, barcode lookup