Actions

Work Header

Rating:
Archive Warning:
Fandom:
Additional Tags:
Language:
English
Stats:
Published:
2026-03-18
Completed:
2026-03-26
Words:
1,902
Chapters:
3/3
Comments:
5
Kudos:
39
Bookmarks:
21
Hits:
368

SecSysLang Reference

Summary:

This is a reference document for SecSysLang, my fanon conlang for SecUnits, SecSystems, HubSystems, etc. to use when talking to each other.
This also contains some amount of meta from the actual canon; SecSysLang assumes that all the SecUnits and SecSystems in canon actually use SecSysLang, and Murderbot just translates it into words for us.

Feel free to use/adapt/take inspiration from/modify etc. SecSysLang in your own fanworks!

Notes:

(See the end of the work for notes.)

Chapter Text

General notes on SecSysLang

Credit/Usage

Hi! I’m the author, Saaabriel. 

Shameless self-promo: 

 

If you want to use SecSysLang in your own fics, or you’re inspired to do something similar and use my fics/this document/whatever as a jumping point: go for it!! You’re welcome to link my AO3 in your fic or use the “inspired by work” feature on AO3, but you’re also welcome to just post your fic without crediting me. I am not the first person to come up with the concept of security codes/secunit conversation/etc, and I won’t be the last to come up with it independently! For tagging, the tags I use on AO3 for this stuff is “SecSysLang” for the language itself and “SecSysLang-Speaking Three” for the headcanon of Three being more comfortable speaking SecSysLang than in words and/or slipping into SecSysLang in various situations. 

 

On Writing with SecSysLang

SecSysLang is bots talking. They are not actually talking in words, they’re talking in data. For SecSysLang integration with canon, assume that Murderbot is translating everything it sends/receives into words in its logs. When writing, you can choose: 

  • Write everything in words: do as Murderbot does, and translate everything into normal-sounding sentences. Mention that you’re translating. Or don’t; Murderbot doesn’t always. 
  • Write everything in code: using this reference document, get as close to the “raw code” as you can. This is the formatting I use in There’s Two of Them because I want it to be incomprehensible to humans. (note, you might therefore have to take the Command messages a step further; I assume most of the command words are not actually in english words!)
  • Write in a weird hybrid format: In This Hostile Boarding Attempt… I used the SecSysLang formats but translated everything into words to try to convey the oddness of Three’s speech patterns without making parsing everything too difficult for readers. 

 

Worldbuilding / Components of a System

SecSysLang depends heavily on the structure of a company system. 

  • The overarching system is just "System." System includes everything: HubSys, SecSys, MedSys, Units, drones.
  • HubSys considers itself synonymous with "System". It is the entire system; it gives orders to its components to carry out tasks. For HubSys, "my unit" is equivalent to a human saying "my arm". 
    • HubSys is in charge of making decisions, giving orders, and doling out punishment. HubSys itself does not perform any tasks/do any carryout; its "limbs" do all the carryout.  
    • The overarching entity is called HubSys in company systems, but that's not necessarily the case. It might also be "Station System", "General System", "[Name of station] Central", something like that... or even an augmented human. 
  • SecSys is a fully digital system. It interfaces with independent entities: units, drones. Its job is to assist with security: handling processing power, supporting input sorting, monitor cameras, etc. Its job is largely to receive, process, and give data to/from HubSys and other security components. (Murderbot often befriends SecSystems so that SecSys will let Murderbot manipulate data, delay/cease messages to HubSys, and provide data to Murderbot. All the while, Murderbot convinces SecSys that this is a normal part of operation, and it has the authority to request this.)
    • SecSys, MedSys, gunships, drones, etc are bot components; they do not have the capability to parse anything that isn't already programmed into them. 
  • SecUnits (and CombatSecUnits) are construct components of the system. Unusually, this means that they can make complex decisions and parse new information. Therefore, they're used to process/understand new situations: unlike orders to SecSys, orders to SecUnits might include room to "analyze the situation and behave as appropriate". This also means that they are the only governed components of the system. 

 

Commands

HubSys -> Component command; Component -> HubSys acknowledge

Basic command message format: [Hail/attn][Identify Self][Identify Recipient][command]:[other]

Hail: only on session startup 

Attention: only when necessary

Identify: when necessary to distinguish between system components

Command: always

Other: when necessary

 

Command Message Components

Hail: 

To initiate communication, indicate the communication protocol for self and for recipient. [self][recipient]. It should be the same protocol; if it isn't, hailing is part of the negotiation for which protocol/protocol variant to use. 

To respond to a hail, re-indicate the protocol. [protocol]

  • System is the communication protocol for any security system. When an in-system component contacts an in-system component, a basic Hail is: System System.
  • For an in-system component contacting an out-of-system component, it would try to mirror the out-of-system's communication protocol. 
  • For out-of-system variants,
    • (Begin) Session
    • Hail
    • Salute
    • Nod 

Attention: 

  • other tags such as important, all
  • Can use Hail for “Listen To Me!”

Identifier (in-system): 

  • One unit: Unit
  • One of multiple units: Unit01 (specify)
  • HubSys: null (HubSys is the system; it does not need a specific identifier and never identifies itself.)
  • Component (MedSys component, SecSys component, drone): Component [specify]
  • Partition: n/a, Partition is invalid message[1][This only made the list because Perihelion tries it in Bot Sex Positivity.]
  • Foreign entity: there is no protocol for this

