--- title: "Three labels for 113 technical posts, and what each one decides" canonical: https://dxdev.com/blog/plain-language-layer-discovered-missing/ datePublished: 2026-08-22 --- The work log says 74 companion posts written and gated. A few weeks earlier, none of those paths existed, and the request that should have asked for them only gave them one clause. We had asked Manus for more structured source material: git, Discord, Jira, the archive, session records. The plan was to improve the technical posts. It was also to build a second, plain-language version for business owners and early AI adopters. The request named both audiences, so it sounded complete. It wasn't. The data sources took most of the weight, and the plain-language reader got one clause near the end. We had turned the audience into a data problem, and that was the wrong model. ## What the Manus task got wrong We had sent Manus toward an inventory of source material when the missing object was a route through that inventory. More records could make a technical post more grounded. They could not tell a reader why unfamiliar words felt intimidating, or make the next useful question visible. The source request itself said that jargon was confusing and scary. It also asked for something straight, simple, practical, and visible. We had stated the need and then treated it as a secondary formatting concern. That is how the gap stayed hidden. A technical post can faithfully record a decision, a tool, or a failed check. A reader outside that vocabulary arrives with a different problem. They need enough context to know what changed, why it matters, and where they can stand before the technical detail starts moving. Replacing difficult words isn't enough. The missing work was to preserve the event while changing the entry point. ## A second artifact with its own job We stopped calling that work a nice extra and started calling it a communication layer. The technical post and the plain-language post do related jobs, but they aren't duplicates. One keeps the operational detail available. The other makes the event legible before that detail becomes a wall. That distinction turned the count from a content target into a coverage problem. The companion format gave that responsibility a place to live. It asks a technical draft to stay as technical as it was, and it makes a second artifact accountable for the first moment of understanding. That is a narrow job, but a necessary one. Without it, a reader has to translate the post before the post can help. ## Triage before translation Then the inventory became concrete. The work log records 113 unscored technical posts triaged into three outcomes: publish-ready, one-edit, and retire. We didn't need every technical post to get the same treatment. We needed the existing material to be honest about its state before it could carry a second route for a different reader. So the three labels stopped being back-office labels. They made the source material visible as a set of decisions. A post could be publish-ready. It could need one edit. It could be retired. Each condition affects whether a companion has something sound to explain, and a plain-language layer can't rescue a technical post whose own status is still unclear. ## Moving the leak check to draft time The gate changed too. We had treated the leak check as a publishing concern, something that happened at the end after a draft was otherwise finished. The work moved that check from publish time to draft time, so a draft was safe when it was written. It's a small shift in sequence, but it changes the artifact under review. A late check protects the release. A draft-time check protects the words that every later edit, companion post, and review will inherit. It belongs in the same picture as the companions. Plain language is no excuse to get loose with the source or careless about what the text exposes. The posts had to be both understandable and safe at the moment of drafting. That sequence let companion work begin from a bounded artifact, and readability never became another reason to delay the check. ## What we had assumed The uncomfortable part is that none of this began with a writing problem. Manus had more possible source material. The technical posts had a triage. The gate had a place in the workflow. The gap was that the system had no explicit responsibility for translating an event into plain language without sanding the event down. We had assumed technical accuracy would travel on its own. We are still wary of calling the 74 companion posts an expansion, because that makes them sound optional. They are 74 paths the technical blog did not have before. If you publish technical material for a business audience, check whether anyone is explicitly responsible for the plain-language version, and whether that version starts from content whose status (publish-ready, one edit, or retire) is already known. Put the leak check at draft time, so every later edit and companion piece inherits text that is already safe.