The rule started out selfish
None of it began with the reader. The first reason for writing a technical term out in plain words was that doing so organizes the term in my own head, which is about as self-serving as a house rule gets.
What it turned into is the rule that still runs here. Internally I call it the plain-language gloss rule, and it comes to this: a technical term doesn't get to stand on its own. Write "AI agent" and a short explanation follows it — a way of handing one role to an AI and letting it run. Write "passive approval" and the explanation comes right after: a flow where nothing arriving inside the time limit counts as approval. The point was never to write at greater length. A few words wedged in directly after the term, and that is the whole of it.
Switch the rule off and a sentence comes out like this.
"In this project, subagent works from SPEC to draft the body text, and a tone check runs before it passes the QA gate."
Built on purpose without a single explanation in it. The skeleton is readable — something acts on something else, in some order. But the first term stops a certain kind of reader cold, and once SPEC and QA gate and tone check stack up behind it, each one stays a blur. The structure parses and the activity doesn't. It is an odd state to be left in.
Put the explanations back and it reads: subagent (a small unit handed exactly one role) works from SPEC (the document saying what to build) to draft the body text, and a tone check (confirmation that the writing sounds the way it was meant to) runs before it passes the QA gate (the quality pass before anything goes out). Heavier, and probably harder on the eyes. But what is being done can now be followed. Whether someone unfamiliar stays with it or drops out seems to turn on that much.
Someone who hits one unfamiliar term after another doesn't file them away to look up later. The judgment is faster and cruder than that: this one isn't for me. Which is less a claim about readers in general than something recognized from the other side, back when the reading was being done rather than the writing.
There is a specific person behind all of it, and that person is a construct rather than a survey result. High IT literacy, but no particular grounding in getting several AIs to work alongside each other. Early thirties to early forties, running systems at a small or mid-sized company. Stuck, specifically, on who manages which agent and how. Stack terms in front of that person and what comes back is admiration, and nothing gets attempted afterwards. Plain words describing what was tried and what came of it seem to move things further along — at least, that was true from the reading side. An article dense with terminology conveys the competence of whoever wrote it. Whether the reader carries anything away from it is a separate question.
For a while, though, the brackets in these posts were carrying two loads at once. One was meaning. The other was pronunciation: the reading of a Japanese compound, the katakana spelling of an English word. Both went in side by side, as though they were the same kind of help. Adding the pronunciation felt at the time like part of the same rule. It wasn't. Failing to pronounce a word and failing to know what it points to are separate failures, and only the second one halts anything. A compound whose characters resist a reader can be read straight past, provided the meaning arrived. The reverse does not hold. Explaining a term to another department in a meeting works the same way — saying it slowly and carefully to them changes nothing if the content doesn't land.
What made it obvious was going back over a batch of old posts in one sitting. Line after line where the brackets held a reading and nothing else, no explanation in there at all. Something about that looked wrong at the time. More pronunciation had gone in. No more meaning had. So the readings came out, the explanations stayed, and nothing seems to have been lost. If anything the sentences had been worse before, stretched thin by brackets carrying syllables.
The side effect turned out to be the larger half of the whole thing, or that is how it feels now. Trying to break a term down exposes exactly how far my grasp of that term actually goes. "Passive approval" would not reduce. The first attempt — a system where saying nothing means yes — was off. Close in outline, wrong in feel. After a few rewrites it came out as a deadline for objections, with approval on expiry, and that got nearer. For one clause, the distance to it was long. The version at the top of this post, the one about nothing arriving inside the time limit, is where it eventually settled.
There is a kind of manager who hands a job to a new hire entirely in jargon, and mostly that manager doesn't hold the work either. Not being able to say a thing plainly tends to be the tell.
Writing a term down smoothly, without breaking it open, can mean nothing more than leaning on it. Anyone who understands the thing should be able to put it in ordinary words, and if it won't go, that is a signal to go back to the design. As a check on myself it works, for now.
