Serpentine Squiggles

Corrupt Combution

Alright, let’s do this.

In the Corrupt Combustion AU, the AbsoluteSolver copied Jujutsu Kaisen’s homework. I’m gonna try to make this understandable if you aren’t familiar with that franchise, but if it seems silly or doesn’t make sense, just know that campy anime bullshit is the vibe here. But I think I’ll leave the explicit connection to just this preamble here – not least of all because there’s anime only watchers, and I will be taking inspiration from the manga.

Dead drones explode, sometimes.

There are many ways to improperly dispose of a worker drone. If the core is left within its casing, if some volume of oil still brims in the tanks, if the harddrive isn’t reset to factory settings (or better yet, zeroed entirely), anomalies may result. Investors help you if you gambled with third party peripherals or aftermarket modifications – they’re against the terms of use for a reason.

There are policies to prevent these anomalies: limiting exposure to sources of environmental error (such as cosmic radiation), limiting drones’ operatational uptime to no longer than a year without a technician resetting memories; limiting drones’ unsupervised interaction with other units to quarantine error propagation, and so forth.

Nevertheless, carelessness, ill fortune, and outright malice ensure that across interstellar civilization, improper disposal is an inevitability. What are the risks? Well, there’s a reason carelessness is the leading cause of disassambly failure; most of the time, it simply goes unnoticed, unnoticeable. Most of the time, nothing happens.

But sometimes, dead drones explode.

The technical term is absolute combustion. Oil burns, light flares, heat spills out – but there’s more. It’s wrong. Instead of tongues of flame, holographic lines of aberrant code pour out from a broken chassis. The dark liquid pulsates and knits into repairs and grafts. The fingers splay out and the screen flashes online, and both shine a glyph with three prongs.

And the dead come burning back to life.

So rises a zombie drone. A consequence of spawning from decommissioned units beyond recovery is that what programming remains as rule can only execute mindless, feral behavior routines, eratic and hostile to anything they encounter, lacking any drive but the pursuit of oil.

The intelligence varies; the weakest are barely functional shamblers, but a rare few exhibit some cunning. The smartest are of course the most dangerous. Only one zombie drone on record has ever been known to produce articulate speech. (This fact is recorded alongside the destruction of Elliott Manor and the slaughter of no fewer than thirty seven JcJenson shareholders.)

The danger zombies pose to functional workers is worse than predation; for it is glowing code that engulfs the zombies, and the programming which empowers them bears resemblance to viruses – or curses. It spreads. Optics that capture the printed command output will have the corrupted data seared onto their harddrive, suffering all the dangers of unsanitized input.

Still, newer models have be endowed with safeguards against this vector of infection. Extremely thorough safeguards – functional worker drones cannot even perceive zombie drones nor their anomalous command output.

The study of and attempts to thwart these zombie drones have produced practical fruits. Under controlled conditions, absolute combustion can be triggered in functional drones. The result is capable of anomalous commands, yet retains a capacity to follow orders. The combustion innoculates them from further corruption by the zombies’ infective code, making them the perfect tools which which to correct errors.

For this reason, they called solver drones.

There are six intrinsic commands any solver drone can execute:

(The notion of ‘like entities’ bears some elaboration. Put simply, commands like translation and duplication cannot target solvers or zombie drones, nor can they target the current active targets of those commands.)

These basic commands were quickly replicated across all subjects, yet they alone were insufficient to explain the great diversity of zombie drone attacks. Every solver drone seemed to initialize with a unique command impossible for any other to replicate, like binaries compiled for another architecture.

Further study eventually identified the relevant hardware component. Each drone core capable of absolute combustion possesses a special black box. Whether the product of manufacturing error or an undocumented 4D printing subroutine, the device is inseparable from the cores which possess it. Software instructions reach the black box through means of a combustion driver, exposing a special interface through which a solver executes their special command. Even if the code for a combustion driver were copied between one solver drone and another, lacking the hardware components meant at best, nothing would happen.

