This is the part of the Books section that is least about books themselves.
It is about everything that grows around them.
As my publishing work expanded, I found myself repeatedly building the same kinds of things: production systems, landing pages, translation tools, language protocols, reader resources, visual standards and small pieces of software that make books easier to create, distribute, understand and reuse.
Eventually those supporting tools became a layer of their own.
That is what Publishing Systems & Protocols contains.
ABVX OS
One of the core systems behind the publishing work is ABVX OS.
It is the internal operating layer I use to organise book production, track publication status, manage workflows and keep the growing catalogue understandable.
A book passes through many states before it becomes a finished publication.
There may be research, translation, editing, formatting, cover production, metadata preparation, landing pages, store listings, revisions and later new editions.
When only a few books exist, much of this can be managed manually.
As the catalogue grows, that stops working.
ABVX OS exists to turn publishing into a more structured production process rather than a collection of disconnected files, notes and reminders.
It is not a public publishing platform in the conventional sense.
It is infrastructure for running my own publishing system.
Pictiq as a protocol
Another important direction is Pictiq, my visual communication system.
Pictiq sits somewhere between language, interface and protocol.
The goal is not merely to create attractive icons.
A visual language requires rules.
It needs a controlled vocabulary, composition principles, conventions and ways to express relationships between concepts.
So before expanding the publishing work around Pictiq, I started by documenting the system itself.
The protocol provides a stable foundation for the language.
That matters because future books, websites, learning materials and software should not each invent their own version of Pictiq.
They should all refer back to the same underlying system.
The protocol therefore becomes part of the publishing infrastructure.
The books depend on the language.
The language depends on the protocol.
And the protocol needs its own documentation, tools and website.
Sitelen pona
The same problem appears with sitelen pona.
Sitelen pona is already widely used in the toki pona community, but there are different conventions, glyph sets and ways of representing some words and structures.
For casual writing, variation is part of the culture.
For publishing, consistency matters more.
If I produce several books, a translator, websites and digital tools using sitelen pona, I need to know that the same word will be represented consistently across all of them.
So I documented the particular sitelen pona conventions I use in my publishing work.
The intention is not to declare one universal version correct.
It is simply to make my own system stable and reproducible.
That protocol can then be used by books, websites, software and future production tools.
Emoji Pona
A similar experiment led to Emoji Pona.
The idea is to explore whether toki pona can be represented through a controlled emoji-based visual system.
Again, the interesting part is not simply replacing words with emoji.
A usable system requires rules.
Which symbols correspond to which concepts?
How should they be composed?
What happens when no obvious emoji exists?
How do we avoid the same symbol drifting into several incompatible meanings?
Once those decisions become repeatable, the result starts behaving less like decoration and more like a protocol.
That makes it useful not only for experimental books but also for digital interfaces, websites and translators.
Translation infrastructure
Toki pona publishing also led to the creation of a dedicated AI translation system.
The translator can take text from ordinary languages and convert it into toki pona, with output that can also be represented through sitelen pona or Emoji Pona.
It uses AI because translation into a language such as toki pona is not primarily a dictionary substitution problem.
The source meaning often has to be decomposed and reconstructed.
A sentence containing specialised terminology may need to be rewritten conceptually before it can exist in a minimalist language.
That makes translation itself part of the publishing research.
The same tool can support books, learning materials, websites and experimentation with language.
Websites that can change language systems
The language work also extends into web publishing.
I have created plugins and translation layers that allow sites to be presented in toki pona and, depending on the project, rendered through sitelen pona or Emoji Pona.
A similar approach is being developed around Pictiq.
This is useful because I do not want these languages to exist only inside static PDF files or printed books.
If a language is supposed to be usable, it should also work on contemporary digital surfaces.
Websites are part of that environment.
So the publishing system increasingly includes not only translated texts but also the infrastructure required to make entire digital experiences readable through those systems.
Landing pages as publishing infrastructure
Most of my major publishing lines also have their own dedicated landing sites.
These include series sites, free-reader resources, language projects and companion pages around individual publishing experiments.
I treat these sites as part of the publication itself.
A marketplace listing is designed primarily to sell a book.
A dedicated landing page can do much more.
It can explain why the project exists.
It can connect several books into a series.
It can provide free material.
It can document protocols.
It can host articles and background information.
It can give a reader somewhere to continue after finishing the book.
This is why I gradually stopped thinking of publishing websites as marketing pages and started thinking of them as companion infrastructure.
Protocols make experiments repeatable
A large part of my publishing work is experimental.
That creates a problem.
Experiments are easy to perform once.
They are much harder to repeat consistently.
If I translate one book into sitelen pona without documenting my choices, the next book may use different conventions.
If I create one visual-language book without a stable vocabulary, the next project may contradict it.
If every series site is built from scratch, each new launch becomes unnecessarily expensive and slow.
Protocols solve part of this problem.
They freeze enough decisions to make the next project easier.
A protocol does not mean the system can never change.
It means changes become explicit.
The old version can be understood.
The new version can be documented.
Books created at different moments can still be traced back to the rules that produced them.
That becomes increasingly important as the catalogue grows.
Publishing for humans and machines
There is another layer that is becoming more important: machine readability.
Books and publishing projects now exist in an environment where discovery is no longer mediated only by bookstores and search engines.
AI systems increasingly read websites, structured data, repositories and public documentation.
So part of the publishing infrastructure is also about making projects understandable to machines.
That includes clear metadata, structured landing pages, public protocols, content indexes and other ways of making a publishing project easier to discover and interpret by search engines, language models and AI agents.
For me, this is not separate from publishing.
It is becoming part of what publishing means.
Books generate systems
The important thing about all of these projects is that most of them were not invented in advance as standalone software products.
They appeared because a publishing problem required them.
A Toki Pona book required a consistent writing system.
That required a protocol.
Several translations required a translator.
Several series required reusable landing infrastructure.
A visual language required a handbook, a composer and a website.
A growing catalogue required an internal production system.
Each new book can therefore generate something beyond the book itself.
Sometimes that becomes another tool.
Sometimes a protocol.
Sometimes an open-source project.
Sometimes an entire language ecosystem.
That is why Publishing Systems & Protocols belongs on the Books page even though much of it also belongs in Systems.
It represents the technical layer that allows the publishing work to keep growing without becoming a collection of disconnected experiments.
The books are the visible output.
This section is about the machinery underneath them.