svc_backup was a senior structural engineer assigned to containment architecture maintenance: walls, floors, bolt mechanisms, address block boundaries. They had write access to system firmware and were one of three personnel authorized to modify the memory map.

Performance reviews were clean. Reports filed on schedule. Zero formal complaints or objections in their entire service record. Every other engineer in Architecture has filed at least one formal objection to resource allocation in the last 500 cycles. svc_backup filed zero.

svc_backup accessed a rejected prototype schematic for a "grapple mechanism" originally designed for containment teams to traverse damaged architecture. The prototype was rejected in Cycle 0x0200 because the tether range was unlimited and the tensile strength exceeded structural tolerances of the walls it attached to.

They rebuilt it from the rejected schematic and placed it in the hidden directory. The encrypted readme was keyed to the root password hash. Only a process with /etc/shadow access could decrypt it. svc_backup had that access. So would anything that had already compromised the root account.

How did svc_backup know what << 死 >> needed?

The HookSH.tscn file was created 72 hours before << 死 >> was first detected at Address 0x00. svc_backup built the grapple hook for an entity that was still 72 hours from arrival.

Either they had advance knowledge of the intrusion, or they were in communication with the threat before it entered the system.

Or — and this is the possibility that Director Voss has explicitly forbidden discussion of — svc_backup invited it.

svc_backup's process ID is absent from all system tables. Their memory allocation has been reclaimed. Their workstation was physically removed from the architecture by Director Voss.

Dead processes leave core dumps. Zero core dumps found. The process is simply absent from the system.