The Problem
I inherited a substantial body of High Speed Guard documentation that engineers had written directly. They had organized the technical material well and captured valuable product knowledge. The documentation still read like engineering material, however. Administrators needed conceptual context, complete procedures, and clear paths through related procedures, all in Everfox's documentation voice.
The architecture problem changed again as the product evolved. What began as one product became a family of related operating-system, administrative-control, and guard-specific components with different owners and release schedules.
Why It Was Hard
I needed to preserve the engineers' technical accuracy and useful organization while turning their material into documentation that guided administrators from understanding through configuration and maintenance. That meant identifying missing concepts, turning implicit operational knowledge into procedures, and connecting those procedures into paths that users could follow.
The later product split made placement more difficult. Some information applied across the family, some belonged to one component, and writers needed to reference some information because another team owned it. Copying shared material everywhere would have been convenient for one release and expensive for every release after it. Independently shipped components would eventually carry different versions of guidance that should have remained consistent.
What I Figured Out
Documentation boundaries needed to follow product ownership and release boundaries. Shared content should remain shared only when its meaning, ownership, and cadence were genuinely shared.
What I Changed
I began with a complete audit and inventory of the engineer-written material. The audit showed where readers needed more conceptual framing, procedural detail, or connections between related tasks. I rewrote the material in Everfox's voice, developed the missing concepts and procedures, and organized clear paths through the work. I also defined placement rules for future information. A new topic should enter the architecture because of who needed it, which component owned it, and when it changed—not because a similar topic happened to be in a particular book.
When the product became a family, I revisited those rules. Shared, referenced, and product-specific content decisions followed technical ownership and release cadence. That allowed common information to remain common without pretending independently released components were one product.
The architecture also had to extend beyond my own product areas. Related products used the administrative server, so I coordinated with other writers and maintained release and version behavior across documentation that did not all ship together.
What Changed as a Result
The result was more than a cleaner set of books. The documentation architecture began to mirror the product architecture and release model, giving writers and users clearer signals about ownership, product boundaries, and where information belonged.
That structure reduced the risk that duplicated content would drift across products and made later decisions more systematic. When a component, owner, or release cadence changed, the team had an architectural rule to examine instead of having to rediscover the original rationale.
Evidence and Technical Detail
Making these decisions required a working understanding of the system: secure cross-domain systems, encryption and key management, secure file and stream transfer, Linux administration, networking, PKI and certificates, configuration, installation and deployment, troubleshooting, APIs and configuration formats, and air-gapped or restricted environments. The technical boundaries determined where the documentation boundaries belonged.