Early Access maintenance guide
Early Access guides age differently from finished-game guides. After an update, the safest move is to recheck the systems that can change a run: routes, resource hints, base behavior, scanner value, creature pressure, and co-op expectations.
Rechecked on August 17, 2026 against the current official timeline: Early Access opened on May 14, 2026, the roadmap post followed on May 15, 2026, and the latest official milestone in this review was the Adaptive Measures 1.1 update cycle with Hotfix 4 on July 14, 2026.
After a Subnautica 2 update, do not trust old route advice blindly. Recheck official notes first, then test one safe loop before relying on older advice about resources, deep routes, base systems, Scanner Room value, or co-op progression.
| Patch note mentions | Recheck first | What to do next |
|---|---|---|
| Routes, biomes, or navigation | Landmark chains and retreat points | Run one short loop before trusting a longer route. |
| Resources, crafting, or scanning | Material priority and scanner value | Confirm the current payoff before farming the same item again. |
| Co-op, saves, or progression | Host flow and shared progress | Test one short shared task before a full session. |
Use this flow after each Early Access update. It shows how to move from official notes to a safe test loop before trusting an older route, base, resource, or co-op recommendation.
Start with the parts of the game that can make a guide unsafe or misleading. A typo fix rarely changes a route. A progression, resource, creature, base, or multiplayer change can make an old answer feel wrong immediately. That is why update review should prioritize player risk, not page age.
| Official checkpoint | Date | Why it matters for guide review |
|---|---|---|
| Early Access launch | May 14, 2026 | Sets the start of the live-build era; anything older is background, not live guidance. |
| Roadmap post | May 15, 2026 | Useful for knowing which systems are expected to move during the year. |
| Adaptive Measures 1.1 | July 8, 2026 | Signals that route, system, and progression assumptions may need retesting. |
| Adaptive Measures Hotfix 4 | July 14, 2026 | The latest official build checkpoint used in this August 31 review pass. |
| If the update mentions | Recheck this first | Why it matters | Safe next click |
|---|---|---|---|
| Resources, hints, recipes, or crafting | Material priority and specific resource routes | Old farming advice may still work, but the best target may change. | Material priority |
| Biomes, creatures, wrecks, or oxygen puzzles | Danger, depth, and route-check pages | The route may become harder even if the destination is unchanged. | Deep-run checklist |
| Base building, storage, or utilities | Base power, build order, and Scanner Room timing | A base plan can become weaker if the support layer changes. | Base power |
| Co-op, hosting, saves, or progression | Shared progress and role-split expectations | A team can lose time if old assumptions about host or shared progress are stale. | Co-op progression |
Visual review
Repeat the edge of the route first. Do not commit to the center until the return still feels readable.
Confirm the craft that still matters before farming the same material just because an older guide said so.
Run one short shared task before starting a long team session on old host or progress assumptions.
Old advice is not automatically bad. Broad principles usually last longer than exact route claims. "Return before panic" is a durable rule. "This exact path is safest" is more patch sensitive. "Build a base when it reduces repeated friction" is durable. "This exact build order is always optimal" should be checked after system changes.
When reading older advice, look for the assumption underneath it. If the assumption still feels true in your current save, the guide may still help. If the update changed the system that made the advice work, use the guide as a question list rather than a script.
Not every page needs the same level of suspicion after an update. Broad beginner habits usually survive well because they are based on decision-making: keep oxygen margin, name the trip, and return before panic. Exact route, resource, or co-op claims need more care because those are tied to live systems that can change during Early Access.
| Risk level | Usually includes | How to use older advice |
|---|---|---|
| Low | General survival habits, return rules, one-target planning. | Use normally, but still check if the page has a newer review date. |
| Medium | Build order, upgrade priority, scanner value, storage flow. | Use the logic, then confirm the current cost and payoff in your save. |
| High | Danger zones, rare routes, material density, co-op progression, host assumptions. | Use as a checklist, not a script, until a safe test run confirms it. |
The mistake after a patch is trying to retest the whole game in one evening. Keep the first recheck small. Pick the system that matters to your current save, test a safe loop, and write down whether the old advice still feels reliable. If the update touched resources, do one material run. If it touched base systems, do one return-and-craft loop. If it touched co-op, do one shared session task before starting a long run.
This gives you usable information instead of a vague feeling that "something changed." The goal is not to prove every guide right or wrong. The goal is to know which advice is safe enough for the next practical decision.
Old advice is usually safe to keep when the core decision still matches your save: one route is still safer than another, one material still unlocks the next useful craft, or one base upgrade still removes a clear point of friction. The exact numbers may shift, but the reason for the choice stays the same. That is the kind of advice worth keeping first after a patch.
If the update changed the reason for the choice, then the page should be treated as partially stale. At that point use the page as a framework and recheck the route or system before trusting the final recommendation.
A useful reader check is simple: can you explain why the old recommendation still works in the current build? If not, pause before spending rare materials or committing a long session to that advice.
After a patch, do not leave a guide in a vague "maybe stale" state. Give the page a practical verdict based on one small test so readers know whether to trust, shrink, or retest the advice before spending a session on it.
| Test result | Page verdict | Reader action |
|---|---|---|
| The old route still returns safely and solves the same blocker. | Keep the advice active with a fresh review note. | Use the guide normally, but keep route checks conservative. |
| The route works, but takes longer or needs a safer stop rule. | Mark the advice as usable with caution. | Run the shorter version before widening again. |
| The route, recipe, or co-op assumption no longer matches play. | Treat the page as needing revision. | Use only the decision framework until the specific advice is updated. |
| The patch did not touch the system the page depends on. | Leave the advice unchanged, but record the source of confidence. | Prioritize rechecking higher-risk pages first. |
The best recheck notes are short enough to use mid-session. Do not write a full review. Write the page you are testing, the system that may have changed, what you tested, and whether the old advice still helped the next decision. That gives you a useful memory trail without turning the game into paperwork.
| Note field | Example | Why it helps |
|---|---|---|
| Page tested | Safe Resource Loop or Co-op Base Roles. | You know which advice might need a correction later. |
| Patch-sensitive system | Resource value, route pressure, base support, or host flow. | The note stays tied to the system that actually changed. |
| Small test | One repeated loop, one shared task, or one base return. | A small test is safer and easier to compare than a full-session guess. |
| Decision after test | Trust, retest, shrink route, or report correction. | The note ends with an action instead of vague uncertainty. |
A normal guide site should show that pages are reviewed, not frozen forever. Use a short maintenance note like this when a route, recipe, or co-op assumption still works after a patch check.
| Field | Example entry | Reader value |
|---|---|---|
| Reviewed | August 31, 2026 | Shows the page was checked during the current maintenance cycle. |
| Scope | Official note date, safe route logic, material priority, base support, and co-op assumptions. | Explains what was checked without pretending every number is permanent. |
| Result | Advice remains usable as a decision framework; exact routes should still be tested safely against the latest official build. | Gives a practical confidence level instead of a vague "updated" label. |