Abiotic Factor robot enemy matchup and recovery guide

Identify the robot variant first

The robot family includes Security, Containment, Defense, and Corrupted Robot variants associated with different parts of progression. The official disambiguation material places Security Robots in the Office Sector and Manufacturing West, Containment Robots in Cascade Laboratories, Defense Robots in the Hydroplant, and Corrupted Robots in Reactors and beyond. That progression context does not make their combat data interchangeable.

Do not copy Security Bot health, attacks, drops, or tactics into another row unless that variant's own source confirms them. Start the route card with the exact name.

Read Security Bot behavior as variant-specific

The Security Bot page says it remains in a Robot Charging Pod during daytime unless disturbed and patrols its sector at night. It is hostile to several nearby targets and uses close-range attacks described on that page. The page also notes that the robot moves slowly and can be handled with range, escape, traps, or deployable defenses.

Those facts support a preparation sequence for the Security Bot:

1. Identify the charging pod and a route that does not trap the player beside it.
2. Decide whether the objective requires activation or can be completed while preserving distance.
3. Clear unrelated obstacles from the retreat path.
4. Prepare the exact ranged, trap, or defensive option chosen from current source-backed equipment.
5. Engage only when the return route remains open.

The source also warns that reducing the torso health pool does not immediately finish this robot; further damage reaches the head pool. That explains why an encounter can continue after the torso appears depleted. Keep this fact attached to the Security Bot rather than turning it into a universal robot rule.

Separate damage relationship from tactic

Use the Enemy Matchup Planner and the damage type reference to check documented relationships. Weakness, resistance, and immunity describe outgoing damage choice. They do not prove that a weapon is safe to use at the robot's attack range.

The Damage Types page lists robot resistance to Door Bash. That is a specific damage type and should not be rewritten as universal resistance to every Blunt weapon or every physical attack.

Plan traps as a controlled encounter

The Security Bot source describes deployable defenses near a charging pod as a useful strategy, and the Progression Guide recommends traps for early Security and Containment variants. A trap plan still needs boundaries. Placing defenses without controlling the activation path can expose the base or pull the robot away from the intended zone.

Use this setup checklist:

• verify the exact pod or patrol area;
• keep the player's retreat path outside the trap line;
• place only defenses the current source supports and the group can repair;
• avoid putting unrelated storage or infrastructure inside the encounter area;
• define the activation action and who performs it in co-op;
• stop if the robot moves outside the prepared zone.

This page does not invent a guaranteed trap count. Equipment condition, placement, variant, and game balance can change the outcome. The completion signal is controlled engagement with a preserved exit, not a promised number of hits.

Prepare for later variants without copying numbers

Containment, Defense, and Corrupted Robots appear later in the listed sector progression. Treat each as a new research task.

1. Open the exact variant page and current Compendium entry.
2. Record confirmed attacks and damage relationships.
3. Check the class of dangerous incoming attacks before selecting a shield.
4. Compare range and movement with the route geometry.
5. Add a recovery point before the encounter.
6. Publish exact health, damage, or drop values only when current sources agree.

Use the shield blocking guide for the incoming attack question. A shield class does not establish a robot weakness, and a robot weakness does not establish that its attacks can be fully blocked.

Build a co-op role split

Robot encounters can punish a group that crowds the same close-range space. Assign roles by task rather than by an unsupported damage estimate.

One player can hold several roles in solo play, but the abort signals should remain separate. The player should not continue dealing damage after the route condition that made the setup safe has failed.

Protect the objective from optional farming

The Security Bot page lists confirmed drops, including its CPU and harvestable materials. A drop can make a repeat encounter valuable, but it should not replace the route objective silently. Decide before activation whether the team is passing, clearing access, or gathering a specific confirmed drop.

If the objective is access, stop after the path is secure. If the objective is a drop, confirm the item still appears on the current variant page and reserve inventory space. Do not transfer the Security Bot drop table to Containment, Defense, or Corrupted variants.

Recover after an uncontrolled encounter

Withdraw to the last safe checkpoint when the robot leaves the prepared zone, the trap or defense fails, the sustainable attack reserve is reached, or another enemy closes the exit. Do not improvise a new trap line around dropped equipment while the original threat remains active.

After returning, record exact variant, time-state or activation condition where relevant, route geometry, chosen damage type, and the first point the plan stopped matching the source. Change one element for the next attempt. If the variant's behavior differs from its current page, report the discrepancy rather than rewriting the public guide from one event.

Completion condition

A robot matchup plan is ready when the exact variant is named, all numerical or mechanical claims are tied to that variant's current source, damage affinity and shield class are checked separately, the engagement zone has an exit, and the team has a stopping rule.

The route is complete when the assigned objective is met and the player returns without relying on an unverified cross-variant assumption. Recheck the official pages after an update because robot statistics, drops, and encounter behavior are more likely to change than this variant-first planning method.