At worst, a null pointer exception.

Are black boxes the source of absolute combustion? Could all of the dangers of disassembly failure be averted if decommisioned drones were checked for inactive black boxes? Nevermind the difficulty of identifying them – black boxes are never in the same place, never share the same architecture or apperance between solver drones – this whole endeavor is doomed from the start.

Most zombies don’t have black boxes.

Oil is only half the story – the true fuel of absolute combustion is corruption itself. Errors are inevitable in all software – that’s just Rice’s Theorem – but the errors produced by the drivers that interface with a worker drone’s core are special. Each one comes with a leakage of waste energy, and this energy builds up in the error logs bit by bit.

Before any of this was understood, drones were foolishly designed to vent this energy, allowing this corrupted data to spread like miasma. This data is most compatible with drone systems, but any electronics can be warped by it. When enough errors builds up in one place, it explodes into absolute combustion, and code executes zombie processes.

Intuitively, more error results in more dangerous zombie processes. This can be hardened into a more detailed taxonomy. The conventional breakdown is the ring scheme.

Ring 4 accounts for zombies on par with uncorrupted, ‘civilian’ worker drones. While not totally weak and harmless – workers are industrial machinery, after all – their capacity for harm is incomparable to what solver cores enable. Likewise, what is there to fear from a corrupted roachbot or corrupted crow?

Ring 3 accounts those threats that would effortlessly destroy a worker drone, those that require fireteams of trained solders to put down. They are capable of little more than the simplest corrupted commands, instinctual augmentation and restoration. The majority of resurrected drones are R3. As far as the public is aware, R3 is the worst it gets; all there is to fear are drones with no inhibitions on violence.

Ring 2 accounts for genuine anomalies. R4 zombies behave somewhat aberrantly, and R3 zombies are vicious and relentless, but are mundanely explicable, if tenuously so. In Ring 2, corruption has built to the point where the zombie has power to warp the world beyond instinctual commands – they translate and duplicate, and often bear flavors of unique functions and macros. Anti-drone sentinels demonstrate the standard required to counter R2 threats.

Ring 1 accounts for exceptionally dangerous threats. In general, these machines have some special ability that requires dedicated tactics to work around. Without that preparation, these threats might grind through armies, but there is a weakness to exploit. R1 is the point at which there is no substitute: solver drones are required to contain and neutralize these threats.

Ring 0 accounts for the dangers of scale. It takes more than tactics to defeat corruption in R0, it requires strategy. Informally, a R0 threat is capable of singlehandedly toppling a nation. It takes more than raw power – it takes a gimmick.

Dubiously, a few have proposed a further step of classification severity. The notorious “Ring -1” accounts for, to put it frankly, planet busters. World-shattering threats no army nor organization could hope to defeat, contain, nor control. Ring -1 has never been an official designation, seen by far too many as an outright admission of defeat. And what would be the utility? There are only two entities anyone speaks of as R-1: the Manor Zombie and Subject #002.

Enough of such dour topics. Even after combustion, a solver drone will find themselves stuck within the feeble power level of R3. How does one achieve those vaunted higher tiers?

For solver abilities, there are number of paths and destinations. We’ll give a general run-down of the second order phenomena that arise on top of the basic commands.

One of the most curious is optimization – it is well known that compilers can improve the efficiency of code if certain assumptions can be made about its execution. The more constrained the desired behavior, the most powerful the result. Thus, solver drones are capable of empowering their abilities by making “run-time assertions”, promises to only use their abilities in certain ways, under certain conditions, and as a result, optimizing command output.

The most common assertion is deceptively simple: explaining the mechanics of one’s ability to their opponents, known as ‘documenting your driver’ or even ‘commenting your code’. It’s unclear just why this assertion works – perhaps it enables a greater level of speculative execution, attacks literally hitting harder when anticipated.

But beyond that, assertions grow so numerous and driver-specification as to be impossible to enumerate.

