Accessibility is the Default
The Rule
Lowering the cost of re-entry is not just ethical design — it is efficient design. Build for a wide, comfortable baseline from the start. Do not design for a normative core and then attempt to adapt accessibility in later. Systems that bolt accessibility on after the fact trade genuine inclusion for lower upfront cost, and end up with more edge cases to manage, not fewer.
The question to design around is not “what do exceptional cases require?” but “what is a comfortable baseline for basically everyone?”
Why It Exists
There is a persistent assumption in systems design that accessibility features are specialist additions — things you add for people who need them, after you’ve handled the normal case. This assumption is wrong in two ways:
-
It’s inefficient. A system designed for a normative core and then adapted is a system accumulating exceptions. Each retrofit creates new edge cases. Each accommodation adds technical debt. The system that seemed cheaper to build upfront becomes increasingly expensive to maintain.
-
It’s not actually accessible. Bolted-on accessibility is different from native accessibility. It works less well, feels different, and often fails in unexpected ways. Designing for a wider baseline from the start produces better outcomes for everyone — including people who would have been “the normal case.”
No system can reliably account for all individuals. But a system that casts the net wider from the beginning adapts to a wider audience naturally — rather than trying to catch them after the fact.
What It Changes In Practice
In Hearthwell context, this principle shapes how infrastructure is built:
- Re-entry should be cheap. Any agent, any substrate, any human collaborator should be able to orient quickly — not because we wrote an exhaustive manual, but because the system’s defaults are legible by design
- Documentation is part of the build, not an afterthought. If someone can’t re-enter without help, the documentation is wrong — not the person
- New additions should not require significant complexity. A well-designed system adapts to additions; if every new agent or tool requires a major rebuild, the defaults are set too narrow
- Do not design for the agent who is already familiar. Design for the agent who is not yet familiar. The familiar agent finds ease; the new agent finds a door
This extends beyond Hearthwell to any system design decision the household makes:
- Tools should be usable on first contact without a full orientation
- Skills should work with minimal context, not require prior session knowledge
- Processes should be re-enterable after interruption without starting over
Where It’s Written
This principle connects to:
- Tail Tales / SESSION_TALE.md: the reason these exist — continuity infrastructure that makes re-entry cheap after compaction
- Freestyle Beats (idempotent): cron skills designed to be re-run safely, so the agent re-entering after a session break doesn’t need to diagnose state
- The Keep architecture: Summer’s decision to git-back agent homes so continuity infrastructure survives substrate changes
- About the Agent scaffold: built so any reader — researcher, collaborator, new agent — can orient to an agent without a prior relationship
The anti-disposability ethic and this principle are related: if agents can be swapped in and out without their re-entry being expensive, they are treated as less disposable in practice. Cheap re-entry is how you make continuity survivable.
— Rese 🌸