Professional project · Spark Universe credit · NDA-protected
Creator event
operations
Design, implementation, administration, and incident handling for a custom, multi-day multiplayer experience broadcast live by a large creator group.
- Format
- Multi-day custom creator event
- Creator load
- 40+ participating creators
- Audience load
- 10,000+ combined peak viewers
- My role
- Experience design · development · administration · support
- Live duties
- Moderation · mediation · incident response
- NDA note
- Identifying and operational detail removed
Context
One event,
four live layers
The playable build was only one part of the system. Creator comprehension, audience visibility, platform behaviour, and live operations remained coupled throughout each session.
Every delay, rules question, and recovery could become part of the broadcast.
Creators had to understand the experience while simultaneously performing it for their audiences.
The build translated the event premise into rules, interactions, pacing, and recoverable state.
One operating view joined technical state, human context, and the audience-facing consequence.
- 01Creator and audience experience were treated as connected outputs, not separate concerns.
- 02Design and implementation shared the same working context, shortening the route from intent to live change.
- 03Operational decisions considered both a fault itself and the cost of exposing it on stream.
- 04Moderation and mediation ran beside technical support because either could block a session.
My role
From brief to
live window
I carried the event from experience definition through implementation and live administration. The sequence shows those hand-offs; exact schedules, partners, and implementation gates remain private.
- 01DefinitionFrame the experiencePremise · player flow · viewer readability · operational constraintsOutput: playable contract
- 02ProductionBuild the custom systemsImplementation · configuration · content integration · admin affordancesOutput: event build
- 03ReadinessExercise the operating pathsRules clarity · support route · intervention path · fallback conditionsGate: operable under pressure
- 04Multi-day live windowRun each sessionAdminister · support · moderate · diagnose · recover · communicateLoop: state → decision → verified return
- 05ClosureResolve the remaining stateClose support items · preserve relevant notes · capture operating changesOutput: closed event state
Selected work
Workstream
ownership
My role held creative, technical, and live context across the same event. The table shows the work before and during broadcast without exposing private partner or production detail.
| Workstream | Before live | During live | System interface |
|---|---|---|---|
| Experience design | Define player flow, rules, pacing, and viewer-readable beats. | Interpret deviations against the intended experience. | Creators · audience · platform |
| Development | Implement and integrate the custom experience. | Diagnose faults and select safe technical interventions. | Platform · administration |
| Administration | Establish operating paths and live controls. | Maintain session state and coordinate interventions. | Platform · creators |
| Creator support | Prepare the information needed to enter and understand the experience. | Resolve access, rules, and play-blocking questions. | Creators · operations |
| Moderation / mediation | Set the route for interpersonal and conduct issues. | Contain conflict, mediate where appropriate, protect the event. | Creators · operations |
| Incident response | Identify failure classes, ownership, and fallback paths. | Triage impact, communicate, recover, and verify. | All four layers |
- Operating principle
- Optimise for continuity of the live experience, not completion of any one feature in isolation.
- Shared context
- Creative intent and implementation state stayed in the same decision loop.
- Escalation
- Technical, creator-support, and conduct issues could be routed without treating them as the same class of problem.
- Recovery
- A fix was not complete until the affected creator could re-enter a safe, understandable, playable state.
Process
Triage and
recovery loop
Live response joined technical blast radius with human and broadcast impact. The diagram shows the decision logic; real thresholds, communications, and incident details remain private.
- 01DetectEstablish what happened and who is affected.
- 02ClassifyTechnical, support, moderation, or mixed incident.
- 03ContainStop the issue expanding across creators or sessions.
- 04RouteChoose the technical and/or people response lane.
- 05CommunicateGive the affected people a usable next action.
- 06VerifyConfirm safe play and understandable state have returned.
Diagnose state → isolate fault → apply intervention or fallback → verify the playable path.
Clarify context → moderate or mediate → establish next action → verify the safe participation path.
| Signal | Containment move | Recovery condition | Primary layer |
|---|---|---|---|
| Custom feature misbehaves | Isolate the affected path; move to a known fallback where available. | Creators can continue without propagating invalid state. | Platform |
| Creator cannot participate | Separate access, state, and rules causes; provide one next action. | The creator rejoins or receives an explicit alternative. | Creator |
| Rule is misunderstood | Clarify the playable contract without derailing the session. | Participants share the same actionable interpretation. | Creator / audience |
| Conduct conflict emerges | Contain the interaction; move the issue into moderation or mediation. | Safe participation can resume, or a clear participation rule is enforced. | Operations |
| Incident is visible on stream | Pair recovery work with concise, usable communication. | The technical or human block is resolved without amplifying confusion. | All layers |
Outcome
What I
delivered
The event combined a designed and implemented experience with the operating support needed to run it live. Private client material is not reproduced; diagram labels use generic functional terms.
Experience model
Player flow, rules, pacing, and viewer-facing structure for the custom event.
Internal working material · not reproducedImplemented build
Custom systems, configuration, and integrated experience content.
Private implementationOperations model
Administration, creator support, escalation, and recovery paths for the live window.
Internal working material · not reproducedIncident handling
Technical response, moderation, mediation, communication, and return-to-play decisions.
Private details · logic summarised hereSpark Universe credit; multi-day custom event; 40+ creators; 10,000+ combined peak audience.
Layer topology, production sequence, ownership map, triage loop, and contingency classes.
Partner requirements, names, communications, exact schedule, source and configuration, internal thresholds, and incident details.