Operate sponsored engagement across every partner and surface.
PLLAY Campaign OS is the control plane platforms, brands and operators will use for campaign creation, approvals, live monitoring, outcome resolution, rewards and reporting — in development, not yet self-serve.
In development — managed campaign operations available today.
Eleven fields, one campaign.
Every campaign is scoped from this same set of fields, gathered with the PLLAY team in the first working session — there is no self-serve console to log into instead.
capability_flags.pulse_brand_campaigns_enabled = true, but every sponsor_campaigns row in production is demo/pilot data (advertiser is null on all of them); zero campaigns have reached campaign_status = 'COMPLETED' with a signed io_reference and a paid invoice. Scoped with our team today, in the first working session — there is no campaign console to log into instead.
- Objective
What the campaign is for — awareness, engagement, conversion or another named goal.
- Sponsor
The brand or agency funding the reward pool behind the campaign.
- Partner
The platform, creator or publisher the campaign runs against.
- Placement
Where inside the partner's content or surface the interaction appears.
- Audience
Content eligibility, category exclusions and age constraints the campaign runs within.
- Schedule
When the campaign opens, runs and closes.
- Frequency
How often a participant may be asked, so participation does not become interruption.
- Creative
The visual and copy treatment a participant actually sees.
- Interaction
The question, options and decision window a participant plays.
- Reward
What a participant receives, and the budget it is funded from.
- Outcome rules
What counts as a resolved result, and what happens when a read is unclear.
Conceptual interface — described here, not a shipped self-service screen. The builder is a set of fields a campaign is scoped with today, not a form a visitor fills in.
Nothing launches without sign-off.
The sponsor signs off on the creative and the interaction before anything reaches an audience.
Human approval runs as part of every engagement with the PLLAY team; there is no self-serve review queue yet.
The partner platform or creator confirms the placement and eligibility rules.
Content eligibility, category exclusions and age restrictions are set as terms of the engagement with the PLLAY team for every campaign today.
Disclosure, eligibility and category rules are checked before the campaign runs.
Content eligibility, category exclusions and age restrictions are set as terms of the engagement with the PLLAY team for every campaign today — the same rule config/brands.ts's BRAND_CONTROLS records.
A named PLLAY reviewer confirms the interaction is buildable as specified before launch.
No distinct product-approval stage exists as its own tracked step today — review runs as one undifferentiated pass with the PLLAY team, not as a separate, logged stage.
The funded budget behind the campaign's rewards is confirmed before launch.
A self-serve reward-budget field exists in the sponsor portal's source code, but that portal is not deployed yet — budgets are set as terms of the engagement with the PLLAY team today.
Changes to a live campaign or its outcome rules are tracked, not silently overwritten.
No rule- or campaign-versioning system exists in the codebase today — a campaign is configured directly with the PLLAY team, and an unclear outcome is held or refunded rather than adjudicated against a rule history.
Conceptual interface — described here, not a shipped self-service screen. Approval today is one reviewed pass with the PLLAY team, not five independently tracked queues.
What's watched while a campaign runs.
Whether a running campaign is performing as scoped, watched between sessions with the PLLAY team.
Launch is real — predictions run today; optimization runs as a team review between campaigns, per config/brands.ts's own LAUNCH_STEPS.
Eligibility, session state and interaction timing as a campaign runs.
Credits are allocated and participants are geo- and age-checked before an interaction opens, and the window locks before the outcome is knowable — live on every interaction today.
Who took part, and what they did — written per interaction as it happens.
The participation and verification record exists and is written per interaction, shared back with the partner between campaigns.
Participation patterns that do not resemble real people, flagged before they reach a report.
Fraud and anomaly detection runs on a recurring schedule in production, flagging suspicious activity for review before it reaches a payout.
What has been paid, to whom, and under which campaign's ledger entry.
Winners are paid, the revenue split applies per partner configuration, and the ledger is written — live on every settlement today.
How much of a funded budget is committed, reserved or still open.
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.
Switching a campaign off platform-wide without a deploy.
Capability flags already gate major functions in production — vision_autonomous_enabled, pulse_brand_campaigns_enabled — but there is no partner-facing pause control; today a flag change is an internal, PLLAY-operated action.
Conceptual interface — described here, not a shipped self-service screen. Monitoring today runs as a team review between sessions, not a live partner-facing dashboard.
What happens to a candidate outcome.
The same resolution hierarchy PLLAY's Vision AI module runs on — see /vision-ai — described here as what an operator actually does with a candidate.
The result a resolution method proposed, before anything downstream acts on it.
ACCURACY_LEDGER: 38 recorded broadcasts, 31 auto-tier, 0 wrong auto-settles. All clips are VODs.
The read that produced the candidate, preserved alongside it.
Settlement writes a ledger entry on every pool; Vision AI's accuracy ledger records all 38 benchmark trials. This is an internal record today, not a published, partner-facing audit-log export.
How strongly the evidence supports the candidate outcome.
ACCURACY_LEDGER: 38 recorded broadcasts, 31 auto-tier, 0 wrong auto-settles. All clips are VODs.
Which version of the outcome rule the candidate was checked against.
No rule- or campaign-versioning system exists in the codebase today — a campaign is configured directly with the PLLAY team, and an unclear outcome is held or refunded rather than adjudicated against a rule history.
The four things an operator can do with a candidate outcome — settle it, send it to review, void it, or override the read.
settle_prediction_atomic is deployed and gated on creator or operator confirmation; the unclear branch holds or refunds rather than guessing.
Conceptual interface — described here, not a shipped self-service screen. The console is a description of what the resolver already does, not a rendered screen.
Where a funded budget actually goes.
The total reward value a sponsor has committed to a campaign.
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.
The share of the funded budget already committed to in-flight interactions.
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.
Rewards actually paid out against a resolved outcome.
Winners are paid, the revenue split applies per partner configuration, and the ledger is written — live on every settlement today.
What is left of the funded budget once reserved and issued value are accounted for.
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.
Value kept back on an unclear outcome rather than paid out on a guess.
Pools settle to the pool's own snapshot of its rate; unclear outcomes are held or refunded rather than guessed. This settlement logic is live in production.
Matching what was funded, reserved, paid and held back to one ledger.
Winners are paid, the revenue split applies per partner configuration, and the ledger is written — live on every settlement today; the report is shared back with the partner, not self-served.
Conceptual interface — described here, not a shipped self-service screen. Budget tracking is reported back between campaigns today, not surfaced as a live self-serve ledger view.
What a campaign reports against.
The field definitions below, not example figures — PLLAY has run no external brand campaign to source a number from, so a schema is what is shown.
The measurement infrastructure this would sit on top of is real and already powers Platform Intelligence as a managed, API-based engagement (see the Intelligence product). What does not exist yet is a self-serve dashboard — a campaign operator cannot log in and pull this data directly today.
- Eligible viewers
People present for the content the campaign ran against, and inside its eligibility rules.
- Participants
People who took an action — not people who were served something.
- Completed interactions
Interactions carried through to a resolved outcome, rather than opened and abandoned.
- Repeat participants
People who came back for a second interaction. The signal that separates a novelty from a habit.
- Reveal completion
How many participants stayed for the verified result rather than leaving at the call.
- Reward claims
Funded rewards actually claimed, as distinct from rewards awarded.
- Conversion
Actions carrying an attributable path to the outcome the objective named.
- Cost per verified engagement
Campaign cost over completed, verified interactions — the denominator being an action, not an impression.
- Exposed users
People the interaction was actually shown to, upstream of whether they took part.
- Invalid-traffic exclusions
Participation patterns that do not resemble real people, identified and excluded before anything is reported.
What a campaign's numbers compare against.
These are internal engineering design targets, not results measured from production traffic. PLLAY has not published a live latency, throughput or success-rate number — see /developers. No real advertiser campaign has completed and been invoiced yet, so no benchmark drawn from a real campaign exists to publish either.
Three tiers, not one blur.
Managed operations available today
- AvailableBrand, platform and legal/compliance sign-off
- AvailableEvent flow, eligibility and session state
- AvailableFraud detection
- AvailableCandidate outcome, evidence and confidence
- AvailableFinalize, escalate or void a resolution
- AvailableReward issuance and the settlement ledger
- AvailableHolds on unclear outcomes
Interfaces in active development
- In DevelopmentCampaign intake with the PLLAY team
- In DevelopmentSelf-serve campaign builder interface
- In DevelopmentProduct approval as its own tracked stage
- In DevelopmentVersion history for campaigns and rules
- In DevelopmentEmergency pause, partner-facing
- In DevelopmentFunded-budget reservation and spend tracking
- In DevelopmentSelf-serve reporting dashboard
Future automated optimization
- ResearchAutomated campaign optimization
- ResearchAutonomous outcome-rule tuning
Join the Campaign OS Design Program.
Shape the interfaces above with us, on a real campaign — scoped, managed and resolved by the PLLAY team while the self-serve console is built.
Every campaign is scoped directly with the PLLAY team.