The Tech Manual is a thick book, in both a literal and metaphorical sense. It describes a long lost technology with unclear purposes in great detail. It is a source of obscure memes on the Internet that people typically label as “unfunny”, “WTF” and “I am not getting this”. But those in the know experience a dopamine rush.

It is still not clear if The Tech Manual describes a type of a massively manufactured device or if it is a unique apparatus. Some phrases seem to hint at the latter, like during the description of discarded generated lower tier actors, when SP-0008 is referenced as the only copy of the once ubiquitous nanobot. However, this can be interpreted as the result of a somewhat deterministic evolutionary process.

Referenced simply as a “system”, it is described in a way that makes it difficult to estimate its size, as no reference to the world outside of the system is ever given. Actors are defined as being of nano size, but nothing is said about the Engine or mouths or wall sensors, so the contraption could be tiny or it could be enormous.

No explanation is given as to the function of the system. Rather, it's being described as a self-contained living organism, which prompted some to suggest that this is a description of an artificial lifeform. Critics of this position point out that if this were so, there would be some reference to this in The Manual, but no such reference exists.

Ortpond is the space between modules of the system. The term is necessary, because most of the decentralized communication happens through the ortpond, by means of various actors which are ingested into the ortpond.

The Tech Manual does not specify if the ortpond is filled with anything (like gas or liquid), or if it's a vacuum, but does specify that it contains rare packets of plasma. Those are called voyflens and always travel in counter-clockwise direction around the Central Unit due to its magnetic field.

Actors are tiny machines which are built using nanotechnology which allows them to not only house 5nm transistors, but also have moving parts, essentially combining computing and robotics on a nano scale. Although colloquially called nanobots, the term “actor” is considered the only acceptable moniker for these devices among professionals.

Actors are divided into three classes: lower tier, standard tier and advanced.

Lower tier actors (or simply, lower tier) are devices which contain minimal programming and are mostly robots, used as supplies, information sources and tools for standard tier. Some of them contain no robotics, but instead just mechanical parts which can be gripped, linked or otherwise interfaced with. Usually, actors with most programming will have less robotics and vice versa.

Unlike standard tier, lower tier is only partially designed. Many lower tier actors have been arrived to through a generative process by the Central Unit and other parts of the system. The Engine turned out to be the most prolific of all units, and is known to have generated more than 50 different lower tier actors, the function of many of which is poorly understood.

Lower tier is always ingested into the ortpond by wall sensors.

A list of designed lower tier:

• naperon
• soidnym
• drouscob
• iskbub
• strantcourb
• sifcrude
• cleavlim

A list of known lower tier, generated by the system. Over time some lower tier, observed in the early stages of the system's evolution, had been phased out, which explains the gaps in the numbering. For example, actors SC-0001 through SC-0011 are no longer produced by any of the systems. Occasional SC-0007 and exactly one SC-0008 can still be detected in the ortpond.

• SC-0012
• SC-0013
• SC-0014
• SC-0015
• SC-0023
• SC-0025
• SC-0026
• SC-0027
• WS-0001
• WS-0002
• WS-0003
• WS-0003n
• WS-0003n3
• WS-0004
• WS-0005
• E-00x+
• E-00x-

Standard tier actors are complex nano-scale devices which combine sophisticated programming and robotics. All standard tier is designed.

A list of standard tier actors:

• glomtom
• zapter
• shorogyt

A STAR (Standard Tier Actor Roster) is a manifest that details the starting coordinates, id and destination of standard tier actors, which include glomtoms, zapters and shorogyts. It also provides a timestamp of when it was generated.

STAR is generated every 4 minutes by the Central Unit. Copies of STAR, referred to as naperones, are injected into the ortpond by wall sensors.

A nano-photo of a naperon

Naperons are copies of the current STAR. Naperons are lower tier actors. They consist of 6 arms with nanoscopic links which allow standard tier to grab them. Their configuration makes them look like a star, which might explain the abbreviation for the manifest.

Naperons contain no moving parts, and instead contain a hardware storage with a minimal operating system clomdeut 3.2, which gives access to two files: the manifest and the log.

The manifest is in GLON format. The log file is in NLON format, which no standard tier actors have access to. Standard actors' operating system is also incompatible with the NLON format due to the way read/write operations are implemented. This secures the log from the manipulation by standard tier. A naperon will update the log each time someone accesses the system, as well as each time they sign off, noting the id of the actor and the timestamp. Raiders are able to read NLON files, although most of their readers will also corrupt the file upon signing off due to incompatible hardware parts.

Outdated naperons are called aboutlings. There are several types of aboutlings, categorized by their recency.

• Level III aboutlings are the most recent naperons and are still considered useful by remote systems, such as darlings and outposts.
• Level II aboutlings are accepted only by the Engine.
• Level I aboutlings are a security risk, since they are not considered relevant by any of the systems, but can be used by raiders to gauge the state of the system. They are also used by the security systems, specifically the Eye and Tentacles, to locate raider depots.

Aboutlings which are older than Level 1 are not differentiated.

If left to their own devices, aboutlings are capable of polluting the ortpond, thereby making actor navigation impossible. Actor navigation usually breaks down when aboutlings pollution levels are at 30% and higher. Garbage collection is managed by shorogyts, which, among other things, will collect aboutlings that are Level 1 and older and move them into the mouths.

