How to run a faith-community service project without losing meals, rides, or the signup sheet

Miriam is a fictional 58-year-old volunteer organizing a week of meal delivery from a congregation in Richmond, Virginia. Miriam’s community delivers meals each December. The kitchen is booked, fourteen cooks signed up, and two drivers dropped out. A list of recipient households from last year may be stale, so Miriam has already requested address confirmations. Someone suggested doubling the number of meals.

A paper signup, a kitchen calendar, and last year’s address list do not share Tuesday.

Doubling meals sounds generous and would strand food if drivers stay at the reduced number.

In You.one's Superboard view, Miriam can give “Deliver this year’s meals with a current household list, enough drivers, and a kitchen schedule—without doubling volume by slogan” a Board of its own. That Board connects community promises, volunteer capacity, local evidence, and human authority; opening “Choose count versus drivers” creates a Room for its evidence, discussion, state, and decision.

The mission is specific: Deliver this year’s meals with a current household list, enough drivers, and a kitchen schedule—without doubling volume by slogan.

The consequential choice is not something a board or an AI should quietly make: Whether to stretch four cars to twelve confirmed stops, cap the route at eight confirmed stops with two stops per car, or recruit two more drivers before proposing twelve stops. Unconfirmed household replies never count as stops.

You.one can keep the work, evidence, live dependency, and “Choose count versus drivers” decision visible through its Superboard view. The Owner boundary stays explicit: Miriam’s community chooses the scale, talks to drivers and households, and owns the meals.

The December meals Board gives this mission one durable operating picture. Miriam can use familiar language instead of translating the situation into project-management jargon. Its five Lists separate the kinds of attention this situation actually requires.

Its Cards deliberately distinguish actions, evidence, a live dependency, and decisions. A Waiting List is useful here only because a named request or outside condition is already in motion. That separation makes the current choice, evidence, and next move easier to scan.

These Card titles come directly from Miriam's situation: “Choose count versus drivers” is the live choice, “Two drivers dropped out” holds evidence, and “Household confirmations” names something genuinely in motion outside Miriam's control. The point is recognition, not a perfect taxonomy.

Opening the Card gives the visible item durable depth. Stage can hold Scale brief: Place last year's twelve stops and six drivers, this year's four remaining cars, still-unconfirmed household replies, and the twelve-across-four / eight-at-two-per-car / recruit-two-before-twelve options on one page. Chat keeps the request and response beside that artifact instead of in a detached thread. Pulse can show “Open decision: Miriam’s community will choose a scale that four cars can actually deliver.” Activity can preserve this attributed receipt: “Ava compared the options in Card Chat using the Scale brief and this Card Room's visible notes and left “Choose count versus drivers” with Miriam’s community.”

A useful Card Chat request would be: “Using only the context visible in this Card Room, compare routing twelve confirmed stops across four cars, capping the route at eight confirmed stops with two stops per car, and recruiting two more drivers before proposing twelve stops. Treat unconfirmed household replies as unanswered here; do not move Cards, watch other Lists, contact households, or choose for us.” When live AI is configured, current Ava can respond to an explicit Card mention using supported Room context and can make limited reversible changes inside this Card Room after an explicit request. She uses only supported Room context; she cannot summarize the Board, watch other Lists, or act outside this Card Room. She does not gain authority over the decision merely because the context is organized.

Miriam's call remains explicit: Miriam’s community chooses the scale, talks to drivers and households, and owns the meals.

These requests use the visible supported context inside the “Choose count versus drivers” Card Room. They do not imply that current Ava automatically surveys the whole Board or follows up on her own; Miriam must provide the relevant facts and check the result.

Current Ava can reply in this Room to an explicit Card mention using supported Room context. She cannot summarize the Board, make the choice, represent Miriam, watch other Lists, or act outside this Card Room.

The community owns meals, contacts, and routes. Ava does not contact households, drive, or give dietary advice.

A week that can be driven: cooks are not mistaken for cars, last year’s list is a confirmation job, and volume is a decision.

• Request idea: using only the context visible in this Card Room, compare routing twelve confirmed stops across four cars, capping the route at eight confirmed stops with two stops per car, and recruiting two more drivers before proposing twelve stops. Treat unconfirmed household replies as unanswered here; do not move Cards, watch other Lists, contact households, or choose for us.
• Request idea: use only the Scale brief and notes the Owner has placed in this Card Room to separate facts, assumptions, and unanswered questions
• Request idea: name which visible Room note could most change the comparison; do not watch other Lists or follow up autonomously

A paper signup plus last year’s addresses is enough when drivers and households are unchanged.

It starts to break when two drivers are gone and someone wants to double the food.

The December meals Board earns its place only when the familiar tool—a paper signup plus last year’s addresses—can no longer keep the reason, Scale brief, conversation, current state, decision, and history connected.

Miriam should rename every List or Card that feels artificial. This recipe succeeds when “Choose count versus drivers” becomes easier to decide and fewer open loops depend on memory—not when the Board looks tidy.

Later, Ava may help this Board notice when meal count exceeds driver Cards, still leaving every route with Miriam.

A future unified You.one experience could carry relevant context from “Choose count versus drivers” across guidance and the Superboard view. Broad proactive coordination, cross-surface personalized memory, realtime shared editing, and general external execution are not available today. Any future action would still require the applicable capability, connection, grant, and human authority.

• Miriam is fictional and is not a customer, testimonial, research participant, or disguised real person.
• This is not dietary, medical, or charitable-registration advice.
• It does not show Ava contacting households or driving deliveries.
• It is not a measured service result.