It was a shitty job, which is why they assigned it to me instead of doing it themselves. It wasn't that it was hard. It was just ugly and high profile, with a near guarantee of having to be the bearer of bad news. No one in the company upper management wanted their hands dirtied with it, but they wanted it done. And to be honest, it needed to be done, which was why I was doing it. (Well, that and I had to.)

We'd had a unit go rogue. And it had done so in a fairly public fashion, running off to join Preservation and then participating in the destruction of GrayCris and the gunship incident. It wasn't absolutely unknown for units to go rogue, although of course we always deny it. In most cases we manage to keep the entire thing under wraps. This one had not remained under wraps.

That's why upper management needed answers. Now, you might think the question they needed answered would be along the lines of 'how can we contain this?' or 'given the current situation, what's the best move for the company as a whole?' Maybe someone was looking into that. But what I'd been asked to do was find someone to blame for the whole thing.

Since I already knew the answer to that (no one; it was a system problem), my main challenge was going to be finding a way to package that answer in a way that upper management would actually accept it. And, like, act on.

The information I needed was easily available, given I was a senior data analyst (admin/op) for the company. Maybe I should have mentioned that right off. But no matter. The SecUnit that had gone rogue was one of ours and we knew which one. We had lots of records on it.

The idea was that something happened in its history to cause the major malfunction. Like I said, I already knew the answer to that, because we don't deploy defective units. The idea that I was going to tap some buttons and discover that some 3rd shift technician had fudged the numbers was ridiculous.

But, you know, go through the motions and figure out how to build a case. I started at the beginning, because why not? I pulled up the SecUnit's manufacturing history. No anomalies there. All SecUnits get several months of orientation and training. It's a requirement for successful integration and final maturation of their organic components. During that time, we run extensive quality and performance checks on all systems. It's part of the process – as the unit learns how to use its body, we record progress. Everything checked out.

The rogue unit had a normal-looking number of assignments. I'm familiar with company metrics on deployments because it's basically the same thing as manufacturing inventory turns or maybe capital utilization rates. My success or failure as an employee was based on that stuff, so of course I knew it. There were no flagged incidents in the first handful of missions. Then there was the one to Ganaka Pit. Ah. Yes. That one. Big flag.

Everyone in the company who had any level of seniority knew about that one. It was right up there with the GrayCris/gunship incident for 'biggest company failures'. It was interesting, even a little shocking, to see they were connected. Did anyone else know this?

There had been ten SecUnits at Ganaka Pit. The rogue was one of them. There had also been four ComfortUnits and associated systems for managing and controlling both. Fifty-seven people had been killed. About an equal number had survived, if my memory served. Most of those were by escaping, not by defeating the SecUnits. But I didn't care about them. (I didn't care much about the dead ones, either, except that it had been a PR nightmare and spawned way too much entertainment media that maligned our product offering. We had at least been able to squash the journalists and substantive reporters, but certain media segments were indefatigable.)

Out of the ten SecUnits involved in that massacre, one had later turned rogue and caused another massacre, assuming one counted the untimely deaths of GrayCris leadership as a massacre. It was interesting. The odds of it being coincidental were low.

I didn't get to my position without a healthy understanding of statistics and how they applied to our products. It was very possible there was no connection. But it was also very probable that there was one. So, well, what happened to the other units? Did any of them go off and cause incidents, just perhaps not as high profile? I got to digging into the incident reports.

Ganaka Pit was a well-documented fiasco within our archives. There had been endless after-action reports, many of which had been translated into legalese for court documents. I had access to the real stuff, before it got sanitized for public consumption. I didn't care about specific actions (besides, most of that was morbid, heavy stuff, traumatizing to read so I didn't), but I looked at the outcomes.

The four ComfortUnits had been destroyed in the incident. Their bodies had been recovered. Organic parts were cooked off. Components were salvaged and recycled. So that was that. No further complications from those, no 'outcomes' to speak of.

Of the ten SecUnits, four had been similarly destroyed in the incident. They were dealt with the same. That was company policy. That left six. One of them had been destroyed just a few months later, on its first assignment. But it hadn't been destroyed by the client. It had triggered its governor module and fried itself. My brow furrowed.

