{ "date": "2026-10-01", "status": "Proposed workstreams; not a contracted schedule", "workstreams": [ { "id": "scope", "title": "Agree the first operator and launch scope", "phase": "Define", "lead": "Founding team, operator sponsor and regulatory adviser", "purpose": "Turn the early conversations into one specific service that can be tested, budgeted and accepted. The platform’s full breadth should not make the first release unbounded.", "foundation": "Working player demos, operator tools, headless delivery, tenant configuration and the existing feature catalogue.", "actions": [ "Document the target operator, customer audience, jurisdiction and commercial operating model.", "Decide which party supplies software, hosts facilities and contracts with players; obtain advice on the resulting licence responsibilities.", "Select the first games, markets, channels and customer workflows.", "Agree migration needs, provider responsibilities and the customer’s acceptance questions.", "Reconcile the delivery budget against that scope and seek a documented customer commitment." ], "outputs": [ "First-operator specification", "Responsibility and dependency matrix", "Initial game/content list", "Acceptance plan and scoped budget" ], "depends": "Prospective operator participation and specialist review of the chosen model.", "complete": "Both sides can identify exactly what will launch, who is accountable and what evidence is needed. No unsigned interest is counted as a contract." }, { "id": "customer-demo", "title": "Build the customer-specific demonstration", "phase": "Demonstrate", "lead": "Product/design, platform engineering and operator product owner", "purpose": "Show the prospective customer’s business in action: brand, acquisition journey, player experience and staff workflow.", "foundation": "Seven existing brand demos, the shared widget/skin system, custom API delivery and the customer demo brief builder.", "actions": [ "Translate the customer’s positioning into navigation, content hierarchy, typography, colour, mobile layout and supported journeys.", "Build onboarding through to account history, using an isolated play-credit evaluation session.", "Represent the selected sportsbook or game catalogue and demonstrate rules and account controls.", "Provide a supervised operator walkthrough for reporting, player servicing, trading and audit.", "Record representative journeys and gather specific acceptance feedback." ], "outputs": [ "Branded play-credit demo", "Player and operator walkthroughs", "Customer feedback and change list", "Agreed scope of configuration versus new delivery" ], "depends": "A usable customer brief and a defined feature/content scope.", "complete": "The customer can evaluate their actual workflows and the team can estimate the remaining work. A polished demo is still an evaluation environment." }, { "id": "test-submission", "title": "Prepare games, RNG and integration evidence", "phase": "Test", "lead": "Game/platform engineering and an approved test house", "purpose": "Make the implemented product independently assessable, using an identifiable release and a bounded first slate.", "foundation": "Game engines, published-return checks, deterministic round evidence, recovery tests and the internal verification tools.", "actions": [ "Freeze the release identifiers, engine versions, paytables, rule text and configuration for the submitted scope.", "Assemble RNG design, seed lifecycle, game-maths/return calculations and round-reproduction examples.", "Run the relevant simulations, financial-integrity, interrupted-round and integration checks; retain the results with the build identity.", "Obtain a scoped external testing engagement and submission requirements.", "Submit the agreed build, track findings and retest changes that affect the assessment scope." ], "outputs": [ "Versioned submission package", "Scoped test-house engagement", "Findings and remediation record", "Applicable independent test outcomes" ], "depends": "The selected game slate and agreed test-house requirements. Provider integration testing may introduce additional scope.", "complete": "The relevant external findings are resolved and the independent results identify the actual assessed build and scope. Internal test counts are supporting evidence." }, { "id": "iso", "title": "Complete the ISO 27001 management-system work", "phase": "Assure", "lead": "Security/compliance owner, management and independent certification body", "purpose": "Extend the implemented technical controls into a scoped, operated information security management system.", "foundation": "Staff authentication, tenant controls, audit, financial integrity, privacy workflows and the assurance evidence map.", "actions": [ "Define the service and organisational scope, assets, data, suppliers and customer responsibilities.", "Carry out risk assessment and treatment; maintain the Statement of Applicability with justification and evidence.", "Assign control owners and implement policies for access, change, incidents, suppliers, retention and business continuity.", "Collect operational evidence, train staff and rehearse recovery and incident handling.", "Perform internal audit and management review; commission the independent certification assessment and close findings." ], "outputs": [ "ISMS scope and risk treatment records", "Statement of Applicability", "Owned policies and operational evidence", "Internal audit and management review", "Actual certification outcome if obtained" ], "depends": "Management ownership, an agreed service scope and evidence that the controls operate in practice.", "complete": "The management system has been assessed within its stated scope, with findings resolved and any certificate described accurately. Product code alone is insufficient." }, { "id": "soc", "title": "Plan and evidence the customer’s SOC 2 requirements", "phase": "Assure", "lead": "Security/compliance owner and an independent CPA firm", "purpose": "Determine which assurance report customers need and plan the evidence collection accordingly, rather than promising a generic badge.", "foundation": "The same authentication, availability, audit and transaction-integrity controls described on the assurance page.", "actions": [ "Confirm the customer procurement requirements and the service boundaries for the examination.", "Agree the relevant Trust Services Criteria and report type with the examiner.", "Describe the service, controls, responsibilities and evidence sources.", "Close readiness gaps and collect evidence for the agreed examination scope and period.", "Undertake the examination and handle report access, exceptions and remediation." ], "outputs": [ "Customer-led SOC 2 scope", "Control/evidence ownership map", "Examination plan and evidence schedule", "Independent report when completed" ], "depends": "Customer demand, examiner engagement and sufficient operating evidence. Scope can overlap with ISO preparation but the outcomes are distinct.", "complete": "An independent report exists for the actual scoped service and is described by its type and period. Planned assurance is not a completed examination." }, { "id": "providers", "title": "Contract and accept the launch providers", "phase": "Integrate", "lead": "Platform engineering, operator compliance and provider account teams", "purpose": "Replace demonstration configuration with provider connections suitable for the chosen customer and jurisdiction.", "foundation": "Payment, identity, exclusion, location, odds/content and settlement interfaces and internal workflows.", "actions": [ "Agree a provider matrix covering identity, national exclusion, geolocation, gaming payments, official settlement data and chosen external content.", "Confirm eligibility, commercial rights, contractual responsibilities and data-processing arrangements.", "Configure credentials and tenant-specific policy without exposing secrets in customer interfaces.", "Exercise success, refusal, timeout, retry, duplicate callback, dispute and exception paths where applicable.", "Record integration acceptance and align failure behaviour with the operator’s launch policy." ], "outputs": [ "Contracted provider matrix", "Accepted live integrations", "Failure/retry evidence", "Operational escalation contacts" ], "depends": "Provider onboarding/underwriting, operator eligibility and the business/licence model. An existing driver does not imply provider acceptance.", "complete": "Each required integration works under accepted production configuration and its rights, failure handling and owner are documented." }, { "id": "performance", "title": "Measure representative performance and resilience", "phase": "Prove", "lead": "Engineering/operations and customer technical owner", "purpose": "Substantiate the speed and stability proposition with reproducible measurements under a realistic workload.", "foundation": "Static customer delivery, headless API, shared brand assets, health checks and concurrency probes.", "actions": [ "Define representative device/network profiles, journeys, concurrency and workload mixes.", "Measure customer loading, API latency percentiles, errors and settlement behaviour under the stated environment.", "Exercise contention, retries, delayed feeds and provider failures without placing production customer funds at risk.", "Document bottlenecks, capacity changes and repeat the relevant measurements after remediation.", "Agree monitoring, alert thresholds and the customer’s actual service expectations from the results." ], "outputs": [ "Dated benchmark methodology", "Latency/error/throughput results", "Bottleneck and remediation record", "Agreed operating envelope" ], "depends": "Representative infrastructure, accepted integrations and permission to test the chosen environment.", "complete": "Claims can be tied to a workload, build, environment and result. The site’s three public reads remain browser round trips, not a substitute for this work." }, { "id": "operations", "title": "Rehearse the operating service", "phase": "Operate", "lead": "Operations, security/compliance and operator finance/support", "purpose": "Show that the customer service can be monitored, reconciled, supported and recovered after launch.", "foundation": "Audit and reporting services, health/alerts, deployment runbooks, ledger reconciliation and round recovery.", "actions": [ "Assign support, finance, incident and deployment responsibilities with escalation routes.", "Verify backup location, restoration, recovery objectives and a recorded recovery drill.", "Establish release/change approvals, access reviews and secret/key rotation responsibilities.", "Rehearse reconciliation, failed withdrawals, unsettled events, disputed rounds and provider outages.", "Complete customer-facing policies, support procedures and the selected funds-protection arrangements with the responsible operator." ], "outputs": [ "Operating and incident runbooks", "Restore/recovery evidence", "Reconciliation and exception procedures", "Owned access/change controls", "Operator acceptance record" ], "depends": "The customer model, actual infrastructure, finance arrangements and provider escalation paths.", "complete": "Named roles can demonstrate the rehearsed procedures and retained evidence. A healthy homepage alone does not establish an operational service." }, { "id": "approval", "title": "Complete applicable licensing and approval gates", "phase": "Approve", "lead": "Responsible licence applicant, regulatory adviser and relevant independent bodies", "purpose": "Establish that the exact service is authorised for the intended activity and market before any regulated real-money release.", "foundation": "The readiness command already records external obligations separately from implemented controls.", "actions": [ "Confirm the required applications and responsible legal entities for the supply/hosting/operating model.", "Prepare the required business, technical, key-person and operational submission material.", "Track enquiries, findings and any changes to the proposed service.", "Attach the relevant game/testing and security outcomes to the launch evidence where required.", "Review the final conditions, approved scope and production configuration before customer release." ], "outputs": [ "Applicable regulatory decisions", "Documented conditions and responsibilities", "Approved release evidence checklist" ], "depends": "External decision processes and the completed evidence they require. Timelines and outcomes cannot be guaranteed by the platform team.", "complete": "The applicable decisions and supporting evidence exist for the chosen service; no play-credit demo is treated as real-money permission." }, { "id": "launch", "title": "Accept, deploy and expand the first customer", "phase": "Deploy", "lead": "Delivery/operations and operator sponsor", "purpose": "Turn the accepted and appropriately approved service into a controlled customer release, then learn whether the model is repeatable.", "foundation": "Tenant provisioning, brand interfaces, operator tools, billing/reporting implementation and deployment tooling.", "actions": [ "Complete customer acceptance on the agreed devices, journeys, account controls and staff operations.", "Perform and reconcile any agreed migration with an explicit rollback/recovery plan.", "Identify the deployed build/configuration and use a controlled release window with active monitoring.", "Review incidents, conversion, repeat engagement, service costs and customer outcomes after launch.", "Scope subsequent brands and games against demonstrated demand, delivery effort and the relevant approval boundaries." ], "outputs": [ "Signed acceptance", "Identified production release", "Post-launch review and measured customer outcomes", "Evidence-based expansion backlog" ], "depends": "Integration, operating, commercial and applicable approval gates must be closed for the release scope.", "complete": "The customer has accepted the live service, operating evidence is retained and expansion decisions are based on actual outcomes rather than implementation counts." } ] }