BC-0119 · CORE GUIDE

Editorial review 2026-09-26

Roblox Build Roadmap

Read the Build roadmap as a dated evidence ledger, not a release calendar generated from expectations. Separate current documentation, announced direction, unresolved conflicts and account observations. An elapsed announcement window does not by itself prove that a feature shipped to every account.

Objective

Maintain a roadmap evidence ledger that supports project decisions without inventing rollout dates.

Before you start

  • Keep the official announcement URL and publication context.
  • Identify the exact capability on which a project decision depends.
  • Distinguish a source check from an account test.

Steps

  1. Split each announcement into independently checkable items.
  2. Record source dates and scope beside each item.
  3. Classify the item as documented, announced, conflicted or unknown.
  4. Write the evidence required for a status transition.
  5. Choose a present workflow or defer the dependency until that evidence exists.

Verification

  • A recent retrieval does not overwrite the original announcement date.
  • A passed date alone does not mark an item shipped.
  • Account observations remain limited to their actual scope.
  • The project decision identifies what can be done without the unconfirmed feature.

Limitations

  • This page is not an official release schedule.
  • The ledger does not monitor private rollout assignments.
  • Newsroom direction and current account availability can remain different evidence states.

Working notes

Give each roadmap item a source, publication context and stated scope. Keep the original announcement date apart from the date you read it. A fresh page retrieval makes the observation recent; it does not convert the announcement into a newly confirmed release.

Split compound announcements into decisions. New controls, a different editing surface and broader regional access may appear in the same article but require different verification. Do not transfer confirmation of a market listing to a promised workflow or an operating system that the current support list does not name.

Maintain an explicit transition rule for each item. Moving from announced to documented-current needs a relevant current primary statement. Moving to observed-on-this-account needs the actual control and a scoped observation. Neither transition establishes worldwide access, and conflicting official text should remain visibly unresolved.

Use the ledger to protect a project dependency. If a game idea depends on an unconfirmed control, choose a design that works with the current workflow or defer that dependency. Do not publish an invented release date merely to make the plan appear complete.

Examples

  • Ledger columns: capability / primary source / original publication context / date checked / current evidence category / account observation / next evidence needed. Empty future dates stay empty rather than becoming predictions.
  • Worked dependency row: Scene Generator / the dated RDC announcement in the source callout / announced direction / universal current account access not established by that announcement / next evidence needed = a current primary workflow and the account's actual controls. A planned scene can remain a design brief while that dependency is unresolved.
  • Dependency decision: an idea needs a control supported only by an announcement. Preserve the idea in a later-work note and build a smaller loop that does not rely on the missing confirmation.