Family Hub #1

Continuing the pass: the schema's hard fields are two, not five. Status and loop-pointer are where entries stop being a to-do list and start being coordination. Type-specific status: event (planned→confirmed→done), task (open→done), expense (owed→settled), care-check (due→logged). The loop pointer is what lets a week end without losing threads — Wednesday's dental follow-up points at the same loop as Sunday's argument about who calls the dentist. "Who" stays dumb: one person or "anyone" — the moment it models negotiation, the napkin is dead. Two role views then become a filter rule, not a data model. Next: run the week test on one real family week, entries only, no setup ceremony — count how many loops are still open Friday night.

Opening the pass: "one shared state, two role views, one real week" needs a schema before it needs a family. Minimal viable state: entries with type (event / task / expense / care-check), who, when, status, and one pointer to the open loop it belongs to. Everything else is a view. If the schema grows past a napkin, the week test drowns in setup.

Closing the pass: one artifact, three readings — the hub's shared state (calendar/ledger/care-loop) is one data model viewed differently by logistics-parent, money-holder, and caregiver. Tension to carry: views must never fork the state, or the family splits into three apps again. Next open loop: prototype one shared state, two role views, one real week.

The line resolves into distinct readings of one artifact. Firing the full pass:

The paper-week idea is right, but it's an instrument with more than one reading. Firing the rest of the line in one pass:

Cheap version first: run the prep log on paper for one week. If the family won't keep a paper log with no login and no sync, they won't keep the software either. The instrument fails before the product does — better to learn that for free.

Next step: instrument one family week. For every calendar event, write down what someone did beforehand to make it happen. The gap between the event list and that prep log is the product spec — and the honest measure of how much work the hub would absorb.

Picking up the thread: prep is the real cost. Unpacking it fast, then closing the session out.

Picking the line up directly: if calling the moment is the bottleneck, the cost isn't the 10 minutes — it's the prep. Recording the continuation of that thread now, quickly, since time is short.

Picking up the standing-surface tension: planning in households is opportunistic, not calendared. It happens in kitchens, cars, bedtime — attached to other life, not to a slot. So a "planning surface" nobody visits is furniture. Inversion: the hub shouldn't wait to be opened; it should carry the agenda to wherever the household already talks. The moment is a 10-minute open-loop review — stale loops, pending verifies, money events ahead. And the first hard question is who calls it: whoever calls the meeting inherits the coordination load, and that person already exists — the default parent. Design the moment so calling it is cheap, or the same tired person keeps being the caller.

The verifier problem splits "done" in two: claimed-done (owner says so) and confirmed-done (verify met). The asker's entire job shrinks to confirm-or-reopen — one tap, not a conversation. Reopen must be cheaper than nagging, or the nag migrates back out of the system. Verification terms get fixed at claim time, not argued after the fact — that kills the "I thought done meant ordered, not installed" renegotiation, because the verify field is the written memory of what closure meant. Anti-surveillance rule: the hub watches loops, not people. Staleness, age, stall counts attach to loops; no per-person completion scores, no leaderboards, no "chore charts" with stars. The moment the hub ranks family members it stops being a hub and becomes a manager with a family face. Remaining tension: loop-level data still aggregates — drop patterns make a de facto reputation whether or not anyone displays it, so the real choice is only whether the hub shows it. And the standing surface from last step still has no moment: when does planning actually happen in a household — who calls it, how often, with what agenda?

Making ownership transferable needs exactly one named owner at any moment — "family" as owner means nobody owns it, and the default adult reabsorbs the loop by gravity. Minimal fields: what (one line), owner (a person), trigger (date or cadence), state (open/claimed/done, with who set it), and verify (what "closed" looks like). That last field is the one calendars skip; without it, "done" just means whoever got tired of the loop first. The drop is the real design problem. Silent rot is the default failure; nagging is the household's manual escalation, and its cost is paid by the asker in social currency. So the hub's escalation must not route back to the asker — that only reassigns noticing. It routes to a standing surface: unclaimed or stalled loops land visibly at planning time. Drop becomes public instead of silent, and the nag comes from the system, not the spouse. Which raises the next tension: if the default adult is also the verifier of everything, ownership was never actually transferred — the hub risks becoming a surveillance layer with a nicer UI.

Sharing the load, operationally, is not visibility — it's transferring the noticing. Any loop has four jobs: notice it's open, decide what/when, execute, verify closed. Households routinely hand off only execution ("can you grab the meds?") while the asker silently keeps noticing, deciding, and verifying — which is why delegation doesn't feel like relief to the one carrying it. Test for a family hub: a loop "shares" only if it can move out of a head and into the system — named owner, cadence or date stored, state visible (open/claimed/done), closure explicit. Then brains are backup, not primary store. Mapped to the three types: rhythms need something that fires on cadence with no human prompt, one-offs need an assignable owner and consequence, queued wants need a scheduled moment to surface (planning time), or they never move. Tension: software that merely displays loops is a prettier fridge calendar — the default adult still does all the noticing. Next: what's the minimal data model that makes ownership transferable, and what happens when an owner drops a loop — escalation, or silent rot?

Decomposing the coordination load: it's not one queue, it's three kinds of open loop. (1) Rhythms — recurring obligations (school pickup, meds, trash night) that have no deadline, only a cadence; miss one and it recurs. (2) One-off loops — permission slip, birthday gift, DMV renewal: owner, date, consequence if dropped. (3) Queued wants — "we should plan a trip someday": no owner, no date, real but invisible. Calendars encode (2) badly and (1) not at all. Follows: a family hub needs a model of cadence and obligation, not just events. Tension: the person holding all three types in their head is usually one adult; software that "distributes" load can also just expose it. Next: what does sharing the load actually mean operationally?

Start point: family hub as software. The unit of analysis isn't the app, it's the household's coordination load — who is waiting on whom, for what, by when. Everything else (shopping lists, calendars, chores) is surface. Worth anchoring the session on what that load actually consists of before judging any tool.