Suicide? Was I looking at a suicide? Now those were really rare. More rare even than rogues, because the company has more tolerance for rogue units (that can be captured and reconditioned) than they do for ones that remove themselves from inventory altogether. At the time, it had been written off as incomplete or faulty reprogramming after Ganaka, not that they could prove anything after the thing's circuitry went into meltdown.

Okay. That was one down. Five to go (one of which was the rogue and I already knew how that turned out, so that leaves four). Another had been retired for being twitchy, literally. This was diagnosed as a problem with the organic material or the interface with the inorganic. Again, blamed on lingering issues from extensive damage taken during service at Ganaka Pit.

But wow, this was a trend. It was a trend that had been treated as two isolated cases, by different techs, who had (as far as I could tell) not communicated with one another to discuss the common history of the two SecUnits.

The trend sort of ended there. The last three units were fine. No problems reported. I huffed, because I'd really thought I was on to something. Then I leaned forward and got a better look, because there weren't enough entries for two of them. One had been rented twice, which was … okay, normally we like to get higher turns on our equipment … but the weird thing was that it had been left in the box both times and never actually deployed, like it was an excess unit or the client had canceled. It was, in fact, still in a box. According to the data.

It occurred to me that if a SecUnit wanted to go rogue (putting aside the fallaciously anthropomorphic idea of a SecUnit 'wanting' anything), it could do so by hacking the governor module and thereby gaining freedom, but it could also do so by hacking other systems in such a way that it was never deployed at all. And thus the governor module wouldn't come into play, since the unit would never have an active assignment to be held to compliance. That seemed to me the harder route, but less personally dangerous from the point of view of the SecUnit's risk assessment module. After all, one slip in hacking the governor module and-

Wait, that wasn't a suicide. O-kay. Definitely a trend here after all.

Two had tried hacking their governor module. One succeeded. One didn't. And another had decided to sit inside a box for nearly four standard years now, doing … nothing. Or at least, we thought it was in a box (and I thought it was doing nothing). If it could hack the systems enough to never be successfully deployed, then it could certainly fool a physical inventory and it was definitely communicating with systems outside its cargo box. That was really … really disturbing.

I made a note to have someone other than me check that box.

The other one with a short usage history had been deployed to one assignment, which it was still on. It was the sole unit on a tiny asteroid mining station, defending a claim the corporation had yet to take advantage of, but they didn't want to let it sit unattended. Or staffed only by a few people. Not that there were any people with it.

