Symptom: No way to tell whether the insights_gained/memories_created per-conversation multiplier is roughly constant or highly variable. Dividing insights_gained by user-day (as a rough per-conversation-day proxy) was explicitly checked and rejected by the production usage report as an invalid approximation, since conversation volume itself isn't measurable today (see the companion conversation_processed issue, #13).
Impact: A highly variable per-conversation insight/memory ratio would mean a conversation-anchored Proactive AI cap doesn't actually control insight/memory volume well — directly affects whether that cap design (pricing handoff, formed2forge/handoffs omi-pricing.md §4/§5/§7/§14) is viable.
Fix identified: add insights_gained/memories_created int fields onto the same conversation_processed event proposed in #13, emitted from backend/utils/conversations/process_conversation.py at the same call site as the existing record_usage call.
Evidence: production usage-distribution report (30-day window, 2026-07-29 to 2026-08-27) explicitly flagged this as unmeasurable from existing data, same root cause as conversation-volume.
Symptom: No way to tell whether the insights_gained/memories_created per-conversation multiplier is roughly constant or highly variable. Dividing insights_gained by user-day (as a rough per-conversation-day proxy) was explicitly checked and rejected by the production usage report as an invalid approximation, since conversation volume itself isn't measurable today (see the companion conversation_processed issue, #13).
Impact: A highly variable per-conversation insight/memory ratio would mean a conversation-anchored Proactive AI cap doesn't actually control insight/memory volume well — directly affects whether that cap design (pricing handoff, formed2forge/handoffs omi-pricing.md §4/§5/§7/§14) is viable.
Fix identified: add insights_gained/memories_created int fields onto the same conversation_processed event proposed in #13, emitted from backend/utils/conversations/process_conversation.py at the same call site as the existing record_usage call.
Evidence: production usage-distribution report (30-day window, 2026-07-29 to 2026-08-27) explicitly flagged this as unmeasurable from existing data, same root cause as conversation-volume.