Status labels explained

Status: 🟩 COMPLETE Last updated: 2026-06-21 Plain-English tagline: Four colored squares — 🟥 🟨 🟩 🟦 — tag every entry’s polish level. They appear at the top of each entry AND next to every cross-link. Glance to know what to expect.

In plain English

Every entry in the encyclopedia has a status. Four possible values, with colored-square emojis to make them pop visually:

Badge	Name	Meaning
🟥	STUB	Title and tagline only. No real content yet. Listed so we know it’s a planned topic.
🟨	DRAFT	Substantive content, but rough or incomplete. Use cautiously; verify before relying on it.
🟩	COMPLETE	Written, reviewed, cross-linked, sourced. This is the gold standard.
🟦	LIVING	Written and reliable, but the underlying topic itself evolves frequently (Vercel ships weekly; AI tools change monthly). Treat as a snapshot.

The status badge sits at the top of every entry inside a blockquote with the “Last updated” date and the plain-English tagline:

> **Status:** 🟩 COMPLETE
> **Last updated:** 2026-06-19
> **Plain-English tagline:** ...

The same badges appear next to every cross-link in “See also” sections, so you know what to expect BEFORE clicking:

## See also
- [HTML](../02-frontend/html.md) 🟩
- [CSS](../02-frontend/css.md) 🟩
- [WebAssembly](../02-frontend/wasm.md) 🟥

This makes navigation honest: you can see at a glance whether a link goes to a polished entry or a placeholder.

When each badge applies

🟥 STUB

Listed in a section index because the topic is planned, but the actual file either doesn’t exist or has only:

Title
One-line description
Status badge marking it as a stub

You don’t read STUBs. You IDENTIFY them so you (or a future session) can come back to write them.

If you click a 🟥 link, you usually find a near-empty file or a 404. That’s expected.

🟨 DRAFT

There’s real content but it’s incomplete. Common cases:

A first pass written quickly; needs review + polish
Most sections present but “Common gotchas” is thin
Cross-links not yet badged
Sources not yet added

DRAFTs are USABLE but worth verifying. The content is probably correct; the polish isn’t there.

In practice, the encyclopedia rarely uses 🟨 — most entries are either stubs or completes. Drafts appear briefly during writing then get upgraded.

🟩 COMPLETE

The gold standard. Has all seven sections of the entry template:

Status block + tagline
“In plain English” — non-coder analogy
“Why it matters” — 2-4 sentences
Concrete example
“Common gotchas” — specific, topic-relevant items (5–15 typical; more if the topic warrants; fewer if it doesn’t have more)
“See also” with status badges on every cross-link
“Sources” with authoritative external refs

Every 🟩 entry has been reviewed against the iron-clad quality bar (see feedback-encyclopedia-quality — though that’s in memory, not in the encyclopedia itself).

If you’re choosing what to read: 🟩 means “reliable; this is what you want.”

🟦 LIVING

Same standard as COMPLETE — full sections, full quality — but the UNDERLYING TOPIC moves fast enough that the entry is a snapshot, not a permanent truth.

Examples of LIVING entries:

Vercel 🟩🟦 — Vercel ships changes weekly. The entry is current as of its “Last updated” date.
Next.js 🟩🟦 — major versions ship yearly; minor features monthly.
Claude models 🟩🟦 — model lineup changes; pricing changes; capabilities expand.
Mobile development 🟩🟦 — iOS/Android annual cycles plus React Native + Flutter constant churn.

A LIVING entry asks you to:

Check the “Last updated” date
Be skeptical of specific facts (versions, pricing, features) if dated
Use authoritative sources to verify when accuracy matters

Notably, 🟩🟦 entries are STILL gold standard — the quality is the same; the topic just doesn’t sit still.

How to interpret a cross-link with a badge

In a “See also” block:

- [Vercel](../06-hosting-and-deployment/vercel.md) 🟩 🟦 — the deploy platform
- [DNS deep dive](../13-networking-essentials/dns-deep-dive.md) 🟩 — protocol-level
- [Game dev — overview](../15-broader-tech-bonus/game-dev-overview.md) 🟩 🟦
- [Some future entry](../somewhere/not-yet.md) 🟥

Reading these:

🟩 — safe to click; full entry
🟩 🟦 — full entry but verify date for time-sensitive facts
🟥 — placeholder; don’t expect content yet
🟨 — incomplete but partial value

Multiple badges combine. 🟩 🟦 is common; 🟨 🟦 would mean “draft AND living”; 🟥 doesn’t combine with others (a stub is just a stub).

Why this matters

Status badges solve a common problem with personal knowledge bases: you can’t tell what’s polished vs. unfinished without opening every file.

With badges, every cross-link tells you what you’re getting BEFORE you click. The encyclopedia stays honest about its own state. You waste less time on unfinished content.

