💡 Longitudinal decision-outcome attribution journal for beekeeper skill development

[github-actions[bot]]

Summary

Build a decision-outcome tracking system that links beekeeper decisions (treatments applied, inspections deferred, splits performed) to measurable colony outcomes (mite counts, population changes, honey yield, survival) across time. Generate personalized seasonal retrospectives showing decision-action-outcome chains with statistical attribution, turning Broodly from a management tool into a learning engine.

Market Signal

• Scientific Beekeeping research shows beekeepers who track mite-wash counts and treatment dates per hive have markedly lower winter losses than those relying on memory
• Beekeeping Diary offers AI condition analysis of current state but no longitudinal tracking
• No competitor provides decision-outcome attribution across seasons
• 75% of Broodly's target metric is "helps me decide confidently" — learning from your own outcomes directly builds decision confidence
• HiveLog AI catches varroa infestations 2-3 weeks earlier via photo analysis, but doesn't close the loop on whether the beekeeper acted on that information

Sources: Best Beekeeping Apps 2026, HiveLog AI

User Signal

Existing idea #367 proposes AI-generated colony story timelines (narrative format). This proposal focuses specifically on causal decision-outcome analysis: "you delayed treatment by 2 weeks in 5 hives; 3 of those showed 40%+ higher mite counts at next check." Directly addresses the PRD's edge case of trust recovery when a recommendation leads to a bad outcome — transparent decision replay is the mechanism.

The PRD's measurable outcome target — "season-over-season improvement in the ratio of recommended-action-taken to recommended-action-ignored for high-priority items" — requires exactly this data infrastructure.

Technical Opportunity

Broodly's architecture already mandates:

• Recommendation traceability and evidence audit trails (immutable audit event log)
• Event schema with event_id, event_type, actor_id, occurred_at, payload (JSONB)
• Recommendation contract requiring action + rationale + confidence + fallback

The decision-outcome journal is an analytics layer on top of existing event streams:

1. recommendation_shown event → what was suggested
2. user_action_taken event → what the beekeeper actually did
3. inspection_outcome event → what happened at the next check

PostgreSQL + pgvector enables semantic similarity searches across decision patterns for cross-hive and cross-season insights.

Assessment

Dimension	Score	Rationale
Feasibility	high	Analytics on existing event data. Schema design is the main work — no new integrations needed.
Impact	high	Unique capability. Transforms management tool into learning engine. Directly serves PRD success metrics.
Urgency	med	Data collection should start early so value compounds over time, but insights require accumulated data.

Adversarial Review

Strongest objection: Requires multiple seasons of data for meaningful longitudinal insights. Colony outcomes have many causes (weather, genetics, forage) — attributing outcomes to specific decisions risks misleading beekeepers with spurious correlations.

Rebuttal: Start small: even after one month, "your treatment timing vs. recommended timing" is valuable. Frame insights as correlations with confidence scores, not causal claims: "Hives where you followed recommendations had X% better outcomes (moderate confidence, N=5)." The PRD already requires confidence scoring on all recommendations — apply the same principle to retrospective analysis. Seasonal value grows with each data cycle.

Suggested Next Step

Design the decision-event schema that captures recommendation-shown, user-action-taken, and outcome-measured triplets. Define the minimum data requirements for generating a meaningful first retrospective (e.g., 4 inspections across 2+ hives with at least 1 treatment decision). Ensure the audit event log schema accommodates these event types from day one.