@ak--47/dungeon-master 1.3.0 → 1.4.0

package/dungeons/vertical/insurance-application.js

@@ -1,7 +1,7 @@
 // ── TWEAK THESE ──
 const SEED = "dm4-insurance";
-const num_days = 100;
-const num_users = 5_000;
+const num_days = 120;
+const num_users = 15_000;
 const avg_events_per_user_per_day = 1.2;
 let token = "your-mixpanel-token";
 
@@ -52,100 +52,148 @@ const chance = u.initChance(SEED);
 
 /*
  * ===================================================================
- * ANALYTICS HOOKS
+ * ANALYTICS HOOKS (5 hooks)
+ *
+ * Adds 5. APPLICATION COMPLETION TIME-TO-CONVERT: business 0.74x faster,
+ * family 1.3x slower (funnel-post). Discover via funnel median TTC by account_type.
+ * NOTE (funnel-post measurement): visible only via Mixpanel funnel median TTC.
+ * Cross-event MIN→MIN SQL queries on raw events do NOT show this.
  * ===================================================================
  *
+ * NOTE: All cohort effects are HIDDEN — no flag stamping. Discoverable
+ * via raw-prop breakdowns (date, app_version, issue_category) or
+ * behavioral cohorts.
+ *
  * -------------------------------------------------------------------
- * 1. VERSION STAMPING (everything hook)
+ * 1. VERSION STAMPING (everything)
  * -------------------------------------------------------------------
- * Every event gets a deterministic app_version based on its final
- * timestamp. Uses the everything hook (not event hook) because funnel
- * events adjust their time AFTER the event hook runs.
- * All users shift simultaneously on release dates:
+ *
+ * PATTERN: Every event gets a deterministic app_version based on its
+ * final timestamp. All users shift simultaneously on release dates:
  *   - Days 0-30:    v2.10
  *   - Days 30-60:   v2.11
  *   - Days 60-90:   v2.12
  *   - Last 10 days: v2.13
+ * app_version is a real product property already in superProps.
+ *
+ * HOW TO FIND IT IN MIXPANEL:
+ *
+ *   Report 1: Event Volume by App Version
+ *   - Report type: Insights
+ *   - Event: "page viewed"
+ *   - Measure: Total
+ *   - Breakdown: "app_version"
+ *   - Line chart by day
+ *   - Expected: clean cutovers between versions, no overlap
  *
- * MIXPANEL REPORT:
- *   1. Insights > "page viewed" > Breakdown by app_version
- *   2. Chart event volume over time, colored by app_version
- *   3. Confirm: no overlap between versions (deterministic cutover)
+ * REAL-WORLD ANALOGUE: Forced auto-update SaaS apps cut all users over
+ * on release day, producing crisp version bands.
  *
  * -------------------------------------------------------------------
- * 2. SUPPORT TICKET VOLUME DROP (everything hook)
+ * 2. SUPPORT TICKET VOLUME DROP (everything)
  * -------------------------------------------------------------------
- * Before v2.13, support ticket volume is high — each user gets 2-3
- * extra tickets injected with bug-related categories (form_crash,
- * login_error, page_timeout, payment_failure). After v2.13, tickets
- * are progressively removed (30% on day 1 → 85% on day 10).
  *
- * MIXPANEL REPORT:
- *   1. Insights > "support ticket created" count over time (line chart)
- *   2. Break down by app_version: v2.12 has high volume, v2.13 drops
- *   3. Filter issue_category to bug categories (form_crash, etc.)
- *   4. Filter pre_release_bug = true for injected tickets only
- *   5. Compare weekly ticket volume before vs after v2.13 release
+ * PATTERN: Pre-v2.13: each user gets 2-3 extra cloned support-ticket
+ * created events with bug-related issue_category values (form_crash,
+ * login_error, page_timeout, payment_failure — added to event config).
+ * Post-v2.13: tickets progressively removed (30% day 1 → 85% day 10).
+ * No flag — discover via issue_category breakdown over time.
+ *
+ * HOW TO FIND IT IN MIXPANEL:
+ *
+ *   Report 1: Ticket Volume Over Time
+ *   - Report type: Insights
+ *   - Event: "support ticket created"
+ *   - Measure: Total
+ *   - Breakdown: "app_version"
+ *   - Line chart by day
+ *   - Expected: high volume on v2.12, sharp drop on v2.13
+ *
+ *   Report 2: Bug Category Share Pre vs Post v2.13
+ *   - Report type: Insights
+ *   - Event: "support ticket created"
+ *   - Measure: Total
+ *   - Breakdown: "issue_category"
+ *   - Compare pre-v2.13 vs v2.13 date ranges
+ *   - Expected: form_crash / login_error / page_timeout / payment_failure
+ *     dominate pre-v2.13, vanish post-v2.13
+ *
+ * REAL-WORLD ANALOGUE: A UX-fix release reduces ticket volume overnight.
  *
  * -------------------------------------------------------------------
- * 3. APPLICATION CONVERSION BOOST (everything hook)
+ * 3. APPLICATION CONVERSION BOOST (everything)
  * -------------------------------------------------------------------
- * Before v2.13, 40% of "application approved" and "policy activated"
- * events are removed, simulating a broken application flow. After
- * v2.13, all events are preserved — creating a visible conversion jump.
  *
- * MIXPANEL REPORT:
- *   1. Funnels > application submitted → approved → policy activated
- *   2. Break down by app_version (v2.12 vs v2.13)
- *   3. Compare conversion rates: pre-v2.13 ~60% of post-v2.13
- *   4. Insights > "application approved" count over time — step change
+ * PATTERN: Pre-v2.13: ~95% of users have ALL their application approved +
+ * policy activated events dropped (per-user gating). Post-v2.13: kept.
+ * No flag — discover via funnel by app_version or volume line chart over time.
  *
- * ===================================================================
- * EXPECTED METRICS SUMMARY
- * ===================================================================
+ * HOW TO FIND IT IN MIXPANEL:
  *
- * Hook                    | Metric                  | Pre-v2.13 | Post-v2.13
- * ------------------------|-------------------------|-----------|----------
- * Version Stamping        | Events per version      | ~30d each | 10 days
- * Support Ticket Volume   | Weekly ticket count     | HIGH      | ~70% lower
- * Application Conversion  | Approval rate           | ~42%      | ~70%
+ *   Report 1: Application Funnel by Version
+ *   - Report type: Funnels
+ *   - Steps: "application submitted" -> "application approved" -> "policy activated"
+ *   - Breakdown: "app_version"
+ *   - Expected: post-v2.13 ~ 1.3x pre-v2.13 conversion rate
+ *     (~58% v2.13 vs ~44% v2.12; some dilution because users span versions)
  *
- * ===================================================================
- * ADVANCED ANALYSIS IDEAS
- * ===================================================================
+ * REAL-WORLD ANALOGUE: A buggy multi-step form fixed by release.
+ *
+ * -------------------------------------------------------------------
+ * 4. APPLICATION-STEP MAGIC NUMBER (everything)
+ * -------------------------------------------------------------------
+ *
+ * PATTERN: Users with 8-14 application step completed events sit in the
+ * sweet spot — approved_premium boosted +35%. Users with 15+ steps
+ * are over-engaged (likely fraud or signal review); 40% of their
+ * application approved events drop. No flag.
  *
- * 1. Version Impact Dashboard: Chart both support tickets AND
- *    application conversion by app_version to show v2.13's dual impact.
+ * HOW TO FIND IT IN MIXPANEL:
  *
- * 2. Bug Category Analysis: Which pre_release_bug categories were most
- *    common? Do they correlate with the application steps where users
- *    were dropping off?
+ *   Report 1: Avg Approved Premium by Step Bucket
+ *   - Report type: Insights (with cohort)
+ *   - Cohort A: users with 8-14 "application step completed"
+ *   - Cohort B: users with 0-7
+ *   - Event: "application approved"
+ *   - Measure: Average of "approved_premium"
+ *   - Expected: A ~ 1.35x B
  *
- * 3. Platform Comparison: Did the v2.13 improvement affect all platforms
- *    equally, or did web/iOS/Android see different magnitudes?
+ *   Report 2: Approvals per User on Heavy Step-Completers
+ *   - Report type: Insights (with cohort)
+ *   - Cohort C: users with >= 15 "application step completed"
+ *   - Cohort A: users with 8-14
+ *   - Event: "application approved"
+ *   - Measure: Total per user
+ *   - Expected: C ~ 40% fewer approvals per user vs A
  *
- * 4. Insurance Type Breakdown: Are certain insurance types (auto vs home
- *    vs life) more affected by the conversion improvement?
+ * REAL-WORLD ANALOGUE: Engaged applicants get higher premiums approved;
+ * over-engaged ones look like fraud and get flagged.
+ *
+ * ===================================================================
+ * EXPECTED METRICS SUMMARY
+ * ===================================================================
  *
- * 5. Time-to-Approval: Did v2.13 also change the approval_time_hours
- *    distribution, or just the volume of approvals?
+ * Hook                    | Metric                  | Baseline | Effect  | Ratio
+ * ------------------------|-------------------------|----------|---------|------
+ * Version Stamping        | Events per version      | n/a      | clean   | bands
+ * Support Ticket Volume   | tickets v2.12 -> v2.13  | 1x       | ~ 0.3x  | -70%
+ * Application Conversion  | approval rate pre/post  | 1x       | ~ 1.3x  | step-up
+ * Step-Count Magic Number | sweet approved_premium  | 1x       | 1.35x   | 1.35x
+ * Step-Count Magic Number | over approvals/user     | 1x       | 0.6x    | -40%
  */
 
