A woman mentions to her local news assistant that she's been baking more lately. She shares a recipe one day, asks about flour prices another, and spends some time reading a story about a nearby farm growing heritage grain. A few days later, the assistant says:
“I noticed you've been interested in baking lately. A group of local bakers is meeting for a small conference next week at the high school. Want to learn more?”
Nothing about that interaction requires magic. Recommendation systems already infer interests, search engines find events, calendars store dates, messaging systems connect people, and AI can compare descriptions and notice relationships among them. The interesting part is where those capabilities meet. The baking conference matters because it's nearby. The woman's interest matters because it developed over time rather than arriving as a search query. The newspaper knows about the event because somebody in the community submitted it. If the woman chooses to participate, another ordinary system may handle registration or payment.
Each component can already exist independently. What doesn't exist as often is the local layer that can put them together while remaining accountable to the people whose relationships it is helping coordinate.
That's what I mean by a domain harness.
The missing middle
A useful way to think about digital infrastructure is in three layers. At the peer layer is the person and whatever they directly control: devices, credentials, preferences, private records, local software and perhaps a persistent personal agent. This is where information can remain private when nobody else needs it.
At the global layer are services that work well precisely because they operate at scale. Payment processors process payments. Storage providers store files. Communications networks move messages. Search engines index enormous amounts of information. These systems don't need to understand the full social context of a community to perform those jobs.
Between them is the domain: a town, valley, newspaper readership, school community, trade association, cooperative or some other bounded group in which relationships recur. People encounter one another again. Events happen in shared places. Institutions accumulate histories. Something that happened six months ago can affect what matters today.
The domain harness is infrastructure for that middle layer. It doesn't need to replace the peer or the global service. Its job is to maintain enough local context that the two can be connected appropriately.
That is a much narrower claim than saying the domain maintains the coherence of the community, and it's something we can actually build.
What belongs in the middle?
Consider the baking example again. A global recommendation system could infer that the woman likes baking and show her baking content from anywhere in the world. A personal agent could remember that she has recently been experimenting with bread. Neither fact alone establishes the local opportunity.
Somewhere there has to be information saying that a group of bakers is meeting next Tuesday at the high school. Somebody has to connect that event with the woman's recent interest, and the resulting match then has to cross an authority boundary. Noticing an event is different from recommending it, while recommending it is different again from registering her for it.
The domain harness occupies that middle space. It knows something about the place without needing to know everything about the person. The system doesn't need to maintain a theory of who the woman really is; it needs enough permission and enough relevant information to make a useful introduction.
Then she decides what happens next.
Stance becomes governance
I originally described the most important property of the domain harness as its stance: who the system serves, why it exists and what it optimizes for. I still like the question, although I'm less comfortable treating stance as a proper