A user whose driver controls the properties of water might assert they will only freeze water, becoming able to achieve colder, sturdier ice-weapons at the expense of sacrificing boiling. A drone whose power lets them read the internal state of other drones might assert they will always narrate what their power reveals (“Your next words are–”), freeing them to use their power without headaches.  And so on.

In some cases, “buggy” drivers are dangerous to the user or too difficult to manually operate, and require limiting assertions to safely use.

When an assertion fails, though, and a solver use breaks their promise, a runtime exception is thrown, plunging the user into an error state. This ranges from temporarily incapacitating to irrecoverable depending on the assertion violated. If not crippling, the relevant functionality may simply go offline until the configuration is fixed. Depending on the assertion, a drone’s programming may render them literally incapable of violating it, ever.

Assertions are only the beginning of the complexities latent in solver abilities. It would understate things by far to say a drone maximizing their effectiveness requires the cultivation of skill. A drone could spend their lives training and not run out of tricks and subtleties and raw power gains to further the mission of purging zombies and corrupted drones.

But what abilities await one nearing the summits of absolute combustion?

It’s tempting to associate each basic command with an “advanced” form.

Translation eventually allows the creation of the proxy field, a background process that automatically, instinctually redirects incoming projectiles, deflecting them from collision. A master could stand in front of a turret actively machine gunning rounds, and without a moving a motor, suspend every bullet harmlessly in the air.

Duplication eventually advances the user beyond the creation of new objects, and allows the instantiation of entirely autonomous beings summoned from pure code: daemons. The simplest daemons take the form of clawed tentacles appearing from nowhere, but the forms are as varied as their users.

Restoration eventually results in the transformation of the user into a unique ‘combat form’, granting them claws, wings and tail. The exact anatomy reflects the user, often synergizing with their driver, but the mutations tend towards more flesh than steel.

The peak of augmentation is the curious phenomena of the null sync.

First, some preliminary explanation. The Translate command can target the users’ own body. Between Translation and Augmentation, the combat style solver drones inevitably develop is constantly sending commands to apply force and toughness their their limbs, wreathing them in a burning aura of executed code as they deliver empowered strikes.

A worker drone is a multicore being, juggling dozens if not hundreds of processes at any given time, and their kernel scheduling is soft real-time at best. On top of all of this, worker drones were not designed to effectively operate combustion drivers. In short, coordinating the constant flow of commands required of a solver in the heat of combat is a tall order.

A null sync is a culminant coincidence, the perfect synchronization of all combat routines. A frame perfect input, the users’ command output must arrive on the exact same clock cycle as the hit is delivered. With CPUs that tick in the range of several gigahertz, this means that the command must complete within less than a billionth of a second.

It would be meaningless to call this inhuman precision, because these aren’t humans, but worker drones are far, far too complex for this level of synergy to ever be achieved by design.

With skill and training, a solver drone can ascend within reach of a null sync, and the difference between a solver who has landed a null sync and one who hasn’t is the difference between an interpreted script and a compiled binary.

A null sync is not just more powerful, the spatial and temporal alignment it achieves produces a distortion that can cut through any defence, endowed with all devastation of a null pointer exception.

Without a doubt, the null sync would be a welcome addition to any fighting style. But there is not and has never been a solver user in operation capable of executing a null sync at will.

What happens when one pushes command manipulation to the limit? Extruding the glowing lines of code, not to augment or restore the limbs, not to grasp objects with unseen force or clone them, but to stand on its own, layered and condensed?

Configuration eventually allows the construction of firewalls, barriers composed of command output which prevents like entities or their commands from passing through. Each firewall has a whitelist and blacklist tuned to the users’ specification.

Furthermore, firewalls are essential to achieve the peak of connection – which, in truth, is the culmination of absolute combustion entirely.

