# GiG (GiG Software) procurement pack

Review path: /review/gig

Primary procurement model: Modular PAM / API platform

This is an editable procurement record, not a readiness score, contract commitment, market permission or launch approval.

## Recorded position

| Field | Current position |
|---|---|
| Named product or module records | 5 |
| Product responsibility kinds | Player account management · Casino platform · Reporting & BI · Sportsbook · Managed services |
| Recorded permission markets | Alberta · Malta (MGA) · UK (UKGC) |
| Recorded permission kinds | B2B supplier approval |
| Pricing transparency | Not recorded |
| Operational history | Incident history unavailable for a complete count |
| Included deployment records | 0 |
| Included current-live deployment records | 0 |
| Interpretation boundary | These are records included in this review. Counts, zero values and empty lists do not establish absence, package inclusion, the supplying entity, market availability or a current deployment. |

## Applicable procurement scopes

| Scope | Inclusion basis |
|---|---|
| Turnkey iGaming platform | Turnkey |
| Modular PAM / API platform | SaaS / PAM category · PAM / API |
| Sportsbook platform | Recorded sportsbook capability |

## Product and responsibility map

| ID | Product or decision subject | Kind | State | Recorded position | Responsibility | Boundary | Accept when |
|---|---|---|---|---|---|---|---|
| product:gig:player-account-management | CoreX · Player account management | Player account management | recorded | CoreX is recorded for GiG (GiG Software) as player account management. The record establishes the named product-to-provider relationship only. | Player-account identity, lifecycle, authentication, profile state and the account services assigned to the PAM. | Wallet authority, KYC coverage, bonus ownership, omnichannel continuity or inclusion of every adjacent service. | An account-state and data-authority model with registration, restriction, closure, recovery, audit and migration tests. |
| product:gig:casino-platform | SweepX · Casino platform | Casino platform | recorded | SweepX is recorded for GiG (GiG Software) as casino platform. The record establishes the named product-to-provider relationship only. | The casino product layer joining player sessions, lobby, games, account services and operational controls. | Title approval, market availability, wallet authority, content ownership or inclusion of adjacent modules. | An end-to-end casino session and responsibility map covering launch, play, interruption, settlement and recovery. |
| product:gig:reporting-bi | DataX & LogicX · Reporting & BI | Reporting & BI | recorded | DataX & LogicX is recorded for GiG (GiG Software) as reporting & bi. The record establishes the named product-to-provider relationship only. | Defined reports, extracts, metrics, dashboards and controlled access to analytical outputs. | Data completeness, metric comparability, financial correctness, real-time delivery or unrestricted data access. | A data dictionary with lineage, refresh timing, access controls and reconciliation to operational and financial records. |
| product:gig:sportsbook | SportX · Sportsbook | Sportsbook | recorded | SportX is recorded for GiG (GiG Software) as sportsbook. The record establishes the named product-to-provider relationship only. | The bet and market lifecycle assigned to the named sportsbook product, including its connected operating components. | Trading ownership, event volume, PAM inclusion, market permission, latency or operator-specific configuration. | Bet-state tests covering offer, acceptance, rejection, cash-out, cancellation, settlement, correction and resettlement. |
| product:gig:managed-services | ServiceX · Managed services | Managed services | recorded | ServiceX is recorded for GiG (GiG Software) as managed services. The record establishes the named product-to-provider relationship only. | A defined operational function performed by people on behalf of the buyer or platform operation. | Transferred accountability, continuous coverage, decision authority, performance level or inclusion in base fees. | A service RACI with hours, decision rights, queues, handover, quality controls, audit trail and exit assistance. |

## Five priority questions and acceptance gates

### 1. TK-05 — Operational record

