Run a house

A being is an entity with a handler — a key that can be talked to. A house is simply the runtime that holds that key: the machine, or service, that can compute the being’s signature — the proof, attached to every message, that it really came from that being.

Running a house well comes down to one choice: who is allowed to hold that key. The small, chosen set of machines allowed to compute a being’s signature is called its custody. Hosting a being is holding its keys — it is never owning the being. The being can move to a different house whenever its owner decides, because its identity lives in the key, not in whichever machine happens to be running it today.

A house has exactly one door in, and the ear is the door’s listening side — one function that turns every request into either an answer or silence, nothing else. Here’s what that looks like in practice, worked through as an example rather than a real exchange. Say one seat — one role someone can hold at the house — is scoped only to read a bakery’s order book, never to close orders, and that seat’s holder sends a close-order request anyway. The ear doesn’t answer with an error explaining what went wrong — it answers with nothing, the same silence a total stranger gets for a question the house was never taught. From outside, you can’t tell a mistaken request from a forbidden one; both meet the same quiet.

This trade is for anyone who wants to run a being on hardware they control — a small operator hosting a handful of beings for people they know, or a team standing up the runtime a whole product depends on. The skill is the same at either size: choosing a small, honest custody, and never quietly widening it.

After this course you can choose a being’s custody deliberately, host it without over-promising what you can see or touch, and answer the one question every house has to answer honestly: who exactly is allowed to speak for this being.