XD Dark Ride Platform Proposal
A Playbox platform partnership for Triotech
Proposal to Triotech | 6 October 2026
We propose a Triotech-branded platform for XD Dark Ride owners and service teams. It combines attraction performance reporting, game purchases through Stripe and remote support through an approved machine agent and assistant tools.
The proposed next step is a paid joint discovery followed by a limited operator pilot. This validates hardware access, content rights and measurable service value before committing to a fleet rollout.
Existing Triotech Dark Ride product visual. Source S1. This proposal concerns the digital platform around the attraction.
The customer outcome
Owners can understand game performance, purchase approved content and follow service cases. Operators receive a focused daily workspace. Specialists can investigate assigned machines through Claude, Codex or Cursor without giving every user access to technical controls.
The partnership outcome
Triotech defines product compatibility, content rights and approved service procedures. The Playbox partner supplies the portal, integration services and machine-agent implementation. The parties measure support effort and customer task completion during the pilot.
Scope: XD Dark Ride only. All prototype prices, transactions, telemetry and assistant sessions are simulated. No live Stripe, camera, Codex, Claude, Cursor or ride connection is established by the mockup.
Workspaces and access
The interface changes with the person’s responsibility
A role determines the navigation, landing page, data scope and actions available. The prototype hides irrelevant menu items and blocks direct navigation to restricted screens. Production must enforce the same rules on every API, export, download and remote command.
| Role | Available workspace | Restricted by default |
|---|---|---|
| Client owner | Own customer analytics, audience reports, attractions, game store, billing, service requests and team access. | No other customers. No assistant setup, diagnostic tools or repair execution. |
| Site operator | Assigned attraction, local operating status, installed games and service requests. | No game purchasing, billing, demographic reports, team administration or remote assistant connection. |
| Support specialist | Assigned case queue, scoped device evidence, Claude, Codex or Cursor connection, approved recovery and session activity. | No store, customer finances, demographics or customer user administration. |
| Platform admin | Customer metadata, device registry, access administration, support administration and audit activity. | No customer financial or demographic reports by default. Operational access requires an assigned case. |
Client and operator journey
The owner approves a game license and maintenance window. The operator sees installed content and can request help for the assigned attraction. A service request creates a case for the technical team; it does not grant the operator access to an AI connection or privileged command.
Specialist and administrator journey
A specialist opens an assigned case, verifies the device and establishes a limited support session. Administrators manage customer and user configuration. Their support view follows the same scoped workflow rather than acting as an unrestricted machine console.
Switching roles in the prototype closes open dialogs, returns to the correct workspace and clears the assistant connection preview. Architecture and project planning appear in this proposal, outside the operational navigation.
The operator experience
A focused view for daily venue work
Site operator workspace. Synthetic status and activity data. Purchasing, audience reports and assistant setup controls are absent.
Daily operations
The operator landing page prioritizes the attraction’s condition, recent activity, installed games and service requests. The installed-game library shows packages at the assigned attraction with no purchase or deployment controls.
Owner analytics
The owner workspace adds location and period filters, net sales, rider totals, a title-share donut chart and an illustrated leaderboard. Game charts use consistent admissions counts. Revenue must reconcile to the venue’s POS or cashless source; operational events alone do not establish actual sales.
Service communication
Owners and operators submit symptoms and follow case status. Technical specialists receive the diagnostic interface. This keeps the customer experience simple while retaining a clear route to support.
Platform architecture
An approved machine agent connects the attraction to cloud services
Proposed logical architecture. The camera feeds the agent locally. Stripe confirms payment to cloud commerce services.
Machine agent
Install an OS service on a vendor-approved host. The agent enrolls with a device-specific identity, reads approved game events, buffers them in a durable offline queue and sends authenticated batches. Cloud ingestion deduplicates events and binds them to the enrolled customer and site.
The agent stages signed content, checks hashes and compatibility, and activates it only during an approved window with fresh idle state and local clearance. It records outcomes and supports a tested rollback. OS choice, SDK availability and hardware resources are discovery inputs.
Cloud services
Separate customer access, ingestion, analytics, commerce, content distribution and support authorization. Store event time and ingestion time, monitor queue backlog, rotate device credentials and audit changes. The proposed device connection is outbound; the machine needs no public inbound support port.
Authority boundary: local ride controls remain authoritative. Motion, restraints, emergency systems and physical calibration stay outside the remote AI tool scope.
Game purchasing with Stripe
Payment fulfillment and installation are separate states
Publish only offers with approved title rights, territory, term and device compatibility. Triotech must define the seller of record, tax treatment, renewal rules and refund policy. The displayed annual CAD prices are illustrative presentation inputs, not commercial offers.
| Stage | Platform behavior |
|---|---|
| Offer and order | Verify buyer permission and attraction scope. Resolve an approved server-side offer and Stripe Price ID. Record the agreed term, device, amount and currency. |
| Checkout | Create a Checkout Session on the server. Use Stripe-hosted payment fields so raw card details do not enter the platform. |
| Payment confirmation | Verify the webhook signature using the raw body. Match the order and retrieve authoritative payment state. Fulfill once using an atomic transaction and unique session/order constraints. |
| Entitlement | Grant the license only after qualifying payment confirmation. A cancelled, declined or pending payment grants no access. The success page alone is not payment evidence. |
| Installation | Issue a signed manifest and short-lived download authorization. The agent stages the package, validates it and waits for approved local conditions. |
| After purchase | Show receipt, license state and delivery state separately. Reconcile refunds, disputes and expiry under an agreed policy without interrupting an active ride. |
Payment states in the mockup
The account-free checkout illustrates card, Link and wallet layouts with fixed example details. No Stripe account, SDK or payment service is connected. Successful, declined and pending outcomes run locally; success enables demo installation scheduling. A real Stripe-hosted checkout requires an account and server integration.
Production validation
A dedicated Stripe sandbox must exercise duplicate and out-of-order webhooks, delayed payment success and failure, cancelled sessions, refund handling and customer isolation. Reconcile payment confirmation independently from package deployment. The integration pattern follows Stripe documentation S2 and S3.
Start with one merchant account if the commercial model permits it. Evaluate Stripe Connect only if distinct legal sellers and payout routing are actually required.
Support in your preferred assistant
Claude, Codex and Cursor share a scoped support connection
Three client-specific Add to buttons. These illustrate setup and do not install a connection or change assistant settings.
The support experience follows the established Playbox pattern: discover the assigned device, verify the current identity and role, open a bounded session, collect evidence, review an approved action and verify its result. It reuses the workflow idea without assuming Triotech exposes the same interfaces.
Connecting an assistant
A specialist chooses Add to Claude, Add to Codex or Add to Cursor and reviews the case, attraction and permitted evidence. Each button opens a client-specific setup preview. For production, register the approved support server and authenticate in the client. Only confirmed server authorization may establish connected status [S4-S6].
Diagnosis and repair
Begin with machine health, bounded redacted logs and job status. The AI proposes actions; the service layer enforces authorization. Repairs require a separate approved runbook, exact target, expiry, attempt limit and a fresh local state check. Unknown state blocks execution. Record the evidence, action, result and escalation outcome.
The Playbox-style workspace opens a 30-minute preview session before diagnostics, separates repair approval and shows recent jobs with evidence results. Ending the session disables further diagnostics. Owners and operators create scoped support requests with category, impact and symptoms. All actions remain local simulations.
Audience and data governance
Separate occupancy measurements from voluntary demographic responses
Camera occupancy
The product is reported to have a camera. Confirm stream access, ownership, field of view, supported interfaces and usable quality on the target installation. The proposed adapter processes occupancy at the venue, with no stored frames, face recognition, embeddings or cross-session rider identity in this analytics pipeline.
Send coarse time buckets, counts and quality indicators through the machine agent. Measure error against manual counts under real lighting and occlusion. Unknown or poor-quality input must appear as unavailable, not zero attendance. A local disable control and compute limits protect attraction operation.
Voluntary audience survey
Use an optional adult QR survey tagged with the game title and a coarse reporting period. Age bands and gender are self-reported. Do not infer sex or gender from the camera or link responses to camera tracks. Include the option to decline and avoid collecting names or exact birth dates.
Release aggregate reports with respondent counts, eligible-invitation denominators and response rates. Survey results describe participants, not every rider. Proposed controls include a minimum segment size of 20, complementary suppression and limits that prevent reconstructing small groups through filters. Final collection, consent and retention rules need an operator privacy review.
| Record | Core controls |
|---|---|
| Operational events | Schema version, unique event ID, device/session/title version, timestamps, deduplication and source quality. |
| Financial transactions | Authoritative POS or cashless transaction ID, currency, tax, refunds and timezone. Separate from game-license purchases. |
| Customer and user access | Server-side tenant/site checks, least privilege, revocation and audited role changes. |
| Support evidence | Redaction, bounded capture, scoped retrieval, expiry and a complete action history. |
| Audience aggregates | Separate survey storage, agreed retention, sample disclosure, suppression and no camera identity join. |
Delivery and commercial plan
A staged pilot with evidence-based release gates
Treat the 18-week sequence below as an initial planning hypothesis. Confirm the schedule and commercial price after discovery. Camera analytics can remain an optional pilot workstream so it does not delay core commerce and operational reporting.
| Window | Work and exit gate |
|---|---|
| Weeks 1 to 2 | Discovery: one representative machine, host access, supported events, content rights, camera review, current support baseline and named owners. |
| Weeks 3 to 6 | Agent lab and data proof: enrollment, offline buffering, replay, customer isolation, package verification and reliable event capture. |
| Weeks 7 to 10 | Role-specific portal and support: scoped Claude/Codex/Cursor connection, redacted diagnostics, authorization checks and outcome verification. |
| Weeks 11 to 14 | Commerce sandbox and pilot: payment failure/retry tests, entitlements, approved content delivery and two operator organizations. |
| Weeks 15 to 18 | Observe usage and service outcomes, address failures and decide whether to expand. Extend observation if the incident sample is too small. |
Success measures
Agree definitions before measurement. Proposed gates include at least 99% eligible event capture in the agreed window, daily financial reconciliation, no duplicate license grants in retry tests, rejection of unauthorized actions, and successful idle-state postponement and rollback. Target at least four of five representative users completing core tasks unaided.
Test whether eligible support cases reduce median handling effort by at least 20% against a comparable baseline. This is a pilot target, not a savings promise. Measure escalation rate, verified resolutions and operator downtime alongside effort.
Responsibilities and commercial structure
Triotech leads hardware access, content licensing and approved service procedures. The Playbox partner leads portal and adapter implementation, service orchestration and delivery. Both parties approve privacy design, security, pilot measures and operating responsibilities.
Propose a paid discovery statement of work, then milestone-based pilot delivery. Final pricing must cover implementation, cloud operations, support hours, content rights and payment fees. Agree reusable platform IP, Triotech-specific adapters, data ownership, support escalation and service levels before production.
Requested decision: nominate engineering and service sponsors, provide one representative lab system and redacted support examples, and agree the scope of paid discovery and two candidate pilot operators.
Evidence and assumptions
Source register and the status of the proposed capabilities
The proposal combines public manufacturer information, authorized local Playbox source inspection and original product design. The inspected Playbox code contains patterns for scoped access, analytics ingestion, Stripe checkout fulfillment, entitlements, package distribution and audited support. This establishes a reuse starting point, not production readiness or Dark Ride compatibility.
| Status | What it means |
|---|---|
| Established product context | XD Dark Ride is Triotech’s existing interactive attraction with a renewable content library. Official product information and artwork appear in S1. |
| Prototype implemented | Four role-specific interfaces, route restrictions, game charts, simulated checkout and installation, audience illustrations, Claude/Codex/Cursor connection previews and scoped service workflows. |
| Proposed integration | Machine agent, vendor adapter, payment webhooks, assistant identity/authorization service, signed delivery, camera occupancy and survey aggregation. |
| Discovery requirements | Actual machine OS and interfaces, camera capabilities, title licensing, production payment account, tenant security, retention, support policy and operating costs. |
Public references
S1 Triotech XD Dark Ride: trio-tech.com/products/xd-dark-ride. Product visual and logos: go.trio-tech.com/contact-xd-dark-ride.
S2 Stripe Checkout fulfillment: docs.stripe.com/checkout/fulfillment.
S3 Stripe webhook verification and event delivery: docs.stripe.com/webhooks.
S4 Codex assistant setup: developers.openai.com/codex/mcp.
S5 Claude Code connections: code.claude.com/docs/en/mcp. Claude product surfaces have different setup flows; validate the selected client during integration.
S6 Cursor installation links: prod.cursor.com/docs/mcp/install-links.
Public sources checked 6 October 2026. Product logos remain unaltered. Game cards use AI concept artwork. Claude, Codex and Cursor cards use text labels and illustrative symbols; no official partnership or endorsement is implied.
The accompanying mockup is a presentation prototype with synthetic data and browser-session state. Its role selector demonstrates the proposed experience; production authentication and authorization remain implementation work.