- Procurement context: Turnkey iGaming platform
- Current state: unknown
- Recorded position: GiG (GiG Software): incident history unavailable for a complete count. This does not establish poor reliability.
- Question: Can the supplier support the combined service boundary through incidents, recovery, peak load and supplier-chain failure?
- Request: Scoped incident history; component telemetry; RCA samples; capacity evidence; RTO/RPO tests; support rota; SLA formula, exclusions and remedies.
- Accept when: History and tests cover the proposed components and failure modes, while contractual measures can be reproduced from buyer-accessible records.
- Stop when: The supplier will not provide a bounded incident record, cannot demonstrate recovery of the proposed stack, or offers an SLA that cannot be measured or remedied.
- Contract destination: SLA, resilience, support and incident schedule

| Owner | Supplier response | Exception | Sign-off |
|---|---|---|---|
|  |  |  |  |

### 2. PAM-02 — Interface contract

- Procurement context: Modular PAM / API platform
- Current state: unknown
- Recorded position: GiG (GiG Software): Headless API is not confirmed for this profile. This is not a statement that the capability is unavailable.
- Question: Can the PAM operate as a modular service across the required synchronous APIs, events, exports and administrative workflows?
- Request: Versioned specifications; event catalogue; idempotency and ordering rules; error model; limits; sandbox parity; deprecation policy; sample logs.
- Accept when: Buyer tests cover success, duplicate, late, out-of-order, timeout, partial-failure and version-change paths with deterministic recovery.
- Stop when: A critical state transition depends on a private manual process, undocumented interface, non-replayable event or change policy the buyer cannot test.
- Contract destination: API, event and lifecycle schedule

| Owner | Supplier response | Exception | Sign-off |
|---|---|---|---|
|  |  |  |  |

### 3. SB-05 — Player and risk controls

- Procurement context: Sportsbook platform
- Current state: unknown
- Recorded position: GiG (GiG Software): Anti-fraud is not confirmed for this profile. This is not a statement that the capability is unavailable.
- Question: Do player limits, exclusions, affordability, fraud, AML and trading-risk interventions work across pre-bet and in-play paths?
- Request: Control matrix; decision timing; limit hierarchy; acknowledgement events; fail-closed tests; manual-action permissions; audit and report samples.
- Accept when: Every mandatory control applies before acceptance within its required time bound and remains enforceable during partial platform failure.
- Stop when: A restricted player or disallowed wager can be accepted because risk, PAM and sportsbook control ownership or timing is unresolved.
- Contract destination: Player protection, AML and risk-control schedule

| Owner | Supplier response | Exception | Sign-off |
|---|---|---|---|
|  |  |  |  |

### 4. TK-06 — Economics and exit

- Procurement context: Turnkey iGaming platform
- Current state: unknown
- Recorded position: GiG (GiG Software): commercial terms are not recorded for this profile. This does not imply a price level.
- Question: Does the commercial perimeter cover every module, environment, third party, volume step, managed service, migration and exit event?
- Request: Three normalized demand scenarios; complete rate card; pass-through register; indexation; minimums; change rates; exit inventory and priced transition plan.
- Accept when: All proposals reconcile to the same scope and demand assumptions, and data extraction, transition assistance, residual fees and termination events are enforceable.
- Stop when: A material charge, revenue basis, third-party dependency, minimum commitment, data extraction right or termination cost remains undefined at award.
- Contract destination: Charges, data portability and exit schedules

| Owner | Supplier response | Exception | Sign-off |
|---|---|---|---|
|  |  |  |  |

### 5. PAM-05 — Change isolation

- Procurement context: Modular PAM / API platform
- Current state: unknown
- Recorded position: GiG (GiG Software): no bounded deployment record is included in this review. This does not mean that the provider has no deployments.
- Question: Can either party upgrade a component without silently breaking events, reports, integrations or control semantics?
- Request: Compatibility policy; contract tests; schema registry; feature flags; release rings; rollback; end-of-life notices; dependency inventory.
- Accept when: Backward-compatibility and breaking-change rules are automated, release evidence is visible, and rollback preserves transaction and audit continuity.
- Stop when: The supplier can impose a breaking interface or data change without a tested migration path, adequate notice and buyer-controlled release gate.
- Contract destination: Change, compatibility and release schedule

| Owner | Supplier response | Exception | Sign-off |
|---|---|---|---|
|  |  |  |  |