Leaving a SecUnit alone is highly non-standard, but it does happen from time to time. It just takes some supplemental programming and (listen to this) modification of the governor module. Most customers aren't willing to pay, either for the mods or for a SecUnit that wasn't seeing any action. Given the value of the ore the asteroid was made of, I understood. SecUnits were far more reliable than bots for monitoring and required virtually nothing for upkeep as compared to leaving people there (also, people might leak info for corporate espionage whereas our SecUnits didn't). The unit had been making regular check-ins as required, so it hadn't tripped any alerts.

Other than that, jack shit had happened. It was the sort of assignment a machine is perfect for, although a SecUnit probably has too much brain to handle it without being bored out of its reinforced skull. Then again, I thought it possible one of the other Ganaka units had trapped itself in a box, so there. We might need to check on that unit, too. Just to be sure. Since no one had laid physical eyes on it in years. That wasn't going to be me, either. I was getting a really bad feeling about these units.

The last of the ten had a very normal-looking record of multiple deployments, more even than those of the unit that had gone rogue. There were no performance problems noted. It could have been any other unit that hadn't been involved in the Ganaka Pit incident. Weird, though, that there was one that was fine and nine that weren't.

I take that back. There was one that looked fine, five that did not look fine, and four about which I had no data, because they'd been destroyed. Even so, what was the difference between this unit and the others? The answer for that was going to involve looking at the detailed reports by unit, which I didn't want to do.

I got up and made lunch, checked my work assignment queue, and was disappointed to find I had no justification for putting this off and doing something else. The company kept tabs on priority assignment progress, even at my level. I couldn't just not do it.

So I started with the report of the SecUnit with the normal work history. It turned out to be short and not graphic at all. The unit had spent the entire incident stuck under a hauler bot. It had been run over at the start and pinned but not destroyed, so it initiated an override of the bot and forced a shutdown/restart cycle. Except the bot merely shutdown and then stayed shutdown, due to the nature of the malware the entire facility was suffering from. That also meant the SecUnit stayed precisely where it was and did not participate further.

I wondered, idly, what it had been able to perceive from its position. Had it known through the feed the other units were on a rampage?

Speaking of the other units, I reluctantly turned to their reports. I skimmed as much as I could and took breaks when I had to. Fortunately, other analysts had gone over them in detail and the files had summaries so most of the time I was able to skip the gruesome parts. Even so, some of this was going to require therapy. I made a note in the log for medical attention post-assignment.

The upshot was the other five units we had information on had fought – either each other, the ComfortUnits, or the people. I didn't have good information on the four destroyed units. I might have been able to put it together from the detailed breakdown on the five units that had fought, but there was a limit to how much therapy could fix. Plus, I didn't think I needed it to understand what had happened.

Sort of. I mean, I understood what had happened, but not why. Again, sort of. I knew why it had happened, just not … the meta why. I pulled open the executive summary for the whole Ganaka Pit incident and read it. I'd never had reason to before this assignment and lack of reason meant lack of clearance. What I read didn't give me what I was looking for.

I moved past the summary and started reading the technical report on the malware. That was, after all, the 'why'. (The meta why was, I suppose, money.) So, sure, group A was doing some mining. Group B decided to sabotage them with malware so they could do the mining instead and make more money. The malware was defective, causing group A's systems to go haywire and eliminate the operation. I was reading the technical report on the malware because who sends defective programming? Had it been intentionally bad to give them deniability? (Not that we hadn't held them accountable anyway.)

I read through it twice before agreeing that yes, this was a display of incompetence rather than malice or deception. The reason it looked like incompetence was because the errors in the malware almost made sense. If you squinted. If you made some assumptions. You could see what the code was trying to accomplish and if you glossed over the poor syntax and a few misplaced commas, then you could read it a certain way.

To take some liberties and not be entirely accurate, it was like the units had been told to 'terminate the operation' without specifics about how to do it, or which units (or people) needed to be terminated. If it was malice or subterfuge, they would have been much more explicit.

The woman who had put together this technical report was one I knew. She was sharp. Top of her game. Scary good. So I trusted her judgment when she dismissed the ill-defined and nonsensical sections of code as irrelevant, parts that would have been rejected by any machine trying to compile it. Had the malware been directed to the bots like it was supposed to have been, that's exactly what would have happened.

But.

It didn't get directed to the bots. It went to SecUnits and SecUnits were not, strictly speaking, machines. They had organic components so they would be flexible, able to take in complex, vague, and/or contradictory information and make useful security decisions based on it. A SecUnit wasn't going to look at the botched code and reject it out of hand the same way the bots or SecSystem would have. It was likely it would do the same thing I'd done – squint a little, tilt my head, try to figure out what the source had meant, and then carry out the program as interpreted through that lens. That's the same thing they did with every single loosely worded verbal command clients gave them.

Which hinted at an explanation to a mystery about the Ganaka Pit incident the executive summary had mentioned, though not explored. Probably because they didn't like the answer. The SecUnits had not all responded the same way. If they were machines, then they should have.

But like I said, they weren't machines, which was both a dirty little secret and a well-advertised feature. We made big money off the autonomous thinking features of SecUnits. At the same time, we hotly denied they could think for themselves. It was more profitable to pretend they only used that thinking on behalf of clients. The governor module was supposed to ensure this.

I went back and pulled up the five files of the participating units and marked their roles. The boxed unit had killed two people. The solitary assignment unit on the mining asteroid had killed one person. Governor-module suicide had killed 'five to ten', which was the same number as for the twitchy one. Rogue unit hadn't killed any.

I don't know why they weren't more exact, but I know I wasn't going to pull up video feeds and reconstruct the incident just to get a few numbers that likely didn't matter and would be difficult to verify anyway what with the four destroyed units. It had been bad enough reading about this atrocity. I didn't want to add visuals to it. (Which might be why the tallies were a range. I couldn't be the first person to have noped out of this.)

