Browse KB
Content Quality
Public Content Boundary
Public pages should explain the useful part of the work without asking readers to decode private working material. The goal is not to hide the work. The goal is to translate it.
Keep
- The problem a reader can understand.
- The decision or tradeoff that shaped the result.
- The pattern that could help someone else.
- The public outcome: what changed, what became clearer, or what became easier.
- Links to related articles, work pages, KB entries, or focus tags.
Leave Out
- Private working paths, hostnames, or access details.
- Raw logs, backstage sequence, and internal coordination chatter.
- Issue IDs, board mechanics, or temporary labels.
- Family or location specifics.
- Any detail that proves work happened but does not help a reader understand the public idea.
Translation Pattern
| Private shape | Public shape |
|---|---|
| A long working thread | The decision that came out of it |
| A checklist with internal steps | The public quality check it supports |
| A technical fix | The reader-facing improvement it created |
| A private tool name | The job the tool helped accomplish |
Change Check
Review this reference when public boundary rules, scanner terms, publishing policy, or site copy standards change. A boundary page that does not track the real rules can become misleading even if it still reads well.
Source
- Raw Markdown: /assets/files/operating-library/kb/public-content-boundary.md
- Source maturity:
active - Change watch: public/internal content boundary rules, private-term scanner config, RR public copy standards