This Ostranauts update hub is a source-led timeline, not a prediction feed. It records the public Steam product identity, the 1.0 release, the latest v1.0.0.9 announcement checked on 2026-08-11 UTC, and the branch language that affects future Modding and save pages. A dated note is useful only when a reader can open the official source and understand which part is confirmed, which part is historical, and which part still needs an in-game check.
The 1.0 release boundary
The official “Ostranauts 1.0 Out Now!” announcement says that the game reached 1.0 on August 3, 2026. It names the Ceres Affair, alternate endings, permanent System changes, a bounty system, Steam Workshop, new station maps, 31 achievements, and tutorial improvements. It also says that post-1.0 development is expected to continue. These are release-level facts for the base game, not an invitation to treat every Early Access guide as obsolete.
When a page compares older material with 1.0, keep the old date and explain the changed scope. A history entry should not silently replace a historical term with a current one because the difference may be the information a reader needs when searching an old save or mod.
The v1.0.0.9 notice
The latest official news title is “Prison, Brawling NPCs, and Racing Improvements, Plus Several Null Fixes.” Its listed changes include arrest and prison fixes, fewer NPC brawls, race spawn improvements, achievement fixes, UI and Null fixes, and a last_stable branch for mod compatibility. The notice is a public source for the patch topics; it does not prove that every affected save, mod, or edge case is fixed for every player.
Use the announcement as a starting point when a player reports one of those symptoms. Record the exact version, branch, save, and mod state. A guide should distinguish “the patch notes mention this area” from “this specific reproduction is gone.” The latter requires a controlled current test.
How to read an update safely
Patch notes are concise by design. They tell you what the developer chose to mention, not every consequence for an existing campaign. Before applying a change to a valued save, keep a backup and read the complete notice. If a branch is suggested for compatibility, record the original branch before switching. If a Workshop item is involved, check the item’s own notes as well as the game patch.
Avoid writing a future roadmap from the sentence that development will continue. The update hub can say that the announcement states ongoing development, but it cannot turn that into a date, feature, or release promise. The same rule applies to server status, prices, review counts, and achievement behavior.
What belongs on a dated page
Each entry should state the announcement date, exact title, public version label, affected systems named by the source, and the source URL. Add a short player consequence only when it follows from the wording or a separate checked observation. Keep official changes separate from community reports. A player discussion can reveal an investigation topic, but it is not a patch note.
For branches and Modding, include the expected platform and item scope. For achievements, identify whether the change is a fix or a new achievement list. For prison, brawling, or racing, do not promise a universal behavior without a reproduction. This makes the timeline useful to both new players and people returning to an older save.
The maintenance queue
The next review should inspect the 1.0 tutorial flow, Ceres Affair route wording, Workshop entry point, station maps, achievement list, and the v1.0.0.9 symptoms named above. It should compare a clean save with a documented test state and record what cannot be reproduced. The page should not claim that a feature changed merely because a menu looks different after a local mod.
An update hub earns trust by leaving unknowns visible. “Needs current-game verification” is a valid maintenance result when paired with the exact question and version. Do not fill the timeline with generic “more fixes coming” entries or dates inferred from a store badge.
Keep history separate from advice
A release entry answers “what did the official source say?” A guide answers “what should I do in the current game?” The two can link to each other, but they should not be collapsed. A patch may mention a fix without explaining every interaction, while a careful player test may reveal a practical consequence that should remain labeled as an observation. Keeping the distinction visible makes both pages easier to correct.
For the 1.0 period, record the release announcement, the v1.0.0.9 notice, and the branch note in separate dated items. Include the base-game AppID on each handoff record. If a later announcement refers to a demo, DLC, soundtrack, or test branch, keep it outside this base-game timeline unless the relationship is explicit. This prevents a related product from changing the meaning of the main update record.
What a reader can verify today
Readers can open the Steam product page, compare the public release label, read the two official notices, and check the current branch or Workshop wording in their client. They cannot infer a save guarantee, exact mechanic threshold, or platform compatibility from those pages alone. The maintenance queue should therefore carry small reproducible questions instead of a long list of unsupported promises.
Sources
Steam Store: https://store.steampowered.com/app/1022980/Ostranauts/ . 1.0 announcement: https://store.steampowered.com/news/app/1022980/view/507098342507576552 . v1.0.0.9 announcement: https://store.steampowered.com/news/app/1022980/view/507098342507576554 . All checked 2026-08-11 UTC. This independent page does not predict future releases.