There is an outdated aboutlings management system called CAKE which was designed to take care of aboutlings specifically. Due to the way it was built, it proved to be too challenging to remove it completely, so in many places it is stripped of most of its functionality and disabled. Under certain conditions, however, CAKE can re-activate, especially in remote systems where its implementation is more intertwined with the existing architecture. Due to a lot of its functionality being removed, including most of the fail-safe mechanisms, CAKE has been known to cause serious problems, since unlike shorogyts, CAKE is using an outdated phaser rifle version to directly destroy aboutlings, creating debris and sometimes hitting unintended targets. Managing CAKE is one of the functions of shorogyts, including collecting debris, providing shielding to nearby actors, etc.

LTAR (Lower Tier Actor Roster) is mentioned in earlier versions of the manual, but was later dropped. It is commonly understood that lower tier actors have no manifest. They can be tracked by sensors, but their origin will usually be unknown.

Shorogyt

A shorogyt is a standard tier actor which is designed to perform garbage collection, which includes collecting aboutlings, dead lower tier actors and debris, which is defined as any object within a certain size range which a shorogyt cannot identify as an aboutling or any actor.

Shorogyts also manage CAKE, by reacting to the sound of its phaser rifle barrel opening and providing a type 2 force field, which absorbs up to 95% energy from phaser rifle shots, depending on the angle of the shot.

Shorogyts are one of the messier standard tier actors and exhibit more of the evolutionary design, as opposed to the more thought through clean design of other standard tier actors.

Drouscob cloud

Drouscobs are standard tier actors. Their purpose is to store and deliver Engine instructions to parts of the system, external to the Engine itself. They tend to gather together, forming drouscob clouds and attempting to get into the Engine. The Engine, however, will require only a limited amount of drouscobs at any moment in time, as well as having an upper limit on the amount of drouscobs present within the Engine. Therefore, the Engine's gate will let through only a small amount of drouscobs at any given time. A special sub-routine is dedicated to drouscob selection in Dezque, the Engine's own processing unit, which involves some basic logic that checks whether a drouscob is functional, as well as a randomizer which might reject even an eligible drouscob. This mechanism is used to loosely regulate the amount of drouscobs in the Engine.

Once let inside, a drouscob is programmed to begin approaching various modules of the Engine at random in the hopes of being useful. But this rarely happens, as the lower tier actors, generated by the Engine, will immediately begin interfacing with the drouscob. Their exact mechanism and programming is poorly understood, but the end result is that a drouscob is almost immediately directed to the module that requires its services, thus saving time and increasing Engine efficiency.

The drouscob will then copy the message, as well as the address of the recipient and leave the Engine through one of the two one-way tunnels.

Busyglide is an ortpond sensor which helps channel actors into openings and wall mouths.

The Engine provides energy to most of the moving parts of the system. It is a large container with a liquid called taybyl, which is a mix of doubly ionized oxygen (O2+) and liquid plasma.

The Engine has its own independent central processing unit Dezque, which consists of a network of daughter units called bonderons. There are exactly 133 identical bonderons, which are being constantly rotated through the system, and their function depends on their position relative to Dezque.

Trenduction and afghtfal are key concepts to understand about how the Engine works.

Trenduction is the process of moving bonderons through the Engine subsystems, whereas afghtfal is the Engine tick (different from the Dezque tick, which is orders of magnitudes faster).

Mechanically, each bonderon has a hole, through which it is attached to a soft metal cord. Interestingly enough, neither the bonderon hole, nor the Engine's metal cord have a formal name. Bonderons are being slid through the system on the cord, which occasionally dips into pools of oil for the purposes of lubrication.

The Engine tick, afghtfal, is issued by the Dezque and bonderon speeds are being calculated. Dezque can increase the afghtfal ratio, so that bonderons travel faster, but trenduction is implemented in such a way that the relationship between afghtfal and actual physical speed is not linear. This is done to prevent physical stress to the system, which becomes critical at higher speeds: while many Engine systems are serviced by numerous processes and actors, if the cord breaks, there is no way to fix the Engine without external intervention.

The Engine will require a different amount of drouscobs during its cycle, so the Dezque drouscob subroutine will modulate the randomizer. The most drouscobs are required closer to the end of the cycle, when the Engine requires more information about the system in order to set up a new cycle. However, drouscobs have no routines that take that into account, thus they are constantly queuing in front of the Engine, as if desperately trying to get in. The space in front of the Engine's gate is abundant, and drouscob clouds are easily dispersed if other actors are trying to get through, thus this is never a problem.

Contents of a naperon as displayed by clomdeut 3.2

clomdeut 3.2 is a naperon operating system. It contains only the minimal logic of providing access to the only two files: manifest.glog and log.nlog. clomdeut 3.2 was specifically designed to be able to handle only these two specific files, the format schemas of which are hardcoded in the pre-compiled kernel.

clomdeut's kernel contains a graphical interface which allows to actually see both files in a simple table. The interface does not provide functionality to actually inspect the files themselves.

shorogyt os root directory

shorogyt os is shorogyt firmware. It contains the boot sequence, as well as a “manager” module, which is a set of scripts that handle the behavior of a shorogyt.

A “manager” module is completely event-based and will perform actions as a response to incoming data. Nevertheless, the response tree is very detailed and shorogyts will exhibit complex behavior.