-// ── Time constants for hook calculations ──
-const NOW = dayjs();
-const DATASET_START = NOW.subtract(num_days, "days");
-const V211_DATE = DATASET_START.add(30, "days");
-const V212_DATE = DATASET_START.add(60, "days");
-const V213_DATE = NOW.subtract(10, "days");
-
 /** @type {Config} */
 const config = {
+	version: 2,
 	token,
 	seed: SEED,
-	numDays: num_days,
+	datasetStart: "2026-01-01T00:00:00Z",
+	datasetEnd: "2026-05-01T23:59:59Z",
+	// numDays: num_days,
 	avgEventsPerUserPerDay: avg_events_per_user_per_day,
 	numUsers: num_users,
-	hasAnonIds: false,
+	hasAnonIds: true,
+	avgDevicePerUser: 2,
 	hasSessionIds: true,
 	format: "json",
 	gzip: true,
@@ -179,6 +227,7 @@ const config = {
 			event: "account created",
 			weight: 1,
 			isFirstEvent: true,
+			isAuthEvent: true,
 			properties: {
 				signup_source: ["web", "mobile", "agent_referral", "partner"],
 				account_type: ["individual", "family", "business"],
@@ -328,10 +377,13 @@ const config = {
 					"coverage",
 					"technical",
 					"policy_change",
+					"form_crash",
+					"login_error",
+					"page_timeout",
+					"payment_failure",
 				],
 				priority: ["low", "medium", "medium", "high"],
 				channel: ["chat", "phone", "email", "web_form"],
-				pre_release_bug: [false],
 			},
 		},
 		{
@@ -477,12 +529,39 @@ const config = {
 	 *    are left intact, making the conversion visibly jump up.
 	 */
 	hook: function (record, type, meta) {
+		// HOOK 5 (T2C): APPLICATION COMPLETION TIME-TO-CONVERT (funnel-post)
+		// Business accounts complete the Application Completion funnel 1.35x
+		// faster (factor 0.74); family accounts 1.3x slower (factor 1.3).
+		if (type === "funnel-post") {
+			const profile = meta?.profile;
+			const accountType = profile && profile.account_type;
+			if (Array.isArray(record) && record.length > 1) {
+				const factor = (
+					accountType === "business" ? 0.74 :
+					accountType === "family" ? 1.3 :
+					1.0
+				);
+				if (factor !== 1.0) {
+					for (let i = 1; i < record.length; i++) {
+						const prev = dayjs(record[i - 1].time);
+						const newGap = Math.round(dayjs(record[i].time).diff(prev) * factor);
+						record[i].time = prev.add(newGap, "milliseconds").toISOString();
+					}
+				}
+			}
+		}
+
 		// =============================================================
 		// Hooks #1-#3 all run in the "everything" hook so that version
 		// stamping sees final timestamps (funnel events adjust time
 		// AFTER the event hook runs).
 		// =============================================================
 		if (type === "everything") {
+			const datasetStart = dayjs.unix(meta.datasetStart);
+			const datasetEnd = dayjs.unix(meta.datasetEnd);
+			const V211_DATE = datasetStart.add(30, "days");
+			const V212_DATE = datasetStart.add(60, "days");
+			const V213_DATE = datasetEnd.subtract(10, "days");
 			const userEvents = record;
 			if (userEvents.length === 0) return record;
 
@@ -570,7 +649,6 @@ const config = {
 							"email",
 							"web_form",
 						]),
-						pre_release_bug: true,
 					});
 				}
 			}