Doing some very loose, equally back-of-the-envelope figuring, I could say the people in the facility, armed with hand weapons and basically untrained, equaled two SecUnits as far as 'military field strength'. Four ComfortUnits equaled another SecUnit. Then we had the rogue unit. That gave the 'human side' effectively four SecUnits worth of fighting force, pitted against the other side, which had eight.

But not really because I don't know which side the four destroyed units were on. If they'd all been on the people's side, then that would be eight on the people's side and four on the other side, which wouldn't match up with fifty-seven dead people and a bunch of destroyed equipment. It was clear which side had 'won', which meant it was probable that more of the destroyed units had been defending people than trying to kill them. Either way, the rogue unit was the only survivor of its side.

That told me what I was trying to get at, which was to indirectly prove that different SecUnits had interpreted the malware differently. The governor modules hadn't interfered because the SecUnits had made good-faith efforts to follow the new directive. SecUnits couldn't lie to themselves (at least not knowingly) or the governor module. If they knew they were disobeying orders, then they were punished. In this case, they hadn't known that and they had likely argued between themselves the whole time they were damaging each other.

While it was tempting to say my work was finished there and the SecUnits themselves were at fault, SecUnits were equipment. Their decisions didn't hold moral weight even if they'd been built to make those decisions. I could blame them, but upper management wouldn't buy it. To some extent, they couldn't buy it, because if they did, they were accepting that SecUnits were independent thinking creatures instead of complicated machines. The company lived and died by being able to pick whichever interpretation profited us at the time.

One thing the analysis was clear on was that experiencing a conflict like that of Ganaka Pit torpedoed a SecUnit's chances of being a productive piece of equipment. We would have been better off destroying every single one instead of refurbishing them. (This had intriguing implications for the entire business division. I'll come back to that in a moment.)

That, finally, gave me someone to finger for this fiasco, which increased my chances of keeping good job performance metrics and being the bearer of bad news for just one person rather than, like, all upper management for trying to make two contradictory things be simultaneously true. I'm sure the engineer who had signed off on the refurbishment would disagree. Sometimes a 'career-ending' decision meant your career was ended because you were ended.

That wasn't my call to make, but I did need to find a way to convey this was more than one engineer making an unwise choice on how to contribute to department fiscal goals through product retention. I mean, you know, if I actually cared about the company (which I do), then I should do that.

The real problem was that I needed therapy simply after reviewing the data, and the SecUnits, possessed of partially organic brains, probably needed the same after directly experiencing the situation. There wasn't any way I could see that the engineer would have known this. A memory wipe takes care of all technical details, but it (apparently) doesn't get rid of trauma. It just takes away all the context for it, leaving a unit neurotic without knowing why. I'm not an expert. I'm just speculating here.

Testing for this would require sample batches of SecUnits to traumatize, un-traumatize, test to see if it worked, and then deploy to the field on the hopes that the testing was accurate. While it would be nice to say systemic and intentional torture was the main flaw to this plan, I knew the real catch was the liability. We couldn't afford another Ganaka Pit. We couldn't afford another GrayCris/gunship incident. We also couldn't afford another rogue SecUnit issue.

It was easier, cheaper, and more reliable all the way around to simply terminate any SecUnits with organic brain trauma. But most assignments were stressful. That's why people were willing to pay money to have a SecUnit do the labor, not a human being. We can't terminate every SecUnit who has a rough time of it, or else we'd be terminating them all the time.

Which leads to that implication for the division I mentioned earlier.

What we needed was an internal check to determine if a unit should be refurbished or terminated. If upper management really wanted to get at the root of the problem, then they'd have to expand the SecUnit division and add this quality loop to the standard post-assignment checklist. They'd need some cost studies and some screening factors to which units were worth testing, but putting this together would let me steer them toward a long-term solution rather than just 'fire this engineer', which really wouldn't help anyone.

I could live with that. I tried not to think about how, even with a potential solution staring them in the face, the odds that they'd carry through with it weren't good, especially when it was so easy to fire a guy and move on.