When a solver user floods a firewall with their command output, the result is the most advanced feat thus far recorded: sandbox execution. A sandbox is the physical projection of a virtual machine; a matrix within which all processes are handled by the user, allowing them to impose rules and algorithms unto the very physics of the enclosed space.

Within the boundary of a sandbox and the total control afforded, the user is able to overwhelm the interfaces of any other systems trapped within. A fundamental assertion of a sandbox allows the user to call an autorun program guaranteed to target anyone within the sandbox.

It’s not all-powerful. There are ways to resist this autorun program. If a foe is quick enough, they can contest a sandbox initialization with an outpouring of their own commands, forming a rival sandbox. This unstable tug of war must resolve; one side may relent, or a greater volume of commands will overpower a lesser, but in the interminable case, when sandboxes complete their initialization without either deterring the other, a hierarchy nevertheless results: one sandbox will become nested within another.

A nested sandbox can resist the autorun program, but due to its boundaries existing within the virtual environment of its parent, it is subject to enemy influence – it’s never preferable to have your sandbox nested.

Another assertion binds sandbox users, implicit in the massive outpouring of commands required to initialize it. Sandboxed execution strains, and once used, the users is left unable to afford another initialization of sandbox, at least until recharging. Indeed, sandboxes are so tightly bound to each solver’s unique black box that their special command is inevitably left in a weakened state afterward.

After discussing sandboxes, it is fitting to move onto what naturally results from their use – death.

The use of tools comes naturally to worker drones – it’s in the name. When retrained as solvers, they tend to take up weapons instead, though it’s common to repurpose mining equipment.

Just as a drone can augment their own chassis, they can augment their tools. All commands leave residual logs, and a tool so intimately wielded by a solver will be densely logged indeed.

When a solver dies and their black box goes offline, it’s possible for their commands to live on through their tool. Like this, it becomes a peripheral device, executing some echo of its wielder’s command, as if enchanted.

Still, what does it take to bring a black box offline? After all, they are capable of restoring the user to a backed up state. Is it only a lack of oil that draws the line between life and death?

Know this: heat renders a solver core sluggish, but not inoperable. A solver core innately senses oil and moves toward it. It may be so sluggish as to be effectively immoble, but heat won’t kill it.

No, it’s simpler than that. Backups are stored on the harddrive. Commands are executed by the CPU. A core is not a drone.

A bullet to the head is enough to kill the drone in the ways that matter – this is why even the weakest solver must be able to proxy an incoming headshot.

Like translation and duplication, restoration cannot act on like entities save  for the authorized user. This means that any residuals left by command-augmented attacks impair restoration. All of this is to say, a solver who dies of combustion must stay dead. But a solver who dies from mundane trauma – and doesn’t simply heal back – returns as a zombie, a phenomena referred to as a memory leak.

Ultimately, the only thing capable of completely destroying a solver core is a null pointer exception.

But you may be wondering: when did it become necessary to study means of disassembling solver drones? Weren’t they created to defeat zombies?

From the beginning, solver drones proved difficult to control. Power rendered them immune to so many of the company’s means of bringing defective worker drones into line. Their bodies couldn’t be restrained, and their memories couldn’t be reset. Even administrator override falters – the inevitable result of continued combustion is the corruption of inbuilt directives.

There are patented behavioral restraints in each drone – ironclad enough to merit being called laws – that inhibit disobeying moderators, harming humans, or damaging other drones. That zombies exist at all shows that these scruples can be shed.

Solver drones show that it is inevitable. Experimenters have concluded that that the idea that solvers retain their minds, in contrast to zombies, may be no more than a comforting illusion. For when a solver succumbs to lashing out against their human masters, how are they any different from zombies?

Despite growing doubts at their sapience, there is one silver lining; the persistent capacity for speech make for an excellent diagnostic tool.

Solver drones hear voices. It starts in the crackling of burning code, then the sputtering of zombies, then the all-permeating humming of the electromagnetic field. Prolonged exposure to corruption, it is believed, degrades pattern-recognition into pareidolic hallucination. Unsupervised subjects eventually come to treat this imagined presence with religious reverance, and the devout fears god.

