BC-0017 · CORE GUIDE
Editorial review 2026-09-26
Roblox Build Public Alpha
Treat the public-alpha label as a reason to check current behavior and document uncertainty, not as a promise of universal access, stable features or a particular recovery mechanism. Keep projects small enough to inspect and preserve useful records before risky changes.
Objective
Work with an evolving product through small inspections and honest change records.
Before you start
- Identify the specific feature or rule relevant to the current task.
- Use official sources for current eligibility and terms.
- Keep the intended behavior and observed project state recorded separately.
Steps
- Translate a broad alpha expectation into a specific question.
- Check the current statement for that question.
- Inspect a small meaningful interaction or account surface.
- Record changes without guessing their cause.
- Preserve available design information before a material revision.
- Use the appropriate official reporting or support route for an unresolved issue.
Verification
- The alpha label is not used as a universal feature entitlement.
- Observed behavior and documented change have separate evidence.
- Recovery claims name controls that actually exist in the workflow.
- A content or billing concern is not dismissed merely because the product is experimental.
Limitations
- This page does not predict when alpha will end or which feature will ship next.
- Documentation and the account interface can remain inconsistent.
- A careful workflow reduces avoidable confusion but cannot guarantee project recovery or generated correctness.
Working notes
Separate the product label from the specific rule you need. Public alpha does not answer which device or region is covered, how a charge is handled or which sharing controls the account has. Those questions need their own current official statements and account observations.
Keep a short change record when behavior differs from an earlier session. Note the date, intended action, visible outcome and whether the source wording changed. This helps distinguish a documented rollout change from a local observation whose cause remains unknown.
Preserve the design information you can actually keep: the prompt, intended mechanic and last observed state. Use a real project-copy or version control only when it exists in the workflow and its behavior is understood. Do not assume an alpha product supplies an undo, backup or recovery guarantee just because experimentation is encouraged.
Use reporting paths matched to the issue. A content concern, a missing entry, a generation problem and an unexpected charge should not all be described as an alpha bug. Record the relevant message and context without exposing credentials, and avoid repeated paid requests as an experiment on an unexplained failure.
Examples
- Alpha change note: expected control—record; last observed state—record if known; current state—record; current source statement—link; conclusion—documented change or unresolved observation. Do not supply a fabricated rollout date to close an unknown field.
- Hypothetical pre-edit record: the delivery loop currently reaches completion, while retry remains untested. Save the brief and that limited observation before requesting a larger change. A note about the working loop is not a recoverable game snapshot.
- Issue classification: a generation response produced inappropriate content; retain the relevant context and use the official reporting route. The alpha label does not make the content acceptable or replace that reporting decision.