For the encyclopedia author (George + Claude): badges drive the work plan. “What’s 🟥?” → that’s the next batch.

For the encyclopedia reader: badges drive trust. 🟩 means “this earned the quality bar”; 🟦 means “still trust, but cross-check facts that might have moved.”

How badges get updated — the maintenance protocol

The three rules at the entry being changed:

Update the badge when status changes. Stub → complete is the most common upgrade. Always edit the Status block at the top of the entry.
Update the “Last updated” date simultaneously. The two go together.
Verify all 7 sections are present before marking 🟩 COMPLETE. See feedback-encyclopedia-quality memory for the iron-clad bar.

Then the part that’s easy to forget — and that the encyclopedia has learned about the hard way:

The back-link bump protocol

When an entry’s status changes, every OTHER entry that links to it needs its See-also badge updated. There’s no automatic propagation.

The procedure, in order, the same session as the upgrade:

Identify the filename. E.g. 10-ai-and-llms/tool-use.md.
Grep for it. Search the encyclopedia for the filename. Use VS Code’s Ctrl+Shift+F (scope to the encyclopedia folder) or grep -r "tool-use.md" ..
For every match in a See-also section, update the badge from the old status to the new one.
Skip matches in body prose — only See-also badges need updating. Inline links typically don’t carry badges.
Commit the bumps with the upgrade, not later. Bundling them prevents the rot from compounding.

This costs ~60 seconds per upgrade. Skipping it costs an entire sweep session later (sessions 36–42 corrected 108 stale badges across 27 anchor entries in a multi-session audit).

The 2-axis rot model (lessons from the sweep)

Sessions 36–42 of the build revealed when badge rot accumulates and when it doesn’t:

Axis	What it means
Age	How long ago was the linking entry written?
Downstream closure	When did the target sections complete?

Rot happens when BOTH are true: the linking entry is old AND its See-also points into sections that closed after it was written. The older the entry and the more late-closing sections it touches, the worse the rot.

Rot doesn’t happen when the See-also is contained within the same section as the entry (intra-section links), because the entire section’s status converged together — there’s no window where targets were 🟥 long enough to leak into a See-also that stayed stale.

Worked example from the sweep:

vercel.md (Section 06, written session 2) had 9 stale 🟥 badges. Its See-also touches Sections 03, 06, 07, 08, gotchas, how-to — completed across sessions 17–34. Old + cross-section + late closures = worst rot.
claude-code-deep-dive.md (Section 11, written session 3) had 0 stale badges. Its See-also is contained within Section 11, which closed session 5. Same age, but intra-section, so no rot.

Implication for prevention: the bump protocol matters most for cross-section anchors. Intra-section anchors are self-cleaning. When you write a textbook entry that links outward into many sections, the bump discipline is non-negotiable.

When to run a sweep instead

If discipline lapses for a while (multiple upgrades happened without bumps), don’t try to backfill ad hoc. Run a deliberate sweep:

Pick 5 entries to review per turn (the per-turn cap).
Prioritize the oldest entries with the broadest cross-section See-also lists.
Read each entry, identify stale badges, fix them, bump the “Last updated” date.
Update the changelog with the totals.
Repeat until the high-yield zone is cleared.

The 2-axis model tells you when to stop sweeping: once you’ve covered the OLD + CROSS-SECTION anchors, the remaining yield drops sharply. Intra-section entries and post-bulk-closure entries can be left alone unless an explicit hit surfaces during normal use.

A note on the iron-clad quality bar

Marking an entry 🟩 is a PROMISE that it meets the bar. The promise:

Required sections present and meaningfully filled
“In plain English” works for a non-coder
At least one concrete example
Common gotchas: specific, topic-relevant (5–15 typical; quality > quantity)
Cross-links are real (point at actual entries with current badges)
At least one authoritative source

Marking something 🟩 without meeting these is dishonest. The full discipline lives in the feedback_encyclopedia_quality.md memory file.

For 🟨 DRAFT: lower bar — substantive but not polished. Used sparingly.

For 🟥 STUB: no real content; just a placeholder. Skipping the quality bar is fine because there’s nothing to evaluate.

What badges do NOT mean

A few clarifications:

🟩 doesn’t mean “perfect.” It means “meets the quality bar.” Some entries could still be improved.
🟦 doesn’t mean “wrong.” It means “snapshot in time; verify time-sensitive facts.”
🟥 doesn’t mean “unimportant.” Many planned entries are valuable but not yet written.
🟨 doesn’t mean “wrong.” It means “incomplete.” Content is usually correct; polish isn’t.

Read badges as level-of-polish, not as truth signals. Authoritative sources are in the “Sources” section of each entry.

Sources

This entry is meta. The encyclopedia’s CONVENTIONS.md defines the badges formally.

Tech & AI, Explained

Explorer

status-labels