Turn television and video into synchronized participation.
PLLAY connects the big screen to mobile participation through QR sessions, timed challenges, verified outcomes and sponsor-funded rewards.
One moment, two screens.
Illustrative — this is a demonstration of the concept, not a recording of live product behaviour.
TV displays
“Will the player complete the challenge?”
Viewer scans QR.
Mobile
The underlying mechanism — a mobile-web second screen, no install, playing in sync with content — is live in production today. A CTV-specific pairing (a code shown on a connected-TV screen, bound to that session) has not run against a real CTV surface. The walkthrough below is illustrative of what that pairing is designed to do.
Where this pattern applies.
CTV gaming
Sports broadcasts
Gaming creator channels
FAST channels
Recorded gaming libraries
Live entertainment
These are the kinds of content and screens this pattern is designed for, not a list of PLLAY's customers or partners. PLLAY has no current partnership, endorsement or integration with any specific CTV device, platform or channel operator.
Seven pieces — what ships, what's still being built.
Short-lived TV session
In DevelopmentA session tied to what's on the TV screen, valid only for the length of the moment it belongs to.
The underlying QR / second-screen mechanism is live in production — mobile web, no install, is how every fan on PLLAY plays today. No TV-bound session concept exists in the codebase yet — the interaction window itself expires, but not a session scoped to a connected-TV pairing.
Signed QR / deep link
In DevelopmentThe code or link a viewer scans is cryptographically signed and cannot be reused or replayed.
The underlying QR / second-screen mechanism is live in production — mobile web, no install, is how every fan on PLLAY plays today. Webhook deliveries are HMAC-signed today (pages/Developers.tsx); the same signing discipline has not been built for a TV-session-bound QR code specifically.
Mobile binding
In DevelopmentThe mobile session that scanned the code is bound to that specific TV session, not just to the interaction.
No TV-to-mobile session binding exists in the codebase — the mobile-web play surface joins an interaction directly, with no connected-TV pairing step to bind against.
Server-controlled lock
AvailableThe window closes on PLLAY's server clock, before the outcome is knowable, not on the client's.
Live on every interaction today — the window locks before the outcome is knowable, per the same mechanic config/pulse.ts's fan-experience record already ships.
Outcome resolution
AvailableThe result is confirmed by creator/operator confirmation or by reading evidence off the content.
Two resolution methods run in production today: creator/operator confirmation, which is how most outcomes resolve, and Vision AI, validated on 38 recorded broadcasts with 0 wrong auto-settles.
Reward issuance
AvailableWinners are paid and the ledger is written once the outcome is confirmed.
Winners are paid, the revenue split applies per configuration, and the ledger is written — live on every settlement today.
Privacy-safe aggregate reporting
In DevelopmentParticipation is reported in aggregate, under a published privacy policy, never as individually identifying data.
A published privacy policy, consent controls and a do-not-sell path ship today across every PLLAY surface. Partner-facing aggregate reporting and exports are still being built — zero partners are onboarded to that reporting surface yet.
What the mechanism produces.
Cross-screen attention
A moment on the big screen becomes an action on the screen already in the viewer's hand.
Participation without interrupting content
The broadcast keeps playing — the interaction runs alongside it, not instead of it.
Sponsor ownership
A funded interaction identifies its sponsor on the experience itself, distinct from a passive ad break.
Measurable scan-to-participation
The path from a scanned code to a completed interaction is a real, countable funnel, not an estimate.
Repeat engagement
A standing streak or reputation gives a viewer a reason to scan again next time.
See the media & platforms business case and the Pulse product record for the fuller picture.
What's guarded, and what's still being built.
Expiring sessions
In DevelopmentA TV-paired session is valid only for the length of the moment it belongs to, then expires.
No TV-bound session concept exists in the codebase yet — see the Technical Pattern section above.
No personal information inside QR code
In DevelopmentThe code itself carries no personal data — only what's needed to join the session.
A stated design requirement for the CTV-session system described above, which is not yet built. Today's live QR/second-screen mechanism predates this specific pairing and carries no CTV-session payload to make a claim about.
Eligibility and frequency limits
AvailableContent eligibility, age restrictions and how often a participant may be asked are all defined before a campaign runs.
Content eligibility, age restrictions and frequency limits are set as terms of every engagement with the PLLAY team today — the same controls config/brands.ts's BRAND_CONTROLS record.
Reward-budget controls
In DevelopmentA campaign's reward spend is capped and reserved before it runs.
A reward-budget field exists in the sponsor portal's source, but that portal isn't deployed — reward budgets are set per campaign directly with the PLLAY team today.
Graceful failure states
AvailableWhen an outcome can't be confirmed, the system holds or refunds rather than guessing.
Live on every settlement today: when confidence doesn't clear the bar, PLLAY holds or refunds rather than guessing — the same rule stated across config/capability-claims.ts and config/pulse.ts.
Scoped, measured, time-boxed.
Three surfaces or content properties
100K+ eligible household/user path where available
Three challenge formats
One sponsor
6–8 weeks
"Where available" is load-bearing: this is a criterion PLLAY looks for when selecting a pilot surface, not a claim about audience PLLAY currently reaches.