Wellbeing Studio 2027Taking R U OK? Day through a production vertical slice
Wellbeing Studio 2027

Production implementation

Taking R U OK? Day through a production vertical slice

R U OK? Day was chosen as the first bounded production release of Wellbeing Studio 2027. The work moved from a defined campaign slice into a real application route, then through participant-access, staging, Magic Link remediation, content integration and runtime-reliability work. Later product specification deliberately removed mandatory authentication from the RUOK core journey, retaining the proven infrastructure without allowing it to dictate participant behaviour.

Why examine thisThe useful evidence is not simply that a campaign page was built. It is the sequence of product definition, vertical-slice implementation, production qualification and subsequent correction: engineering proved what the platform could do, while product architecture retained the authority to decide what participants should actually be required to do.

Production evidence · five stages

Capability proved ≠ requirement retained.

  1. 01
    Bound the product

    R U OK? Day becomes a controlled production slice, not the whole 2027 product.

  2. 02
    Build a real vertical slice

    The campaign experience enters the production application at 2c56d6b.

  3. 03
    Prove participant access

    Neon Auth, staging readiness and Magic Link remediation test the access boundary.

  4. 04
    Harden the runtime

    Postgres reliability and LC1 content/media integrity are qualified rather than assumed.

  5. 05
    Correct the product

    Mandatory authentication is later removed from the RUOK core journey even though the capability is proven.

Inspect the production map

The tension

A fixed date makes inherited code look more authoritative than it is.

The campaign had a fixed 10 September date and substantial infrastructure already existed. The risk ran in both directions: throw away proven foundations and build a disposable microsite, or preserve every existing capability — including authentication and inherited navigation — simply because it had already been engineered.

The move

Prove the slice in production, then keep product authority above implementation.

Use R U OK? Day as a constrained production proof inside the real Studio. Extend durable content, media, database, deployment and access foundations; qualify them in deliberate gates; then re-evaluate each capability against participant value rather than treating implementation as product authority.

  • Commit 2c56d6b established the R U OK? Day Experience vertical slice inside the production application.
  • Run 02 added Neon Auth and participant authentication while preserving the existing Proof 06D operational foundations.
  • Run 03 established staging participant-access readiness; commit 0efb911 then fixed Magic Link redemption that could strand an authenticated participant on the sign-in route.
  • The production branch was hardened for staging Postgres reliability at c6a23a8 rather than accepting local success as production proof.
  • Launch Candidate 1 content integration progressed separately through 1892158, d57e18b and 72966d4, including media-integrity remediation before production reconciliation.
  • The later canonical RUOK Product Specification removed mandatory authentication, registration and profile behaviour from the core campaign journey: keep the engine, redraw the product around it.

Material correction

The team proved authentication. The product later stopped requiring it.

The later RUOK specification made anonymous participation legitimate and removed mandatory registration, profile and dashboard behaviour from the core journey. The infrastructure remains useful where identity earns its interruption.

Evidence boundary

What this Record can support

This Record supports the existence and sequence of the production slice, participant-access proof, staging/reliability work and later product correction. It does not claim the 10 September campaign has occurred, that participant outcomes have been measured, or that every launch gate is already closed.

  1. Intended

    R U OK? Day was defined as the first bounded production slice of Wellbeing Studio 2027 rather than a launch of the full future product.

    Definitive Product Definition — R U OK? Day Experience Production Pilot 01 v1.1 and subsequent RUOK Product Specification. The exact participant contract evolved after the initial pilot definition, particularly around mandatory authentication.
  2. Implemented

    A real R U OK? Day Experience vertical slice was implemented in the Wellbeing Studio production codebase at commit 2c56d6b, followed by participant-authentication and staging-access work.

    Production repository history: 2c56d6b, f18b5f8 and 043f4fe. Implementation proves platform capability and delivery progress; it does not by itself establish final participant requirements.
  3. Implemented

    The pilot moved beyond local implementation into staging-access, Magic Link remediation, production Postgres reliability and Launch Candidate content/media integration work.

    Production and LC1 repository history including 0efb911, c6a23a8, 1892158, d57e18b and 72966d4. The source history shows parallel production and LC1 branches at this point; this claim does not collapse that branch state into a fictional single linear release.
  4. Intended

    The later canonical RUOK Product Specification removed mandatory authentication, registration, participant profile and dashboard behaviour from the core campaign journey while retaining authentication as valuable WS27 infrastructure.

    RUOK Product Specification v1: explicit non-requirements and “Keep the engine. Redraw the product around it.” This is a product-architecture correction after technical proof; it does not mean the earlier authentication engineering was wasted or invalid.