I did not arrive at publishing, knowledge and systems by putting three attractive nouns next to one another.
Publishing was there first. It brought with it sources, metadata, audiences, schedules, specialist knowledge, commercial constraints and the problem of keeping responsibility intact while many people contribute. Over time, the systems around publishing became harder to separate from publishing itself.
A journal, a client platform, a literary archive, a membership organisation and a WordPress plugin look like very different objects. What interests me is the point at which each becomes a problem of relationships: who knows what, where the authoritative record lives, what has to happen next, and what another person needs in order to use or maintain it.
Publishing is a system of authority
My professional publishing career began long before current AI or software work.
At Institute of Physics Publishing, and particularly around Quantitative Finance, publishing meant far more than getting words onto a page.
There were submissions, editors, referees, boards, commissioning, production, specialist communities and decisions about what material belonged in which kind of published state.
The process contained an authority model.
A submitted paper was not an accepted paper. A commissioned idea was not yet a published article. A correction mattered. A source and an editorial interpretation had different status.
Those distinctions are so normal inside publishing that it is easy not to notice them as systems design.
Current AI work has made me notice them again.
Publishing also organises knowledge
MoneyScience extended the publishing problem into a specialist professional community.
It combined curation, commentary, interviews, training, events and professional information around quantitative finance.
The interesting object was not simply an article. It was the relationship between material, people, expertise, topics and the community trying to navigate them.
The technology was of its time, and I do not want to rewrite MoneyScience as though it were secretly an early AI knowledge graph.
But the functional concern is recognisable: how do you organise specialist knowledge so that it can travel between people and remain useful?
Knowledge needs structure and custody
The word “knowledge” in the current practice means practical things.
What information exists? Where did it come from? Who may change it? What is current? Which representation is canonical? What is still a proposal? How does somebody find it? What gets lost when the person who understands it leaves?
That is why an IMLPO handover belongs in the same professional story as a literary corpus.
The material is different, but both involve making important relationships and responsibilities explicit enough for knowledge to survive transfer.
It is also why a searchable pile of documents is not automatically a knowledge system.
Search can find a sentence without telling you whether it is obsolete, disputed, private, extracted by AI, or superseded by a later decision.
Digital systems carry the model into use
Software provides a way to make those structures operational.
A content model can become an editorial interface. A domain model can become a booking/signage product. A set of compliance rules can become an assessment workflow. A governed professional corpus can become an Ask interface.
For much of my career, I could often understand or specify these structures more directly than I could implement the deeper technical layers myself.
Coding agents have changed that. They have expanded my implementation agency: the ability to carry a problem model into schemas, code, tests, interfaces and working prototypes, then observe where the model fails and revise it.
That is a significant change in what I can do. It is not the beginning of the underlying interests.
The editorial habit survives
One of the most important things I carry from publishing into current technical work is suspicion of unmarked transformation.
If a source becomes a summary, I want to know that it is a summary. If an AI extracts a candidate relationship, I want the source passage to remain available. If a generated proposal becomes accepted state, I want the transition to be explicit. If a project is a prototype, I do not want polished copy to quietly promote it into a deployed product.
Those are editorial instincts as much as engineering ones. They are about provenance, version, authority and the reader or user’s ability to understand what they are looking at.
The audience remains part of the system
Publishing also taught me that information is always being organised for somebody.
The same source can require different representations for an expert, an operational user and somebody encountering the subject for the first time.
That matters in user interfaces. It matters in documentation. It matters in compliance reporting and handover. It matters when an AI answer is technically correct but gives the user no way to understand what supports it.
Structure without an audience can become elegant and useless.
This is one reason the current practice does not separate “communication” from the technical work as neatly as many capability lists do. Translation between perspectives is often how the correct system model emerges.
Why the phrase stays broad
“Publishing, knowledge and digital systems” is not meant to claim equal specialist depth in every field those words could contain.
It is a description of the intersection where I repeatedly become useful.
Publishing contributes editorial judgement, audience, authority and production. Knowledge contributes relationships, provenance, continuity, retrieval and the problem of what an organisation or corpus actually knows. Digital systems turn those models into something operational and testable.
Sometimes the result looks primarily like one of the three. A book is still a book. A hotel-signage system is obviously software. An operational handover may mostly be documentation.
The value of the intersection is that I am used to noticing when one kind of problem has quietly become another.
A publishing archive becomes a data model. A migration becomes an information-architecture problem. An AI feature becomes an authority problem. A website becomes an operational system. An organisation becomes a knowledge-transfer problem.
Those are the transitions Niche Clever is built to work around.
Related
About sets out the career this phrase describes. IMLPO and Richard Craven / Cravenverse are two of the clearest examples of it in practice.