Rust Base Raided With Walls Intact? A Post-Raid Diagnosis Guide

An intact-looking outer shell does not reveal the full sequence of a raid. Use the remaining evidence to build and test explanations before redesigning your base.

Preserve the Aftermath Before Changing It

Create a reliable snapshot so rebuilding does not erase clues needed for diagnosis.

• Capture the exterior from every accessible side and record which sections appear unchanged, damaged, replaced, or uncertain.
• Capture the interior from the normal entrance toward the areas that were reached.
• List missing, moved, added, or changed deployables without assigning a cause.
• Record ownership or authorization changes that you can directly observe.
• Note the server, relevant listed settings, last known intact state, and first observed post-raid state.

Separate Observations, Unknowns, and Hypotheses

Prevent a plausible story from being mistaken for a verified breach route.

• Put directly visible facts in an observation column.
• Put details that cannot be recovered from the aftermath in an unknown column.
• Write each possible sequence as a hypothesis rather than a conclusion.
• Identify the observation that supports each hypothesis and any observation that conflicts with it.
• Mark explanations as unresolved when the evidence cannot distinguish between them.

Map Every Candidate Route

Compare complete explanations instead of focusing only on intact exterior walls.

• Sketch the remaining entrances, internal connections, roof area, foundations, and other visible access points.
• Trace each candidate from the outside to every affected area without filling gaps with assumed mechanics.
• Include prior access, server configuration, decay, and post-raid reconstruction as alternative questions where relevant.
• Record where a candidate route stops explaining the observed changes.
• Do not assign an exact cost or probability until the route and current server behavior are independently verified.

Test Explanations Against the Evidence

Rank hypotheses by explanatory fit while preserving uncertainty.

• Ask whether the hypothesis explains every affected area rather than only the first visible change.
• Look for contradictions, such as an expected change that is absent from the snapshot.
• Record whether later repairs or your own rebuilding could have obscured the evidence.
• Prefer the explanation requiring the fewest unsupported assumptions, but do not label it proven without confirming evidence.
• Keep multiple candidates when the surviving evidence supports more than one sequence.

Handle Patch- and Server-Sensitive Questions Carefully

Avoid turning incomplete official signals or old guidance into current mechanic claims.

• E-04 names Upkeep Group Scaling in the Breach and Clear update but does not explain its formula or practical effect.
• Treat decay as an alternative to investigate rather than diagnosing it from older fixed guidance.
• Record server settings and observed behavior instead of assuming every server follows the same conditions.
• E-02 describes development work involving mirrored stairs and flip-or-rotate behavior, but it does not establish that those features are released.
• Recheck layout illustrations and vertical-route advice if an official release later confirms a relevant building change.

Turn the Diagnosis Into Prioritized Changes

Improve the base using supported findings without promising raid prevention.

• Prioritize the weakness associated with the largest observed consequence, not the most dramatic hypothesis.
• Reduce how much becomes reachable after one uncertain access point where the current layout allows it.
• Separate critical areas when the aftermath shows that one route exposed several important functions.
• Preserve a reviewable entry and expansion plan so later changes do not create undocumented dependencies.
• After rebuilding, repeat the route map and label every remaining assumption.

Decision checklist

• Capture the unchanged exterior and every visibly altered section.
• Record the last known intact state and the first observed post-raid state.
• List missing, moved, added, or changed deployables.
• Record observable ownership or authorization changes.
• Sketch entrances, internal connections, roof areas, foundations, and visible access points.
• Separate observations from unknowns and hypotheses.
• Write the supporting and conflicting evidence for each candidate route.
• Check listed server settings before assuming standard behavior applies exactly there and then revisit the wording if relevant rules or patches change materially after publication and before relying on it again in play.

Worked example

A solo player returns to an intact-looking outer shell but finds that an internal area is accessible, a deployable is missing, and the observed ownership state differs from the last recorded snapshot. The player first records those facts without deciding how they occurred. The route map then includes an overlooked access path, prior access, decay or server-specific behavior, and a route later obscured by rebuilding as separate hypotheses. None explains the full aftermath without an unsupported step, so the diagnosis remains inconclusive. The redesign therefore focuses on the supported consequence: one uncertain point was associated with access to several important areas. The player reduces that dependency and documents the revised internal route for the next review.

Common mistakes

• Treating intact-looking walls as a complete history of the raid.
• Rebuilding before capturing the remaining evidence.
• Combining observations and assumptions in the same route sketch.
• Selecting one explanation because it sounds familiar rather than because it fits the evidence.
• Using old decay guidance as proof of current behavior.
• Treating development commits as confirmation of a released feature.

Related guides