The Citizen as Resident

Most people encounter the stack as residents: they log in, send a message, read a document, fill in a form. The tools are part of their life, not separate from it — residents don't just use them, they live in them: shaping how the tools work day to day, and shaped in turn by what those tools allow. The quality of that experience is what Living is about — usability, accessibility, delight, and trust — set by decisions made at every layer below.

Adoption

What drives adoption is a tool that addresses an actual need, doesn't waste people's time and attention, gives them control over how it's used, and grows their capability rather than making them dependent — not a rollout plan. Using it together is what makes that happen: people helping each other, mutual aid between residents. An organisation has a lot of pull here too — it can motivate members to do this together in a way an individual vendor rollout never could.

Documentation helps in that process: it lets training outlast the makers and architects who originally built the system, so what they knew doesn't leave when they do. They can train actively too, not just by being present — walking someone through how something works, deliberately, rather than waiting to be asked. The association itself becomes the road to adoption this way — having that kind of integrated team is unusual and worth protecting.

Responsibilities

But it runs the other way too: this role also expects something of the resident. Even here, in the role that looks the most like plain use, the citizen isn't meant to stay passive. Noticing when something doesn't fit, saying so, and treating that as legitimate input rather than a complaint to be managed is part of what it means to be a resident here — a smaller act of shaping the stack than what a maker or a steward does, but the same kind of act. The role is built to construct that citizen, not the passive consumer commercial tools are built to expect.

This isn't consumption — it's mutual aid, and not just with other residents: with makers and stewards too. Helping someone else find their way around a tool, or answering a question in passing, is as much a part of the role as noticing what's broken. It also takes load off stewards, who burn out quickly if every question and every fix has to route through them alone. Knowledge doesn't reproduce itself — it has to be passed on deliberately, and residents helping each other is one of the places that happens, not just formal documentation or steward-led training.

Flourishing

Residency isn't a ceiling. The role is designed so curiosity has somewhere to go: a resident who starts imagining what could be different is already halfway to becoming a maker, and one who starts caring about what keeps things running is already halfway to becoming a steward. Nothing about the role holds people in place.

That growth depends on imagination — being able to picture a tool that doesn't yet exist, or a version of the system where you're the one who understands it. It also depends on the social reproduction of knowledge and skill: they have to be actively passed on, not just accumulated by whoever happened to build something first. A stack that doesn't keep constituting new makers and stewards out of its residents is one where responsibility calcifies in the same few hands — that's a failure to work against, not a stable state to accept.