Secret communication protocols (and file formats) and their frequent changes is a famous technique heavily used by Microsoft (and some other proprietary software vendors) to lock competition out of their markets and to lock users into their products. OSHS uses a very similar technique called pseudosecret protocols to lock attackers out of the system.
The "pseudosecret" in the name means that the protocols are not made secret to the owner of the system once this technique is deployed. They are made secret to only the unauthorized intruders trying to break in.
In OSHS processes communicate by sending messages to each other. Protocols are used to describe the content of this communication. These protocols specify (among other things) how the data in these messages is expressed (in terms like which byte value(s) are used to request a particular service or which bit needs to be flipped to indicate some special meaning of the data format or the like) and laid out and sometimes which handles to send these messages to.
When one of the processes is an OSHS system server, its protocol is a part of the OSHS interface specification. These OSHS interface protocols are described in source code files placed at some standard space in the filesystem so the compiler can conveniently reach them. In these files the protocol is described using things like structures and constants declared in them. The source code of the application or the libraries used by the application (in vast majority of cases the system library) instructs the compiler to load the needed protocol description headers and then uses the structures and constants declared in these protocol description to construct the messages to be passed to the server and to understand the replies from the server.
Vast majority of exploits (especially the ones that are intended to work automatically) wanting to hijack a service on a remote host for their malicious purposes must bypass all the system libraries and talk directly to the kernel in order to work, because these exploits are already bypassing the normal loading mechanisms of the operating system running on the target host that take care to properly link the loaded programs with the shared libraries they use. This means that when communicating with the system services the exploit must handle all the needed message assembling and reply disassembling itself and without the help of any library (unless the attacker finds a way to "recruit" a library routinne to do that which is way too complicated to most of them, especially when features like randomized stack frames are employed). This is like connecting directly to the phone wires and using the raw phone wire protocols to make a phone call instead of utilizing a phone.
So when the software that uses the OSHS interface protocols is programmed carefully enough, it is possible to change things like the order of the fields in the structures (and in some cases even the size of the structure itself by padding it with unused fields) and the values of the constants and then recompile and restart all the system software and still having everything working well. The only thing that ceases to work is the exploit the attacker is trying to sneak into our system with. By changing the meaning of the raw messages the exploit is locked out like the Microsoft competition is locked out of Microsoft market when Microsoft changes an "internal network protocol".
One of the properties of this technique is that binary only proprietary software usually ceases to work when this technique is deployed and there is no fix possible for that due to the ways modern optimizing compilers treat integer constants thus rendering it utterly incompatible with any binary only software. The need for compatibility with proprietary software is why developers of the traditional operating systems (including the free ones such as GNU/Linux) never ever consider implementing it. The OSHS operating system has no such need and so it is not hindered by it.
This property also means that distributed precompiled binaries for software free as speech will also not work well and (usually) the user will be required to compile the program from source on the target machine. However OSHS uses advanced software integration language which allows better compilers, better utilization of them and less hassles for their users so this is not such a concern.