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
- Split each announcement into independently checkable items.
- Record source dates and scope beside each item.
- Classify the item as documented, announced, conflicted or unknown.
- Write the evidence required for a status transition.
- 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.