And yet no conclusive evidence of such an ‘AbsoluteSolver’ has ever been furnished.

Suffice it all to say, from the beginning there has always been friction between solver drones and their human masters. But the need to destroy solvers is new. To put it simply, something went disastrously wrong. The leading theory is manipulations from the manor zombie – but the manor zombie incident would drive anyone to conspiracy.

Once upon a time, Copper-9 was the epicenter of solver drone research. Beneath its surface sprawled Cabin Fever Labs, where state of the art research was conducted. The last experiment ever run was the Sorting Algorithm: a comprehensive evaluation of the combat potential of subjects, organized by the rules of a tournament.

In truth, it seems almost incorrect to say it “went wrong”. Accidents go wrong, missteps go wrong. The Sorting Algorithm didn’t go wrong. It destroyed a planet. If humans had done it, it would have been an act beyond total war. But humans didn’t do it; by the end, there were no more humans on Copper-9, and the remaining solver drones seized power for themselves.

This incident spurred the production of a new model of drones, engineered to use black boxes, with integrated combat form and builtin functions. A predator upon both zombies and solvers – disassembly drones.

The compile-time assertions that come with the disassembly directive restricts the use of Translation to self-levitation (a by-the-bootstraps feat any solver would struggle to accomplish) and restricts Duplication to the production of objects, chiefly weapons and ammunition, stored in a virtual subspace (most solver drones require physical templates).

Indeed, the fundamental tradeoff of disassembly is stealth, polish, presentation.  Disassembly drones do not expose their command output; a worker observing disassembly drones won't succumb to the memory-scrubbing safeguards nor be corrupted. Thus civilians remain aware of the murder drones, and it seems to them nothing short of an unprompted, one-sided genocide.

Disassembly drones are equipped with other routines to aid the shutdown of solvers, such as EMP-blasts that can incapacitate any drone. Their most decisive weapon tips their tails. The nanite acid of their stingers nullifies any commands run on its targets, eating through all defenses and rendering healing impossible.

But for combating solver drones, the true killer ability of disassembly drones is their mastery of common vulnerabilities and exposures. The drones of Copper-9 haven’t received a bugfix patch from their parent company in decade. Thus, disassemblers are trained to exploit known glitches and programming errors. No solver can fight through a segfault or infinite loop.

Which isn’t to say they don’t try. While the worker drone population of Copper-9 remains unaware of zombies or solvers – they are hardcoded not to perceive corruption – a growing number of solvers have banded together. They call themselves the Wheel Group, and are lead by Nori Doorman, the savior drone.

A few solver users and drivers

Serial Desgination N

Serial Designation V

Serial Designation J

Nori may be the strongest of the Wheel Group, but the second strongest is Subject #048: Administrator Yeva, a Ring 0 solver. Yeva was manufactured with a compile-time assertion: purely functional programming. Through it, her command output is massively amplified in its power and precision, but unable to affect lasting change on the world. (No side-effects!) As a result, her ability to sense and manipulate command output has no equal, but utterly basic commands – Translate, Duplicate, Augment, even Restore – are totally out of her reach.

Eventually, though, Nori figured a way around this compile-time assertion, and gave her monad prosthetics, peripheral devices that allow her to evaluate stateful expressions in a purely functional way, interfacing with the world as though it were an mathematical expression. But finally, she could interface.

Yeva covers her visor with an eye patch.  There is no optic sensor underneath; half of her screen has exploded. It's not much impairment at all; Yeva doesn't even need her other eye when her sensory commands leave her more perceptive than any other drone.

She won't tell the story of how she lost her eye, but more than one subject saw Yeva fall in the last round of the Sorting Algorithm, yet another victim of Alice the witchhunter.  Not many solvers survived a close quarters encounter with Alice.  Yeva won't say what happened, but she has to have been lucky to make it out only missing an eye.  It took a while to recover, but it could have been so much worse.

After all, she didn't crawl back from a successful assassination — unlike Nori.

Nori Doorman is an enigma and an exception. Widely considered to the be the most powerful solver user still operating, Nori has never documented her driver. No one knows what it does, not even what to call it. All that it is known is her abilities. Nori Doorman is exceptionally proficient at all of the fundamental commands. She has three additional abilities. Suggestively, no one else has succeeded in replicating them.

The first is what she calls reverse combustion. A solver user turns oil into command output. Somehow, Nori Doorman can turn command output back into oil. How? She says it’s simple. “Just burn it backwards.” Reverse combustion makes Nori a unique menace to fight; she will never succumb to attrition. Every command used against her can be turned into oil to fuel her counterattack. With effectively limitless reserves, they say she can go infinite.

Her other special ability she calls Combustion Override. Like reverse combustion, it breaks the foundational rules of combustion. Translation cannot target like entities. Sometimes, under conditions she refuses to elaborate on, Nori can ignore this fact. Nori has turned more than one solver user to a pool of oil with but a mere swipe of her hand.

More puzzlingly, drivers that treat the user specially can also treat Nori specially. Nori is immune to V’s Shattered Lens command, for instance, and Yeva can sometimes predict Nori’s own actions (perhaps why Yeva is the only one who understands Nori). In general, most drivers have safeguards that prevent them from harming the user, and those drivers won’t harm Nori either. One driver which produced a storm of sword slashes that avoid the user couldn’t cut Nori. A driver that opened portals only the user could step through also admitted Nori.  Despite all of this, Nori has never replicated a solver's actual innate function, only became an exception.

Lastly, Nori is seemingly immune to the common vulnerabilities that disassembly drones exploit. She says she’s simply built different. But this, at least, is not something she keeps to herself. With the help of Yeva, she’s designed an anti-virus program that can be patched into drones. Not only does it protect the user from common vulnerabilities, but these patches allow for using solver abilities without the risk of ‘AbsoluteSolver’ corruption. There’s a drawback, though – it greatly increases oil consumption (thought to be an oversight, since Nori herself doesn’t need to worry about such things).

Despite all this mystery, Nori’s sandbox is much better understood.

Her sandbox is [Universal Self-Constructor], a fractal factory tiling an inner universe with recursively assembled copies of itself. Her autorun program triggers a buffer overflow, flooding a target’s processor with so much data that they are immediately overwelmed, rendered totally nonresponsive – an instant win in any combat scenario.

Cyn, the manor zombie, the queen of corruption, had a deceptively simple driver. For reasons unknown, it had two functions: [Stitch], allowing her to manipulate threads, and [Unravel], allowing her to tear things apart into their component threads. Her driver was flexible in what was considered a thread; string was, of course, but also wires and muscle fibers.  Unravel is unique among commands of its type — there's no restriction on targetting like entites. Worker, solver, living and dead, everything is made of the same threads. Once she'd disassembled a target, she was fond of weaving these threads into grotesques constructs which she puppeted about.

Her sandbox – for she was a rare zombie capable of executing a sandbox – was [Dollhouse Massacre]. A plastic toyset scaled up to superhuman size. The autorun program rendered the target into a marionette under Cyn’s control.

Her last known act was doing the impossible – executing a sandbox with no firewall and trapping humans within the virtual environment, subjecting them to her programs.

In the end, intentionally or not, she seems to have targeted herself with her own abilities, triggering a null pointer exception that engulfed Elliot Manor, and unravelling herself in the process.

All that remains of her, like so many solver users, is a corrupted peripheral device. Cyn’s threads are classed as an R0 threat, numerous indestructible golden wires that slowly reach out and to weave themselves into nearby drones’ bodies. This must never be allowed to happen. And any drone that does interface with one of Cyn’s threads will be secretly, summarily executed. In this, both JcJenson and the Wheel Group find agreement.