{
  "$type": "site.standard.document",
  "canonicalUrl": "https://serpentsquiggles.neocities.org//posts/fiction/corrupt-combustion/mom-lore",
  "path": "/posts/fiction/corrupt-combustion/mom-lore",
  "publishedAt": "2025-01-14T00:00:00.000Z",
  "site": "at://did:plc:ivoe7cntxuy6at7uzmxzs2ft/site.standard.publication/3mfk6cpprzt2t",
  "textContent": "[As you may have noticed][prev], I've been thinking about Corrupt\nCombustion again.  In general, I like keeping cards close to my chest\n--- certainly, I'd like for there to be big reveals if I ever write\nthis story For Real --- but I've been wondering what the utility of\nthat really is, when the project is this disorganized, and the people\nwho read it are as much brainstorming partners as they are proper\nreaders.\n\n[prev]: repair-slither.html\n\nThe story itself isn't even plotted out in detail enough for me to say\nfor certain where or why some of the things I'm keeping secret will\nactually be revealed.  Like, am I really spoiling the surprise if I\nexplain what's really up with Beau, or what Nori's driver really is?\nIn fact, I don't even remember why I was keeping that one secret to\nbegin with.\n\nWhen I expressed this [elsewhere][tumblr], I received this response:\n\n[tumblr]: https://www.tumblr.com/snugglesquiggle/772610823318388736\n\n> #Let's go!  \n> #Also gonna shoot my shot for guessing Nori's Driver b4\n> it gets revealed  \n> #Current top contender in my brain is something\n> akin to Mahito's Idle Transfiguration  \n> #(but it works on code bc they're robots)  \n> #With the knowledge the current powerset is all bc of Nori inverting\n> her function  \n> #Maybe it normally only can affect her  \n> #But inverted it can affect others  \n> #Looking forward to seeing all the cool stuff you've got cooked up.\n\nThis guess was remarkably close.  In fact, the original concept for\nher driver --- which informs how some earlier material was written ---\nis almost exactly what you describe.  It's changed significantly as\nI've tried to refine what that actually means and how it might be\nbalanced, so a part of me wonders if earlier scenes are still\nconsistent with how my interpretation of her driver has evolved.\n\n(I.e. last year, I might've said her driver was corruption itself, and\nits inverse was 'hotfix', and her apparent powerset is downstream of\nher ability to 'patch' herself like that.  She can no longer really do\nthis.)\n\nWhat can she do?  Let's discuss.  Don't mind that scroll bar.\n\n- - -\n\nTo understand Nori's driver, we first need to refresh ourselves on the\nlow level details of how corruption is supposed to work.\n\nRecall that in CC, computers are cursed.  Certain patterns of\ncomputation innately produce glitches.  Stuff like 2+2=4 or\n2+47=30 are well-behaved, but if these formula get sufficiently\ncomplicated, typing them into a calculator in this world will cause it\nto spit out the wrong answer, damage the circuits a little,\npotentially write random data to unpredictable locations.\n\nThat last bit is the most important.  The data produced by these\nglitches is called corruption: it's where the cursed-ness is stored.\nCode that reads this glitched data as input will have a dramatically\nincreased chance of causing further glitches; the errors cascade.\n\nRemember also that the fundamental formula of corrupt combustion is\nthat oil + corruption = command execution.  By transmitting ---\n\"venting\" --- corrupt data through the cables that connect to the\ndrone's oil reserves, the electricity can spark combustion, and like\nthat, solver commands are executed.\n\nNow, it's still a little bit more complicated than that.  You might\nthink that, well if these glitches are innate to certain computation,\nthen it should be entirely possible to write a program that\ndeliberately executes glitched routine on-demand to create exactly the\namount of corruption you need.\n\nBut corruption isn't so well behaved.  The corrupt data generated by a\nglitch won't always be stored in the same place --- it can overwrite\nimportant variables and configuration.  It can also unpredictably\nalter the flow of the command line.  For example, you might try to run\na small glitch ten times in a loop --- except four times through, the\nprogram glitches its own instructions to gotos out of the controlled\nloop and into a totally different part of the code, wreaking havoc.\n\nAll of this is to say, to allow corrupt combustion means playing with\nchaos; solvers obtain their power from glitches and errors, but this\nisn't cosmetic or flavor.  They are casting from SAN.\n\nThis, incidentally, is the difference between a zombie and a solver.\nSolvers have programming, cognition, a sense of self that's eroded by\ncorruption.  Zombies are corruption.\n\nWhen a solver cascades enough errors, they glitch out, potentially\ncrashing, and have to perform data recovery before they are operable\nagain.  You could disable a solver just by injecting them with more\ncorruption than they can handle.  Try that with a zombie, and the\nadded corruption only strengthens them.  Zombie processes are\nsentient patterns of corruption.\n\nAgain, the formula of corrupt combustion is oil + corruption = command\nexecution.  So another way to understand the difference between a\nsolver and a zombie is where the bottleneck lies; a solver is oil-rich\nand corruption-poor,[^fail] while a zombie is replete with corruption and\nhungry for oil.[^styx]\n\n[^fail]: Drones have failsafe routines that instinctively take hold\n    whenever they reach a critical threshold of corruption.  there's\n    something that speaks to me about the image of a solver\n    instictively venting an excess of corruption via combustion, oil\n    burning away --- overheating themselves just to stay sane.\n\n[^styx]: One reader saw this, and concluded that this would make\n    zombies walking batteries for powerful solvers.\n    \n    This doesn't work.  A solver drone's relationship to corruption is\n    defined more by how much risk they feel comfortable taking, rather\n    than how much corruption they quantitatively have access to.\n    \n    Solvers are not corruption-poor because corruption itself is hard\n    to come by --- just deref NULL[Now, it's not literally an easy as\n    segfaulting.  How much corruption a glitch generates depends matter\n    of entropy --- predictably triggering a glitch has diminishing\n    returns --- and its relationship to the surrounding program.\n    Just like a ball has more energy atop a hill, a glitch can generate\n    more corruption in a complex system --- if it breaks a pattern.  \n    And of course, since corruption can do work, creating it costs\n    energy.  \n    All of this is to say, even if you had zero self preservation, you\n    wouldn't be able to instantly summon a bunch of corruption.  \n    Still, slurping zombies just doesn't really solve your problems.\n    ]{.note} --- what's scarce is controlled\n    corruption.\n\nSo let's talk about the actual commmands solvers run.  The most basic\nattack available to a solver is to just output a stream of\nunstructured data that interrupts other commands.\n\nAgainst ordinary digital targets, this feels as if you jammed noise or\nstatic into their inputs, but there's no anomalous corruption induced.\n\nAgainst hard-drives and circuits laden with corrupt data, it purges\nthat corruption; this is how solvers are able to defeat zombies.^[And\nit's why solvers are all but required to fight zombies --- workers\ntend to just become host to the corruption.  Still, if the zombie\nprocess is starved of oil and electricity for long enough, it will\nslowly fade.]\n\nFinally, if there's a corrupt command running on the target, that\ncommand ablatively absorbs some of the interruption and errors out,\nleaving the target to experience a reduced or no effect.\n\nFor this reason, it's common practice to layer commands, making them\nredundant, so that if some of them error out, the rest can complete\nthe operation.[See also: the concept of radiation hardening in\nprogramming.]{.note}\n\nImagine solver A levitates a roachbot with 3kb of redundant\ntranslation commands.  Solver B outputs 5kb raw interruption into it.\n3kb gets absorbed by the the levitation command, canceling it, and\nthen the roachbot takes 2kb of interruption to central processing and\ncurls up unresponsive.\n\nA tactic that advanced solvers can employ is traps, commands that\ntrigger in response to another command's interruption.  Like a\ncounterattack or parry --- think try/catch exception blocks --- but\nthe added complexity makes it harder to master, easy to mess up.  You\ncan also send alternate interrupt signals that might confuse or bypass\nsimple try/catch code --- at the highest level, there's an arms race\nbetween ever more complicated defenses and ever trickier ways to crack\nthose defenses.\n\nBut most solvers stick to redundant, ablative code, and simple\ninterrupts.\n\n- - -\n\nAnd this is where Nori is different.\n\nNori's driver is [Overwrite]{.spell}.  When she interacts with another\nsolver's command output, instead of causing their command to abort, it\ngets overwritten with her own commands by corrupting the thread of\nexecution.  The overwritten commands then recursively inherit the\neffect of her driver.\n\nLet's go back to that toy example.  Imagine Nori tries to attack the\nthe roachbot held with 3kb of levitation.  She outputs 5kb of driver\ncommands, overwriting the 3kb levitation to yield 8kb (!) output.\n\n...which coalesces into a weak ring 4 zombie process and the possessed\nroachbot skitters away.  Oops.\n\nThis is because Nori cannot interrupt the same way regular solvers do\n--- her overwritten commands only create more corruption.\n\nIn Cabin Fever Labs, the technicians considered Nori a failure or a\ncuriosity.  Remember, the purpose of solvers is to purge zombies, and\nsure, for certain powerful zombies, Nori could negate their special\ncommands --- at the expense of empowering the zombie overall, because\nagain, they're made of corruption.[If nothing else, Nori was useful\nfor ensuring the technicians had no shortage of zombies for testing\nother solvers against.]{.note}\n\nImagine being unable to fulfill your only purpose; the unique essence\nof your soul being infectious wildfire that creates monsters and\nmadmen.\n\nA similar principle holds against solvers, even --- against weak\nsolvers, the sudden influx of corruption might overwhelm them and\nprompt a crash, but remember that so",
  "title": "Top Secret Mom Lore"
}