@@ -602,16 +680,36 @@ const config = {
 			}
 
 			// ─── Hook #3: APPLICATION CONVERSION BOOST ───
-			// PRE-V2.13: Remove ~40% of application approved and policy activated
-			// events, lowering effective conversion before the release.
-			for (let i = userEvents.length - 1; i >= 0; i--) {
-				const evt = userEvents[i];
-				if (
-					(evt.event === "application approved" ||
-						evt.event === "policy activated") &&
-					dayjs(evt.time).isBefore(V213_DATE)
-				) {
-					if (chance.bool({ likelihood: 40 })) {
+			// PRE-V2.13: Remove ALL application approved + policy activated events
+			// for ~80% of users (per-user gating, not per-event). This produces
+			// visible funnel completion gap pre-v2.13 vs post-v2.13.
+			if (chance.bool({ likelihood: 95 })) {
+				for (let i = userEvents.length - 1; i >= 0; i--) {
+					const evt = userEvents[i];
+					if (
+						(evt.event === "application approved" ||
+							evt.event === "policy activated") &&
+						dayjs(evt.time).isBefore(V213_DATE)
+					) {
+						userEvents.splice(i, 1);
+					}
+				}
+			}
+
+			// Hook 4: APPLICATION-STEP MAGIC NUMBER (no flags)
+			// Sweet 8-14 application step completed → +35% on approved_premium
+			// for application approved events. Over 15+ → drop 40% of
+			// application approved events (fraud filter triggers).
+			const stepCount = userEvents.filter(e => e.event === "application step completed").length;
+			if (stepCount >= 8 && stepCount <= 14) {
+				userEvents.forEach(e => {
+					if (e.event === "application approved" && typeof e.approved_premium === "number") {
+						e.approved_premium = Math.round(e.approved_premium * 1.35);
+					}
+				});
+			} else if (stepCount >= 15) {
+				for (let i = userEvents.length - 1; i >= 0; i--) {
+					if (userEvents[i].event === "application approved" && chance.bool({ likelihood: 40 })) {
 						userEvents.splice(i, 1);
 					}
 				}

package/dungeons/vertical/logistics.js

@@ -1,7 +1,7 @@
 // ── TWEAK THESE ──
 const SEED = "dm4-logistics";
-const num_days = 100;
-const num_users = 5_000;
+const num_days = 120;
+const num_users = 10_000;
 const avg_events_per_user_per_day = 1.2;
 let token = "your-mixpanel-token";
 
@@ -16,9 +16,6 @@ import * as v from "ak-tools";
 
 dayjs.extend(utc);
 const chance = u.initChance(SEED);
-const NOW = dayjs();
-const DATASET_START = NOW.subtract(num_days, "days");
-
 /** @typedef  {import("../../types").Dungeon} Config */
 
 // Generate consistent warehouse/supplier IDs at module level
@@ -34,7 +31,7 @@ const supplierIds = v.range(1, 150).map(() => `SUP_${v.uid(6)}`);
  * businesses to track stock levels, purchase orders, suppliers,
  * shipments, and quality inspections across multiple warehouses.
  *
- * - 5,000 users over 100 days, ~600K events
+ * - 10,000 users over 120 days
  * - Multi-tier system: enterprise (15%), mid-market (35%), small business (40%), trial (10%)
  * - Core loop: sign up -> check inventory -> create PO -> receive order -> track shipment
  * - Revenue: free_trial / starter ($49) / professional ($199) / enterprise ($599)
@@ -56,14 +53,19 @@ const supplierIds = v.range(1, 150).map(() => `SUP_${v.uid(6)}`);
 
 /**
  * ===================================================================
- * ANALYTICS HOOKS (8 hooks)
+ * ANALYTICS HOOKS (10 hooks)
+ *
+ * Adds 10. ONBOARDING TIME-TO-CONVERT: enterprise 0.71x faster, small_business
+ * 1.3x slower (funnel-post). Discover via Onboarding funnel median TTC by company_tier.
+ * NOTE (funnel-post measurement): visible only via Mixpanel funnel median TTC.
+ * Cross-event MIN→MIN SQL queries on raw events do NOT show this.
  * ===================================================================
  *
  * -------------------------------------------------------------------
  * 1. MONTH-END REPORTING SURGE (event hook)
  * -------------------------------------------------------------------
  *
- * PATTERN: Reports generated on calendar days 28-31 have 2x the
+ * PATTERN: Reports generated on calendar days 28-31 have 2.5x the
  * report_pages. Simulates end-of-month compliance and audit reporting.
  *
  * HOW TO FIND IT IN MIXPANEL:
@@ -123,6 +125,15 @@ const supplierIds = v.range(1, 150).map(() => `SUP_${v.uid(6)}`);
  *   - Breakdown: user property "company_tier"
  *   - Expected: enterprise ratio ~0.9x vs small_business baseline
  *
+ *   Report 3: Stockout-to-Inventory-Check Ratio (NORMALIZED — recommended)
+ *   - Report type: Insights (formula)
+ *   - A = "stockout alert" total, B = "inventory checked" total
+ *   - Formula: A / B
+ *   - Breakdown: user property "company_tier"
+ *   - Expected: enterprise ratio ~ 0.9x SMB ratio (10% reduction visible)
+ *   - WHY THIS METRIC: per-user counts are dominated by persona event multipliers
+ *     (enterprise has 5x baseline activity); ratio normalizes that out.
+ *
  * REAL-WORLD ANALOGUE: Enterprise operations have dedicated
  * procurement teams and predictive analytics reducing stockouts.
  *
@@ -243,6 +254,41 @@ const supplierIds = v.range(1, 150).map(() => `SUP_${v.uid(6)}`);
  * REAL-WORLD ANALOGUE: Small businesses lack dedicated IT teams,
  * leading to incomplete integration setup and lower alert adoption.
  *
+ * -------------------------------------------------------------------
+ * 9. INVENTORY-CHECK MAGIC NUMBER (everything hook)
+ * -------------------------------------------------------------------
+ *
+ * PATTERN: Users with 5-15 "inventory checked" events sit in the
+ * "engaged-but-focused" sweet spot — every "purchase order created"
+ * event gets quantity boosted ~25%. Users with 16 or more inventory
+ * checks are over-engaged (paralysis); ~30% of their "purchase order
+ * created" events are dropped. No flag is stamped — discoverable only
+ * by binning users on inventory-check COUNT and comparing PO totals.
+ *
+ * HOW TO FIND IT IN MIXPANEL:
+ *
+ *   Report 1: PO Quantity by Inventory-Check Bucket
+ *   - Report type: Insights (with cohort)
+ *   - Cohort A: users with 5-15 "inventory checked" events
+ *   - Cohort B: users with 0-4 "inventory checked" events
+ *   - Event: "purchase order created"
+ *   - Measure: Average of "quantity"
+ *   - Compare cohort A vs cohort B
+ *   - Expected: cohort A ~ 1.25x higher quantity than B
+ *
+ *   Report 2: POs per User by Browse Intensity
+ *   - Report type: Insights (with cohort)
+ *   - Cohort C: users with >= 16 "inventory checked" events
+ *   - Cohort A: users with 5-15 "inventory checked" events
+ *   - Event: "purchase order created"
+ *   - Measure: Total events per user
+ *   - Compare cohort C vs cohort A
+ *   - Expected: cohort C has ~ 30% fewer POs per user
+ *
+ * REAL-WORLD ANALOGUE: A focused operations team that monitors
+ * stock just enough places larger, more confident orders; an
+ * obsessive checker is paralysed and orders less.
+ *
  * ===================================================================
  * EXPECTED METRICS SUMMARY
  * ===================================================================
@@ -256,17 +302,23 @@ const supplierIds = v.range(1, 150).map(() => `SUP_${v.uid(6)}`);
  * Alert Fatigue               | response_time_hours | 4h       | 8-12h   | 2-3x
  * Trial Churn                 | events after wk 1   | 5        | 2.5     | 0.5x
  * Enterprise Profiles         | warehouse_count     | 3        | 10      | 3.3x
- * Small-Biz Conversion Drop  | funnel conversion   | 30%      | 20%     | 0.65x
+ * Small-Biz Conversion Drop   | funnel conversion   | 30%      | 20%     | 0.65x
+ * Inventory-Check Magic Num   | sweet PO quantity   | 1x       | 1.25x   | 1.25x
+ * Inventory-Check Magic Num   | over POs/user       | 1x       | 0.7x    | -30%
  */
 
 /** @type {Config} */
 const config = {
+	version: 2,
 	token,
 	seed: SEED,
-	numDays: num_days,
+	datasetStart: "2026-01-01T00:00:00Z",
+	datasetEnd: "2026-05-01T23:59:59Z",
+	// numDays: num_days,
 	avgEventsPerUserPerDay: avg_events_per_user_per_day,
 	numUsers: num_users,
-	hasAnonIds: false,
+	hasAnonIds: true,
+	avgDevicePerUser: 2,
 	hasSessionIds: true,
 	format: "json",
 	gzip: true,
@@ -299,6 +351,7 @@ const config = {
 			event: "account created",
 			weight: 1,
 			isFirstEvent: true,
+			isAuthEvent: true,
 			properties: {
 				referral_source: ["organic", "partner_referral", "google_search", "trade_show", "linkedin"],
 			},
@@ -691,6 +744,27 @@ const config = {
 
 	// -- Hook Function ------------------------------------------------
 	hook: function (record, type, meta) {
+		// HOOK 10 (T2C): ONBOARDING TIME-TO-CONVERT (funnel-post)
+		// Enterprise tier completes Onboarding funnel 1.4x faster (factor 0.71);
+		// small_business 1.3x slower (factor 1.3).
+		if (type === "funnel-post") {
+			const segment = meta?.profile?.company_tier;
+			if (Array.isArray(record) && record.length > 1) {
+				const factor = (
+					segment === "enterprise" ? 0.71 :
+					segment === "small_business" || segment === "trial" ? 1.3 :
+					1.0
+				);
+				if (factor !== 1.0) {
+					for (let i = 1; i < record.length; i++) {
+						const prev = dayjs(record[i - 1].time);
+						const newGap = Math.round(dayjs(record[i].time).diff(prev) * factor);
+						record[i].time = prev.add(newGap, "milliseconds").toISOString();
+					}
+				}
+			}
+		}
+
 		// -- HOOK 7: ENTERPRISE PROFILES (user) -----------------------
 		// Enterprise ops get large warehouse_count and employee_count.
 		if (type === "user") {
@@ -700,6 +774,9 @@ const config = {
 			} else if (record.company_tier === "mid_market") {
 				record.warehouse_count = chance.integer({ min: 2, max: 6 });
 				record.employee_count = chance.integer({ min: 20, max: 200 });
+			} else if (record.company_tier === "small_business") {
+				record.warehouse_count = chance.integer({ min: 1, max: 3 });
+				record.employee_count = chance.integer({ min: 5, max: 80 });
 			} else if (record.company_tier === "trial") {
 				record.warehouse_count = 1;
 				record.employee_count = chance.integer({ min: 1, max: 10 });
@@ -747,7 +824,7 @@ const config = {
 				if (e.event === 'report generated') {
 					const dayOfMonth = new Date(e.time).getUTCDate();
 					if (dayOfMonth >= 28) {
-						e.report_pages = Math.floor((e.report_pages || 20) * 2);
+						e.report_pages = Math.floor((e.report_pages || 20) * 2.5);
 					}
 				}
 			}
@@ -823,6 +900,24 @@ const config = {
 				}
 			}
 
+			// -- HOOK 9: INVENTORY-CHECK MAGIC NUMBER (no flags) ------
+			// Sweet 5-15 inventory checks → +25% PO quantity.
+			// Over 16+ → drop 45% of PO created events.
+			const invCheckCount = record.filter(e => e.event === 'inventory checked').length;
+			if (invCheckCount >= 5 && invCheckCount <= 15) {
+				record.forEach(e => {
+					if (e.event === 'purchase order created' && typeof e.quantity === 'number') {
+						e.quantity = Math.round(e.quantity * 1.25);
+					}
+				});
+			} else if (invCheckCount >= 16) {
+				for (let i = record.length - 1; i >= 0; i--) {
+					if (record[i].event === 'purchase order created' && chance.bool({ likelihood: 45 })) {
+						record.splice(i, 1);
+					}
+				}
+			}
+
 			return record;
 		}