🏗️ Architecture: How should proactive triggers be learned and stored — DSL vs...

Date: 2026-03-20
Time: 17:40:31 UTC
Session: gspace1-240.5
Agent: backend
Confidence: 91%
Status: ✅ Documented

📋 Decision Context

Question:

How should proactive triggers be learned and stored — DSL vs memory-based patterns?

Task: S240: Proactive trigger learning engine

🎯 Decision Made

Chosen:

Lightweight frequency-based trigger patterns stored in dedicated vitto-triggers MongoDB collection (NOT as VittoMemory). Confidence grows with confirmation, decays on dismiss. No ML models, no DSL — pattern matching on task history + frequency counting.

Options Considered:

1. Custom trigger DSL for users to define rules
2. Store triggers as VittoMemory (conflicts with S239 admission)
3. Dedicated vitto-triggers collection with frequency detection (chosen)

💭 Reasoning

S239 Memory v2 introduces 5-factor admission control. Trigger patterns would be rejected because they score low on factualConfidence (predictions, not facts) and semanticNovelty (patterns repeat by definition). Separate collection avoids conflict with memory admission pipeline. A custom DSL is over-engineering — few users would write triggers manually. ML-based detection requires training data we don't have yet. Frequency counting (3+ similar requests in 14 days) is simple, ships fast, provides real value. Confidence threshold + dismiss-to-decay prevents trigger spam. ProactiveDispatcher already handles the execution side — we only need the detection engine.

📁 Files Involved

• APIs/backend-vitto-api/src/app/engine/trigger-engine.service.ts
• APIs/backend-vitto-api/src/app/engine/schemas/trigger-pattern.schema.ts

🔗 Related

• Decision ID: dev_1774028431367_3qxz9w5
• Session: 240
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation