Rami Ruhayel rami-ruhayel-vgw

Permissions Service: Proposal and Enforcement Gap Analysis

Context

An investigation of the game client's feature toggle and configuration system uncovered a broader issue: business rule authorization (market exits, self-exclusion, purchase limits) is enforced almost entirely client-side. Backend services accept requests from any authenticated user regardless of market status, self-exclusion state, or purchase limits.

This document summarizes the findings and proposes a centralized permission service that all backend services call before allowing restricted actions.

A full design document covering the complete toggle inventory, permission model, Kotlin implementation, test strategy, and phased rollout plan is in progress and will be submitted as a PR to gp-game-client (docs/features/feature-toggle-and-config-migration.md).

Welcome Offer A/B Test - Delivery Plan

Dependencies

graph LR
  S1["Story 1: Source attribution"]
  S2["Story 2: Bucketing"]
  S3["Story 3: Data-driven popup"]
 S4["Story 4: Exposure tracking"]

GeoComply E2E Test Plan (POK-26687)

Review Status

Plan reviewed by automated QA expert agent. Key changes incorporated:

Must fix (done):

Split GeoErrorPage into EnableLocationPage and RestrictedLocationPage page objects
Fixed GeoPromptOverlay.dismiss selector (was the checkbox, not a button)
Added location_lost reason to Slice 3 failure redirect tests

GeoComply Rollout Observability Roadmap

Context

Geo analytics events serve two systems for different purposes:

Loki (operational): "Is the geo flow healthy right now?" Aggregate rates, real-time alerts, engineer audience.
Snowflake (analytical): "What is geo doing to our players over time?" Per-player, historical, joins with other domains, PM/analyst/compliance audience.

See first-time-repeat-player-analysis.md for the full investigation and data pipeline architecture.

First-Time vs Repeat Player Tracking: Analysis

Problem Statement

Every geo-location metric today is a blended average. A 15% verification failure rate could mean 40% of new players fail (catastrophic for growth) and 5% of returning players fail (normal friction). There is no way to distinguish first-time players from returning players in the current event stream.

When the canary goes from 5% to 100%, 95% of active players hit geo for the first time. Without segmentation, operational dashboards become unreadable.

Two systems, two purposes

Geo Event Instrumentation Addendum: Unified Alerts, Snowflake Path, CloudFront Geo

Status: Loki instrumentation (events, dashboard, alerts, simulator) is in draft PRs awaiting review. Snowflake integration and CloudFront geo fix are proposed but not yet implemented.

Companion addendum: KPI Addendum (Loki vs Snowflake, data pipeline, first-time/repeat segmentation)

Builds on: Technical Approach which covers sink abstraction, event payloads, dashboard panels, and simulator.

Deep-dive: Data Pipeline Investigation (full lineage traces, VGW data platform inventory, root cause analysis) >

GeoComply KPI Addendum: Data Pipeline Architecture + Rollout Observability

Status: Proposed. Findings from data pipeline investigation during V1 instrumentation work.

Companion addendum: Technical Approach Addendum (unified alerts, Snowflake integration path, CloudFront geo root cause)

Builds on: KPI Instrumentation Analysis which covers event model, state machines, funnel, and KPI definitions.

Deep-dive: Data Pipeline Investigation (full lineage traces, VGW data platform inventory, root cause analysis) >

E2E Test Account Shopping List

Each environment needs its own unique accounts. Do not reuse accounts across environments.

What we handle (no QA action needed)

CI bot, recovery, TC accounts - already exist
QC bot, recovery, TC accounts - we'll create via script (whitelisted phone works in QC)
CI Facebook/Google accounts - keeping existing ones assigned to CI

Welcome Offer A/B Test - Investigation

Companion document: Delivery Plan (stories, tasks, dependencies, timeline)

Summary

We want to test whether a lower-priced Welcome Offer ($10/SC20) converts better than the current offer ($20/SC40) for new registrations. The infrastructure to support this exists in part and requires a small backend change and a client update. Estimated effort: ~1-2 days backend, ~2-3 days client. The test can be stopped at any time without a deploy by deactivating the variant package.

Agreed test parameters (from meeting 2026-03-27):

10% minimum detectable effect (relative), two-sided test (two-sided because we also want to detect if the cheaper offer converts worse, to limit costs)

	[
	{
	"key": "AK",
	"latitude": 61.385,
	"longitude": -152.2683,
	"name": "Alaska"
	},
	{
	"key": "AL",
	"latitude": 32.799,