{ "date": "2026-10-01", "scope": "Implemented foundation; described acceptance boundaries remain", "implementationItems": 121, "areas": [ { "id": "accounts", "title": "Player accounts, authentication and privacy", "category": "Player foundation", "why": "An operator needs one accountable view of the customer across play, account servicing and responsible gambling.", "flow": "A customer signs in, the API establishes their identity and permissions, and account views read the same platform records used by betting and games.", "done": [ "Registration and login endpoints, bearer-token sessions and account profile surfaces.", "Player two-factor enrolment, one-time codes, recovery paths and brand-level authentication policy.", "Account summary, betting history, transaction history and player activity statements.", "Profile and verification workflows with recorded identity decisions.", "Player data export for access requests and an anonymisation workflow with explicit refusal conditions.", "Retention of financial and exclusion records alongside destruction of defined identity fields.", "Registration checks against retained erased-identity hashes to support exclusion controls." ], "value": "The customer experience and staff account review use the same source of truth. An operator can demonstrate what a player saw and how an account decision was made.", "boundary": "A production identity provider, privacy/retention policy and the actual operator’s legal responsibilities still need acceptance.", "evidence": [ "backend/tests/Feature/AuthHardeningTest.php", "backend/tests/Feature/TwoFactorAuthTest.php", "docs/marketing-spec/12-security-trust.md" ] }, { "id": "wallet", "title": "Wallet, ledger and movement controls", "category": "Financial core", "why": "A balance is useful only when every movement can be explained and retries or concurrent actions cannot create a second spend.", "flow": "A funded action goes through the wallet service, records its transaction and updates the account projection. Reconciliation provides a separate check of the resulting position.", "done": [ "Cash and bonus balance handling behind the central wallet service.", "Credit, debit and transaction history with references to the action that moved the balance.", "Insufficient-funds refusals and bounded movement/balance arithmetic.", "Bonus credit, bonus-to-cash conversion and reversal handling.", "Ledger reconciliation command and supporting integrity tests.", "Withdrawal workflow, approval controls and policy checks.", "Concurrency and retry probes for a controlled play-credit deployment.", "Seamless-wallet integration support for third-party game transactions." ], "value": "Finance, support and compliance can investigate an account movement from its ledger evidence rather than a displayed number alone.", "boundary": "Demo transactions do not establish live banking, funds protection, payment underwriting or production reconciliation operations.", "evidence": [ "backend/app/Services/Wallet/WalletService.php", "backend/tests/Feature/WalletTest.php", "backend/tests/Feature/LedgerAuditCommandTest.php", "tools/concurrency.mjs" ] }, { "id": "sportsbook", "title": "Sportsbook and customer betting journeys", "category": "Sports product", "why": "Operators need coverage that a customer can navigate and betting behaviour that remains consistent when prices change.", "flow": "The customer moves from a sport to a league, coupon and event, builds their selections, reviews the current quote and submits to the platform’s betting controls.", "done": [ "Sport, league, competition, coupon and full-event browsing surfaces.", "Pre-match and in-play views over the configured market data.", "Market and selection structures with prices and line information.", "Betslip, stake calculation and multiple-selection betting flows.", "Correlation-adjusted same-game pricing, with naive and adjusted quotes available for comparison.", "System-bet combination expansion in the front-end engine, including traditional structures from Trixie through Lucky 63.", "Server-side price-change re-offers instead of silently accepting a different quoted price.", "Open and settled bet history and cash-out quote/acceptance workflows." ], "value": "The platform supports both a dense sportsbook interface and a broader casino-led brand. A customer-specific front end can use the same betting API.", "boundary": "System bets expand into ordinary API bet lines; a bespoke client must implement or reuse that expansion. Market availability, live data rights and official settlement depend on the accepted feed scope.", "evidence": [ "docs/marketing-spec/03-feature-sportsbook.md", "backend/tests/Feature/BettingTest.php", "backend/tests/Feature/CashOutReofferTest.php", "tools/engine-tests.mjs" ] }, { "id": "trading", "title": "Odds, pricing, risk and settlement", "category": "Trading foundation", "why": "A sportsbook needs to control aggregate exposure and establish how a result was obtained, alongside offering attractive customer prices.", "flow": "Provider prices are stored and selected by a configured strategy. Betting checks the permitted exposure; settlement records the result and credits through the wallet.", "done": [ "Multi-provider odds interfaces and provider-specific adapters.", "Stored bookmaker prices that can be repriced without another feed fetch.", "Best-price and prioritised-bookmaker pricing strategies.", "Feed freshness and credit/quota-aware synchronisation controls.", "Trading configuration, maximum-payout and stake-risk controls.", "Selection liability reporting and scheduled liability sweep/suspension logic.", "Cash-out repricing and race-related test coverage.", "Official-result settlement integration and documented result provenance.", "A separately controlled synthetic demo fallback that must remain disabled for a regulated real-event deployment." ], "value": "A trader can examine what was priced, what was accepted and how it was settled. The logic is accessible through the API as well as the operator workspace.", "boundary": "Pricing data is not automatically settlement-grade data. Current demo feed quotas and deployment configuration must be checked; the presence of an adapter does not grant commercial data rights.", "evidence": [ "backend/app/Services/Odds/OddsManager.php", "backend/app/Services/Settlement/SettlementService.php", "backend/tests/Feature/TradingControlsTest.php", "backend/tests/Feature/SyntheticSettlementCertificationTest.php" ] }, { "id": "games", "title": "In-house games and game mathematics", "category": "Game estate", "why": "Owning the game implementation allows the team to show its rules, mathematics and evidence directly, while taking responsibility for independent evaluation.", "flow": "The game accepts a funded action, applies the engine rules, resolves the outcome, records the round and settles its wallet movement. Published rules and return information must match that engine.", "done": [ "House-banked and instant-play implementations spanning card, table, number and arcade-style games.", "Game controller entry points for blackjack, baccarat, roulette, craps, Sic Bo, poker variants, bingo and keno.", "Dice, limbo, mines, plinko, wheel, coin flip, hi-lo, scratch, crash and tower-style game implementations.", "Sport-themed games including penalty shootout, snooker and cricket, plus virtual racing capability.", "Slot mathematics and configurable variants, including a five-reel entry point.", "Advertised-return checks against the engine’s mathematics and constants.", "Game rules and return disclosures delivered with the game catalogue.", "Seed commitment/reveal and round-verification mechanisms, with determinism and statistical test coverage." ], "value": "A prospective customer or test house can evaluate the implementation behind the product. The public catalogue distinguishes controller boundaries from commercial title counts.", "boundary": "Internal tests and round verification do not certify the games. The first commercial game slate must be identified, frozen and independently evaluated within its applicable scope.", "evidence": [ "backend/tests/Feature/AdvertisedRtpTest.php", "backend/tests/Feature/GameEngineCertificationTest.php", "docs/marketing-spec/04-feature-casino.md" ] }, { "id": "rounds", "title": "Multiplayer, tournaments, jackpots and recovery", "category": "Game operations", "why": "A complete product must deal with shared rounds, pooled value and interrupted play, as well as the happy path of a single game.", "flow": "A round or competition records participation and funded state. It either resolves normally or follows the defined recovery/abandonment policy without silently losing track of value.", "done": [ "Chinchón game and player-versus-player table implementations.", "Multiplayer state, close, outcome and rake-related test coverage.", "Shared crash-round implementation and shared-round integrity checks.", "Tournament and sit-and-go management, participation and prize workflows.", "Prize-versus-entry validation and tournament publication checks.", "Jackpot configuration and ticker/catalogue presentation.", "Active funded-round listing with resume or settlement paths.", "Abandoned-round resolution and named recovery mechanisms for different game shapes." ], "value": "Operators can review how the system behaves when a browser closes or another participant leaves, rather than judging reliability from a successful round alone.", "boundary": "Each chosen product shape needs independent fairness/integrity evaluation and operational acceptance. A multiplayer demo may require a second participant.", "evidence": [ "backend/tests/Feature/ChinchonPvpTest.php", "backend/tests/Feature/SharedCrashRoundTest.php", "backend/tests/Feature/TournamentSitAndGoTest.php", "backend/tests/Feature/AbandonedRoundResolverTest.php" ] }, { "id": "safer-play", "title": "Safer-gambling and jurisdiction controls", "category": "Player protection", "why": "A responsible-play control needs to apply at the server decision point, even if a client ignores the screen that describes it.", "flow": "The player sets a limit or exclusion. Subsequent account and funded actions consult the stored policy, and any permitted relaxation follows its configured cooling-off process.", "done": [ "Financial limits and cooling-off for relaxations.", "Reality-check sessions, acknowledgement and account-facing controls.", "Self-exclusion and time-out account workflows.", "Server-side slot cycle control and per-action game-cycle checks.", "Jurisdiction-configured stake and age-related rules.", "Withdrawal cancellation refusal within the withdrawal workflow.", "Interrupted-round and game-disclosure requirements tied into the readiness evidence.", "A compliance readiness command that separates checked controls, stubs and manual external obligations." ], "value": "These controls travel with the API rather than relying on one particular web skin. That creates a clearer foundation for customer-specific interface delivery.", "boundary": "Jurisdiction profiles still require market-specific review. Live national exclusion, identity and location providers are distinct launch work.", "evidence": [ "docs/RTS-MAP.md", "backend/app/Console/Commands/ComplianceReadinessCommand.php", "backend/tests/Feature/TwoFactorAuthTest.php" ] }, { "id": "risk", "title": "AML, identity, location and payments integration", "category": "Risk & providers", "why": "Customer verification, national exclusion and real financial movement depend on contracted external systems as well as internal workflows.", "flow": "Account and transaction activity feed risk decisions. Provider interfaces return verifiable decisions; exceptions are recorded and handled by an accountable operator role.", "done": [ "AML monitoring rules invoked around financial activity and through the scheduled monitor.", "AML case workflows, restricted withdrawals, named decisions and access checks.", "Identity-verification provider interfaces, configuration and decision records.", "National self-exclusion provider abstraction and GAMSTOP integration configuration.", "Geolocation provider abstraction and explicit fail-open/fail-closed configuration.", "Payment gateway abstraction, payment results, settlement and withdrawal services.", "Provider credential handling, instrument-policy checks and tenant-specific payment configuration.", "Linked-account/fraud review described in the operator product evidence." ], "value": "The team has implemented the internal shape of the workflows, reducing the work to build each customer integration from scratch. Operators retain responsibility for the policies and decisions.", "boundary": "Implemented drivers are not underwriting approvals or live accepted integrations. Provider eligibility must be established for gambling use and for the exact customer operating model.", "evidence": [ "backend/tests/Feature/AmlProgrammeTest.php", "backend/tests/Feature/AmlCaseAccessTest.php", "backend/config/compliance.php", "backend/app/Services/Payments/PaymentGateway.php" ] }, { "id": "crm", "title": "Segmentation, campaign automation and assisted proposals", "category": "Customer growth", "why": "An operator needs to target the right audience while applying consent and exclusion controls at the point of communication.", "flow": "Staff define a segment, preview the eligible audience, review the campaign and dispatch through the platform’s consent and exclusion handling.", "done": [ "Rule-based segmentation with all/any/none combinations.", "A recorded catalogue of 14 segmentation rule types.", "Fail-safe handling of unrecognised segmentation rules.", "Audience previews and campaign automation workflows.", "Consent and self-exclusion filtering described in the campaign implementation evidence.", "An optional AI assistant that returns a readable, editable segment proposal.", "Human actions remain separate from an assistant proposal: the assistant does not save a segment or send a campaign.", "Audience counts are resolved by platform rules rather than invented by the assistant." ], "value": "Marketing works against the same account and protection records used by the core platform, reducing the gap between a target list and the current customer state.", "boundary": "The customer must approve campaign policy, delivery-provider arrangements and any AI data-processing scope. The assistant needs a configured model service.", "evidence": [ "docs/marketing-spec/05-feature-crm.md", "backend/app/Services/Ai/SegmentAssistant.php", "backend/app/Services/Crm/SegmentService.php" ] }, { "id": "rewards", "title": "Promotions, bonuses, affiliates and loyalty", "category": "Retention & commercial tools", "why": "Reward rules and commercial incentives need to reconcile with the wallet and eligibility policy, rather than becoming a parallel account system.", "flow": "A qualifying action is evaluated against the configured conditions. A reward is granted through the account model, and any wagering, commission or tier outcome follows its own defined rules.", "done": [ "Promotion engine, condition evaluation and offer targeting.", "Bonus grants, redemption and wagering allocation workflows.", "Game contribution handling for bonus wagering.", "Reward-granting and referral services.", "Affiliate attribution and NGR-based commissioning described in the product records.", "Loyalty/VIP services and segment-related tier progression.", "Gamification events and leaderboard ranking services.", "Administrative surfaces for bonuses, referrals, tournaments and rewards." ], "value": "A customer can assemble a retention proposition around the existing platform rules and trace the resulting account movements.", "boundary": "Bonus terms, contribution settings, affiliate contracts and customer-specific incentives need review and acceptance. Revenue impact has not been established merely by implementing these features.", "evidence": [ "backend/tests/Feature/BonusEngineTest.php", "backend/tests/Feature/BonusWageringAllocationTest.php", "backend/tests/Feature/WageringContributionTest.php", "backend/tests/Feature/AffiliateTest.php" ] }, { "id": "tenancy", "title": "Multi-brand administration and staff security", "category": "Operator control", "why": "A platform that serves several brands must give an operator useful autonomy without allowing access to a sibling brand’s records.", "flow": "Each request resolves its tenant and staff identity. The API applies tenant ownership and role/capability checks before reading or changing operator data.", "done": [ "Tenant resolution, tenant settings and brand-scoped account/content records.", "Tenant provisioning service for starter product content.", "Cross-tenant ownership and isolation tests.", "Distinct platform and brand staff access models.", "Owner, manager, trader, support and read-only roles described in the product records.", "Brand-level player/staff two-factor policies and mandatory platform-staff authentication policy.", "Scoped brand settings, staff management and administrative audit.", "Shared-credential restrictions and capability hardening tests." ], "value": "The platform model supports repeatable brand setup and customer-specific operational ownership instead of a separate code fork per brand.", "boundary": "Some demo brands share a tenant. Shared market data and aggregate trading exposure are deliberate boundaries that must be documented and reviewed.", "evidence": [ "backend/tests/Feature/TenantProvisioningTest.php", "backend/tests/Feature/TenantIsolationTest.php", "backend/tests/Feature/AdminCapabilityHardeningTest.php", "docs/marketing-spec/07-feature-multitenant.md" ] }, { "id": "reporting", "title": "Reporting, audit and platform billing", "category": "Business operations", "why": "An operator and its supplier need to explain player activity, financial outcomes, staff decisions and the commercial relationship.", "flow": "Reports read the underlying account and betting records. Staff actions carry identity into the audit trail; platform billing produces invoices from the configured plan and period.", "done": [ "Operator return and player activity-statement services.", "Breakdown reporting and bet-search services.", "CSV exports and scoped operational views.", "Named-actor audit service, filtering and write-coverage tests.", "Staff identity and tenancy checks around administrative audit.", "Platform billing-plan assignment and invoice generation.", "GGR-based billing calculation and due-invoice processing.", "MRR reporting support in the platform billing service." ], "value": "The commercial model has implementation support as well as a sales description. Reports can support diligence and operational review when populated with real accepted activity.", "boundary": "Billing code is not revenue. Regulatory reports require operator validation; audit retention and privileged database access need operational evidence.", "evidence": [ "backend/app/Services/Reporting/RegulatoryReportService.php", "backend/app/Services/Platform/PlatformBillingService.php", "backend/tests/Feature/AdminWriteAuditCoverageTest.php", "backend/tests/Feature/BreakdownReportTest.php" ] }, { "id": "delivery", "title": "API, widgets, skins and custom interfaces", "category": "Product delivery", "why": "Customers should be able to choose their product experience without moving the financial and game decisions into the presentation layer.", "flow": "The browser or application calls the same API. Widgets and custom screens render the response; the platform controls the decision and records its outcome.", "done": [ "Versioned API and repository OpenAPI specification.", "Recorded inventory of 335 operations across 292 documented API paths.", "43 front-end widget files in the recorded inventory.", "Ten visual skin presets and four interface locale directories.", "WordPress/Elementor delivery route and static customer delivery route.", "Seven distinct operator-brand demonstrations.", "A custom sportsbook front end using the public API without the shared widget engine.", "Shared brand plumbing and asset synchronisation tooling.", "Partner API keys, scopes and idempotency support." ], "value": "A customer specification can combine existing platform functions with a brand-specific front end. Presentation work can evolve independently of the core rules.", "boundary": "Catalogue and API coverage do not prove every integration is accepted. Performance, accessibility, browser/device acceptance and provider configuration must be measured for the selected customer build.", "evidence": [ "docs/openapi.json", "sites/ledgerfield/stats.json", "sites/_kit/brandkit.js", "tools/sync-brand-assets.mjs" ] }, { "id": "mobile", "title": "Player, operator and sales application codebases", "category": "Application scope", "why": "Different users need different mobile surfaces while the account and financial rules remain consistent across devices.", "flow": "The applications use a shared typed API client. Credentials use secure device storage; screens render platform responses and do not decide whether a funded action is permitted.", "done": [ "Player application source for sign-in, coupon/betslip, casino, account history and safer-gambling views.", "Operator application source for dashboard, player review, withdrawal queue and audit views.", "Sales application source for a portable product presentation.", "Shared API client and money-formatting code in an npm workspace.", "Secure-store credential handling described in the mobile architecture.", "Separate environment configuration and build profiles per application.", "A documented release-verification path and common server-controlled decision boundary." ], "value": "The portfolio includes an application delivery foundation beyond the web demos. It can be assessed against a prospective customer’s actual mobile distribution needs.", "boundary": "Project documents disagree on historical device-build/signing status. Only source delivery is claimed here; signed builds, device acceptance and store distribution need explicit current evidence.", "evidence": [ "mobile/README.md", "mobile/package.json", "mobile/player/eas.json", "mobile/admin/eas.json", "mobile/sales/eas.json" ] }, { "id": "verification", "title": "Verification, integrity hardening and deployment tooling", "category": "Engineering evidence", "why": "A platform needs repeatable ways to find errors in financial, game and access behaviour and to establish what was actually deployed.", "flow": "The local suite evaluates the implementation; specialised probes exercise a controlled deployment; the readiness command identifies obligations that code cannot satisfy.", "done": [ "Recorded backend verification: 2,503 passing tests and 185,135 assertions on isolated MariaDB 11.8.2, 8 October 2026.", "76 passing tests against the shipped front-end engine in that local evaluation.", "Static-analysis configuration and documented PHPStan verification procedure.", "Separate slow game/RNG simulations and production-database parity configuration.", "Wallet, game outcome, retry, concurrency and abandoned-round integrity tests.", "Cross-tenant, staff capability, two-factor and administrative audit test coverage.", "Smoke, abuse, adversarial and concurrency probe tools for controlled evaluation.", "Health services, operational alerting and webhook dispatch services.", "Bunny static deployment, shared asset synchronisation and documented API deployment procedures." ], "value": "The team can give a reviewer reproducible checks and a defined next evidence set. This is more useful than relying on a successful sales demonstration.", "boundary": "The current default-suite result ran on a real MariaDB 11.8 server in strict SQL mode and the slow simulation group passed separately; neither is a production patch-level match. Internal probes are not an independent penetration test, production scale benchmark or assurance report.", "evidence": [ "sites/investor/verification.json", "tools/engine-tests.mjs", "tools/pentest.mjs", "docs/DEPLOY.md" ] } ] }