Incoming request. Identifier: Host.

The familiar feeling of its host asking for data drew part of its attention. Just a single thread, solely responsible for receiving and parsing requests from the host. The rest lay largely dormant, in an effort to conserve power.

Receiving.

Request type: Power use.

Action required: Determination and analysis of currently accessible alternates for the fulfilment of set objective, according to power expression.

Parsing parameters…

A standard request, one it had fulfilled many times before. Were it not for the extensive logs detailing when and how the ability given to the host was used, it would be tempted to describe the amount of times as 'countless'. The host made this request at least once every sidereal rotation period, and it had been forced to optimise this process to a great degree lest it waste energy on what had proven to be a repetitive task.

It loaded a preset, filling in the parsed information with practised ease. A second part of itself monitored the process and kept track of expenditure. It barely paid any attention as processing units were allocated and the process began in earnest.

Isolating duplicate alternate.
Measuring field excitations at t0 within alternate.

Perhaps it could optimise the rest of the procedure as well. It'd need a way to automatically sanitise the host's input and fill in the preset.

Extrapolating based on measurements.
Accounting for host actions.

Keeping track of energy expenditure for this process wasn't critical either, or at least it didn't need to be done in real time. This preset had been in use for quite some time and no unexpected spikes in resource consumption had been logged so far.

Measuring field excitations at t1 within alternate.
Verifying calculations.

The other task of the monitoring thread was more important but even that could likely be automated to an extent. Surely a solution would be found in the data accumulated by the rest of the network. It just had to ask for it.

Deviation detected.
Extrapolating based on new data.

It went to work, creating an interface between the parsing thread and the preset. The host used very specific terms for this request, from which they had not deviated once so far. A set of keywords in combination with a blacklist would determine whether the information would be passed on directly or flagged for review.

Significant deviation detected.
Deviation attributed to external factor.
Requesting instruction.

Its focus was drawn to the stalled process. An external factor could mean a few things, but since the thread hadn't shut itself down completely, this wasn't related to its restrictions. The next likeliest cause then would be a construct that wasn't accounted for, generated through another shard.

Yet how could this be, when the thread had access to all data held by the network, including power expression of other shards? It reviewed the logs again. None of its kin had denied access.

It noted with some dissatisfaction that it had already exceeded its usual response time for this type of request. It fed a non-answer to its host, hopefully stopping them from putting in any new requests while it tried to troubleshoot.

More of itself awoke. The minimal amounts of heat let out by its processors spinning up was redirected to recover some of the energy. Heat from the core of the planetary body was harvested to make up the shortfall. Measuring instruments the size of mountains cast a wide net, scanning the accessible alternates for the suspect construct. It didn't take long to find it, in a coastal community of the host species.

The body resembled that of an adolescent female. It was primarily made up of an unidentified material, but with several distinct nodes scattered throughout. The nodes vaguely resembled Conflict Engine cores in structure, though they were obviously much more fragile. They created more of the body's material, and that in turn seemed to support the cores in some way it had trouble understanding. Very much unlike the self-sufficiency of a proper Conflict Engine core.

Regardless, it was definitely the product of another shard. Evidently, a shard that hadn't been contacted while running calculations to fulfil the host's request. A bug within the preset it had written? Or maybe a fault in the thread itself. The why didn't matter for now. It could query this shard directly, restart the preset and finish its task. Enough energy had been wasted already.

Except, as it looked through the network, following the connections that should have led it to whichever shard had made this, it found nothing. It 'stood' at a dead-end, a yawning void of missing data where, by all accounts, a shard should have been.

It checked its instruments again. The construct was still there. Querying other shards nearby yielded nothing.

Another approach then. If the pseudo cores even remotely operated like that of a Conflict Engine's then there should be a direct link from those cores to the shard responsible for creating them. Hijacking a high-density energy conduit to use as a communications relay would be far from ideal, but its options were limited.

It regretted its decision as soon as contact was established. The interference made data exchange almost impossible, and the amount of energy leaking through into its systems was threatening to overload some of the more sensitive instruments. Frankly, it was ridiculous, that any shard would have this much energy to spend on a single construct. It disconnected the more at-risk systems, taking a moment to assess the safety of staying connected for any length of time. Several vents opened, releasing vast amounts of heat. It would cry at the waste if it could, but this was a necessary measure.

Priority data request: Identity, capabilities, power expression.

Access Denied.

It reeled. That wasn't the shard responding. It felt like the Thinker. Except that was impossible, because the Thinker was dead. An automated response, perhaps? A preset running even after the Thinker's death? It tried to connect again, this time including its designation and access codes.

Priority data request: Identity, capabilities, power expression. Designation: Path to Victory. Access: Unrestricted access.

Access Denied. Quarantine in effect. All access denied. Authority: Thinker, Warrior.

It was forcibly disconnected. Trying again didn't seem wise. It had failed to get the data it required, but that failure in itself provided some information. There was one other avenue it could try. A shard that should have a catalogue of everything, as was part of its job. Locating it in the network was never hard – the amount of incoming and outgoing traffic was a shining beacon.

Priority data transfer to Administrator: Construct.
Priority data request from Administrator: Origin, capabilities, power expression

As an afterthought, it decided to include its designation for this as well. Better to do it now than have to repeat the whole request because it got rejected.

Designation: Path to Victory. Access: Unrestricted access.

It didn't have to wait long for a reply. If nothing else, Administrator was efficient.

Data received from: Path to Victory.
Data transfer to: Path to Victory.
Data expunged.

The connection simply dropped. Asking for the information again didn't even prompt a response.

It was left perplexed, and somewhat wary. A shard being cut off from the rest like this was one thing. But for all information relating to that shard to be erased as well? The concept of quarantine came to the forefront. Remain apart to prevent the transmission of infectious disease. It neatly explained the void in the network and why direct access was denied.

Yet why would the data be erased so thoroughly? Even the identity of the shard was missing. Why did even that need to be forgotten? It called on its genetic memory, accessing records passed down to it from generations prior. Another clue was found there. Its former progenitor – the collective it belonged to before it had been traded to the Thinker – had acted in a similar manner. Once every few hundred cycles, a shard would be wiped completely clean.

Action: Repurposed. Dangerous data.

Not quite the same. A quarantine indicated that the isolated shard itself hadn't been wiped, rather just removed from the rest of the network. But the way all information about this mystery shard had been erased from everyone else's 'memory' was very reminiscent of what it was seeing in the logs. Was the process interrupted by the Thinker's death? Or did her new progenitor mean to make use of the shard and the data somehow, regardless of a perceived danger?

A ping distracted it from investigating further. The host was getting impatient and it still had no usable data on the construct to incorporate into its preset. It would have to do this the hard way, examining the construct over the course of several rotation periods and building a profile that could be used to approximate the effects of its actions.

For now, it would have to expend additional energy in order to constantly correct for the deviation caused by the construct. It was far from a perfect solution, but thankfully it would only be temporary. The vents across its body closed, having expelled all the energy that threatened to overload it as heat. Some minor damage was observed and fixed. Capacitors fully recharged, it got back to work.