Design for Neglect

The single most reliable predictor of whether a knowledge system survives is whether it tolerates absence. Most don't. They demand daily attention, accumulate guilt during silence, and require a recovery ritual to come back to. The system that wins is the one you can ignore for a month and still find usable.

The principle

The KMS must be designed under the assumption that the user will neglect it. Not "what if the user falls behind" — when. The system stays useful through neglect, surfaces what's stale on return, and never demands a backlog clearing as the price of re-entry.

Why it matters

Life happens. Vacations, intense work weeks, illness, change of focus. Systems that punish absence get abandoned during the first prolonged absence and never re-adopted. Systems that survive absence become long-term infrastructure.

The asymmetry is brutal: a KMS that requires daily upkeep loses its user permanently the first time they take a two-week break. A KMS that requires zero upkeep gets used for years. The difference in capability is small. The difference in survival is total.

How it works

Five concrete moves:

1. No accumulating obligations. No "review queue that grows" or "weekly digest you have to read." The system pulls forward what's relevant when asked; nothing waits for processing.
2. Auto-decay on state. Items in the state layer that haven't been touched in N days get auto-archived (with a recoverable trace), not added to a "stale items" backlog.
3. Re-entry summary. When the user opens the system after silence, the first thing surfaced is a one-paragraph "here's what changed / what's stale / what to ignore" — generated on the fly, not waiting in a queue.
4. No streak mechanics. No "you haven't checked in for X days" guilt. The system doesn't care.
5. Compounding doesn't depend on the user. Automatic compilation runs whether or not the user shows up. Knowledge gets distilled, linked, and surfaced even if the only input for a month was a single email.

In Claude primitives

• Subagents run periodic decay/archive sweeps on a schedule (cron, GitHub Actions, or a Trigger.dev task).
• Skills like re-entry-summary produce the catch-up note on demand — never proactively.
• CLAUDE.md explicitly forbids guilt-trip patterns ("never tell the user they're behind"; "never present a backlog as a queue to clear").

Where I've seen it

A personal KMS's check-in skill is built on this principle — opens with a re-entry summary, never with a backlog. A team KMS's customer dashboard does the same at team scale: stale signals get archived rather than perpetually surfaced. The opposite pattern (a calendar app that surfaces every missed task) is what convinces people they "aren't disciplined enough" for knowledge systems.

The contrarian read

This makes the system feel less "powerful" — fewer dashboards, no streaks, no productivity-app dopamine. Good. The systems that compound are the ones you don't notice you're using, because they don't ask anything of you.