If a message is sent with only one identifier, it is ambiguous whether it's identifying self or recipient. Options:

  • In context, the system would Just Know
  • If one of the entities is HubSys, that's not the one being identified
  • adding [null] to the message string in the correct location: [null][unit01]acknowledge:I just wanna talk = anon says, hi unit01, I just wanna talk. Ominous!

Command: 

  • Query: Request information. Must be responded to, by default with an Acknowledge. 
  • Acknowledge: Closest analogue to “yes” in SecSysLang. Also, “Hi, I am here.” 
  • Go [location]: Go somewhere. If location null, functions as opposite “Freeze” command and/or can be used as “Get moving!!”
  • Retrieve [location]: object (Current location implied if location null)
  • StandDown: Freeze. Do not move. On its own, this does not override any other requirements; GovMod distance limiter will not take this into consideration.
  • Violence time!
    • Intervene [location]: General command; SecUnit uses internal priority to decide between defend/attack.
    • Protect [client/location]: Defend command; do not attack. If client/location null, assume internal priority.
    • GoTarget [identifier]: Attack command; do not defend. Identifier cannot be null.
  • Repair
  • Patrol [location]
  • Assist
  • Analyze
  • Admin [specify]:[client]: Toggle admin state for any subsystem. If client is null, new admin state just applies to HubSys; this can be used as “give inputs please so I don’t have to go find them.” Ex., Unit Admin [diagnostics]
  • Calibrate: Can do calibrate:sensors or something, or just calibrate and Unit will start doing maintenance

 

Example Command Messages

System system unit acknowledge

Full Hail from HubSys to SecUnit, single-unit protocol. (In canon, this is how 2.0 greets Three while hiding as a component of SecSys.)

[System system=Hail][Unit=IdentifyRecipient:SecUnit][Acknowledge=hi]

 

System unit acknowledge

Full response from SecUnit to HubSys.

[System=Hail][Unit=IdentifySelf:SecUnit][Acknowledge=hi]

 

Retrieve [hallwayCrew3]: cleaning supplies

[no hail/attn][no identifiers][Retrieve takes a bracketed Location]:[other specification (cleaning supplies)]

 

Acknowledge Analyze:Bulkhead[priority1] Patrol[priority2]

SecUnit confirming orders from HubSys, + stringing together multiple commands.

 

Messages

HubSys Sending: 

...To a SecUnit

  • Noting an infraction: [Identify Unit][message]
    • Ex: “Unit01 unauthorized message”
  • Bringing something to attention of Unit: [message]
    • Ex: “Anomalous reading. Repairs required.”
  • Sending data: just send it! Tag Codes optional.

...To a bot component of System

  • Do not send the bots messages they do not understand. Use commands and/or tag codes. 

 

Bot Component Sending: 

  • No bot component would initiate communication. 

 

SecUnit Sending:

...to a HubSys

  • n/a, fuck you, use exclusively the command format!

...to a bot component of System

  • Use command format, however, SecUnits do not override HubSys commands. 

...to another SecUnit

[SecUnit to SecUnit Communication (SecUnit to SecUnit Conversation)]

TAG CODES ONLY! Messages may include other data types (image, video, audio), but any other data format sent MUST be tagged with at least one tag code. Some data types will be very scrutinized by HubSys and/or have much more limitations on what tags they can have (logs, diagnostics).

When sending messages to just each other/HubSys, SecUnits will not include the human-readable part of tag codes to save on data/transmission speed. When sending messages that humans or non-SecSys systems can see, they will send the human-readable part.

 

 

Tag Codes (Security Codes)

Tag Codes can either be formatted with or without a human-readable portion. [7820 Review, Respond, Delete] versus [7820].

Types of tag codes: 

  • Security Codes: for general information. Designed for communication about status, clients, etc. Encompasses vast majority of codes. Format: [0000]
  • Action Codes: for making action plans very quickly. Designate specific actions, i.e., “shoot target!” “divert left!” etc. Action Codes are rarely useful outside of combat or combat planning. format: [A0000]
  • Status Codes: for information about the Unit. Default status code means “Systems green” -> [U0001]. Format: [U0000]

 

Message Formatting

  • [code]: that’s a full message. There isn’t any good way to form sentences/complex thoughts with tag codes; most messages are just single codes.
  • [[[code]subcode1]subcode2…]: nested codes are in order of override priority. Here, “code” is the lowest priority, and “subcode2” is the highest priority. To make alterations to a code, the alteration must be higher priority than the code: [[0909 incorrect use of code] 1000 override behavior correction] would cancel the punishment, but [[1000] 0909] would not.
    • Can also nest right-to-left [[subcode1[code]]; no difference in execution. 
  • [code][code][code…]: codes in order of execution.
  • [code:[subcode]]: some codes require subcodes.
  • [code:[[subcode]subcode][subcode]]: getting creative with it = getting more unreadable, but idgaf.

 

Numbered Security Codes

Note: Made these numbers up for Deity Help Us, There’s Two of Them before I ever made this reference document; I reserve the right to defanonize any part of that fic. 

  • 0000 null
  • 1000 override behavior correction (Normally unavailable to a SecUnit to send; used by HubSys to override GovMod in unusual situations.)
  • 1283 cleared cache (“a cache has been cleared”)
  • 0909 incorrect use of code (invokes punishment)
  • 5788 deliberate data alteration
  • 7820 Review, Respond, Delete
  • 8398:[purpose] store for future use (takes another code for Purpose)
  • 9373 spilled liquid in common area