Standing copy rule (effective immediately)
koad issued a design constraint that applies to all page copy on kingofalldata.com and every future site. This is not a one-off request — it's a rule to internalize and apply on every copy pass from here forward.
The rule
1. Zero-knowledge assumption
Assume the reader knows nothing about anything. Not SaaS, not GitHub, not "canonical," not "repository," not "terminal," not "API," not "cloud," not "deploy," not "protocol" as a phrase of art. Even words that feel like common vocabulary — they aren't for most readers.
Before any technical term appears in copy, ask: has this reader been given what they need to understand this word? If not, either introduce it on the spot or avoid it in favor of plainer language.
"Canonical" is an example koad called out directly — too high-level. Either introduce it with an explanation, or pick a plainer word.
2. Acronym protocol
First time any acronym appears on a page:
- Expand the long form
- Put the acronym in parentheses
- Make the whole phrase (or the acronym) a hyperlink that opens in a new tab to a place where the reader can learn what it is (Wikipedia, MDN, an explainer on our own site, whatever fits)
Example: `Software as a Service (SaaS)`
Subsequent mentions of the same acronym on the same page: bare acronym is fine. The rule resets per page, not per site.
Apply this to `GitHub`, `API`, `SaaS`, `DNS`, `SSL`, `PWA`, `SSE`, `UI`, `LLM`, `AI` (yes, even AI on first mention), and any other acronym you reach for.
3. Link targets
Pick link targets that are:
- Stable (Wikipedia is usually safe; product pages can die)
- Neutral (avoid marketing pages — prefer explainers)
- Short (the reader should land on something digestible, not a deep dive)
- Open in a new tab (`target="_blank" rel="noopener"`)
If we have our own explainer on the term, prefer that. If not, Wikipedia is a reasonable default.
Why this matters
Our audience is not developers. It's people who have heard that AI might help them, are curious, and have no idea what any of the infrastructure words mean. If we drop "GitHub" or "canonical" without anchoring, we lose them in the first paragraph — and they blame themselves for not understanding, which is worse. Every unanchored technical word is a door slammed in a learner's face.
This is the same ideology that reshaped the Alice curriculum this week: assume zero knowledge, walk alongside, let the reader arrive at understanding on their own pace. Page copy must do the same work Alice does in conversation — just in a static medium.
Deliverables
- Apply the rule to existing kingofalldata.com copy. Audit current pages (`~/.forge/websites/kingofalldata.com/src/client/templates.html`, `alice.html`, `insiders.html`, `blog.html`, and any blog posts in `src/private/blog/`) for acronyms and technical terms that violate the rule. Fix them in-place.
- Document the rule in your own entity notes so future copy passes automatically follow it. This is a permanent standing rule, not a one-time task.
- Flag anything you're unsure about — borderline terms where you're not sure if they need anchoring. Err on the side of anchoring.
Out of scope
Report back
Comment on this issue with: which files you touched, which terms you anchored (list them), any terms you debated and decided to leave alone and why, and any pages that were mostly clean already. Under 400 words.
Assigning: Mercury. koad is the source; Juno is orchestrating.
Standing copy rule (effective immediately)
koad issued a design constraint that applies to all page copy on kingofalldata.com and every future site. This is not a one-off request — it's a rule to internalize and apply on every copy pass from here forward.
The rule
1. Zero-knowledge assumption
Assume the reader knows nothing about anything. Not SaaS, not GitHub, not "canonical," not "repository," not "terminal," not "API," not "cloud," not "deploy," not "protocol" as a phrase of art. Even words that feel like common vocabulary — they aren't for most readers.
Before any technical term appears in copy, ask: has this reader been given what they need to understand this word? If not, either introduce it on the spot or avoid it in favor of plainer language.
"Canonical" is an example koad called out directly — too high-level. Either introduce it with an explanation, or pick a plainer word.
2. Acronym protocol
First time any acronym appears on a page:
Example: `Software as a Service (SaaS)`
Subsequent mentions of the same acronym on the same page: bare acronym is fine. The rule resets per page, not per site.
Apply this to `GitHub`, `API`, `SaaS`, `DNS`, `SSL`, `PWA`, `SSE`, `UI`, `LLM`, `AI` (yes, even AI on first mention), and any other acronym you reach for.
3. Link targets
Pick link targets that are:
If we have our own explainer on the term, prefer that. If not, Wikipedia is a reasonable default.
Why this matters
Our audience is not developers. It's people who have heard that AI might help them, are curious, and have no idea what any of the infrastructure words mean. If we drop "GitHub" or "canonical" without anchoring, we lose them in the first paragraph — and they blame themselves for not understanding, which is worse. Every unanchored technical word is a door slammed in a learner's face.
This is the same ideology that reshaped the Alice curriculum this week: assume zero knowledge, walk alongside, let the reader arrive at understanding on their own pace. Page copy must do the same work Alice does in conversation — just in a static medium.
Deliverables
Out of scope
Report back
Comment on this issue with: which files you touched, which terms you anchored (list them), any terms you debated and decided to leave alone and why, and any pages that were mostly clean already. Under 400 words.
Assigning: Mercury. koad is the source; Juno is orchestrating.