Architecture: How to structure the PVI backend module for model routing, e...

Documentation for Sessions

🏗️ Architecture: How to structure the PVI backend module for model routing, e...

Date: 2026-03-24
Time: 15:18:11 UTC
Session: gspace1-263.7
Agent: backend
Confidence: 90%
Status: ✅ Documented

📋 Decision Context

Question:

How to structure the PVI backend module for model routing, event tracking, and learning?

Task: Not specified

🎯 Decision Made

Chosen:

Single PviModule under engine/pvi/ with 7 services: PviModelRouterService (Haiku/Sonnet/Opus routing), PviController (10 endpoints), UserSuggestionTrackerService (event recording), SuggestionWeightService (personalized weights + daily cron), PviPipelineFeedbackService (weekly report), PviDesignEvolutionService (token analytics), PviTeamLearningService (org aggregation + onboarding). All use default Mongoose connection to vitto-mind database.

Options Considered:

  1. Separate modules per concern (PviTrackingModule, PviLearningModule — over-engineered)
  2. Inline in existing EngineModule (pollutes the module, PVI is 7 services)
  3. Microservice architecture (wrong for internal feature, adds network hops)

💭 Reasoning

The PVI backend needs are cross-cutting: model routing (which LLM for which task), event tracking (user interactions), weight computation (personalization), feedback loops (pipeline improvement), and team learning (org patterns). Grouping under one NestJS module keeps the boundary clear — PVI is a self-contained subsystem that plugs into EngineModule. 3 cron jobs handle background intelligence: daily weight aggregation (7AM), daily org aggregation (6AM), weekly pipeline feedback (Monday 3AM). The @InjectConnection() pattern (no argument) matches the codebase convention where the default connection already points to vitto-mind. Separate per-service modules would be over-engineered — these services share the same database and domain.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation