Example
How a food truck can run event season without double-booking the generator
Sam can cook. Two events, one generator, and a permit that names an address cannot all be true unless someone chooses.
Book a season of events that the truck, two people, and one generator can actually work, with permits attached to the right Saturdays
Season income and the one-truck constraint
Keep generator and two-person coverage beside event appetite
Each date as a Card with place and permit
Compare downtown, wedding, and split-if-repaired options
Attach the permit address to that date
Generator, stock, and two-person coverage
Keep the photo from last weekend as current risk, not folklore
Turn the warning-light photo into owned diagnostic work before planning a split day
What that site actually allows and sells
Hold guest count and the planner’s allergen list as written
Sam is an explicitly fictional portrait, not a customer or testimonial.
The Event season Saturdays Board gives one mission a visible field; the Choose the wedding Saturday Room keeps its evidence, conversation, state, and decision together.
Current You.one provides the Superboard structure and explicit, bounded Ava paths described here; broader proactive or external work is not a current promise.
Why Event season Saturdays needs an operating picture
Sam is a fictional 32-year-old owner-operator of a two-person food truck in Halifax, Nova Scotia. Sam has festival applications, a weekly downtown spot, and a wedding catering ask on the same Saturday as the truck’s best regular pitch. The generator had a warning light last weekend. Permits are in a folder in the cab.
Festival email, a wedding planner text, and the downtown association calendar all look like income.
The generator warning is a photo on a phone. It is not yet a repair appointment or a no.
In You.one's Superboard view, Sam can give “Book a season of events that the truck, two people, and one generator can actually work, with permits attached to the right Saturdays” a Board of its own. That Board connects customer promises, operating evidence, capacity, and the owner's judgment; opening “Choose the wedding Saturday” creates a Room for its evidence, discussion, state, and decision.
A Saturday can only be one Saturday
The mission is specific: Book a season of events that the truck, two people, and one generator can actually work, with permits attached to the right Saturdays.
The consequential choice is not something a board or an AI should quietly make: Whether to keep the downtown Saturday, take the wedding and skip downtown, or split the day if the generator is repaired by Friday.
You.one can keep the work, evidence, and “Choose the wedding Saturday” decision visible through its Superboard view. The Owner boundary stays explicit: Sam chooses the event, talks to the planner and city, and owns food safety and spending.
Available today
Event season Saturdays: one Board shape to adapt
The Event season Saturdays Board gives this mission one durable operating picture. Sam can use familiar language instead of translating the situation into project-management jargon. Its four Lists separate the kinds of attention this situation actually requires.
Its Cards deliberately distinguish actions, evidence, and decisions while keeping unsent questions in owned work. A Waiting List would be premature until a named request or outside condition is actually in motion. That separation makes the current choice, evidence, and next move easier to scan.
| List | What belongs here |
|---|---|
| Mission | Season income and the one-truck constraint |
| Saturdays | Each date as a Card with place and permit |
| Truck | Generator, stock, and two-person coverage |
| Menus | What that site actually allows and sells |
Available today
The Cards make the operating picture concrete
These Card titles come directly from Sam's situation: “Choose the wedding Saturday” is the live choice, “Downtown pitch permit” holds evidence, and “Wedding menu constraints” is still work Sam controls—not a fake Waiting item. The point is recognition, not a perfect taxonomy.
| Card | List | Job |
|---|---|---|
| One truck, honest Saturdays | Mission | Keep generator and two-person coverage beside event appetite |
| Choose the wedding Saturday | Saturdays | Compare downtown, wedding, and split-if-repaired options |
| Downtown pitch permit | Saturdays | Attach the permit address to that date |
| Generator warning light | Truck | Keep the photo from last weekend as current risk, not folklore |
| Wedding menu constraints | Menus | Hold guest count and the planner’s allergen list as written |
| Request a generator repair quote | Truck | Turn the warning-light photo into owned diagnostic work before planning a split day |
Available today
Available today: Choose the wedding Saturday becomes a Room
Opening the Card gives the visible item durable depth. Stage can hold Saturday-path brief: Place permit, generator status, and downtown / wedding / split options on one page. Chat keeps the request and response beside that artifact instead of in a detached thread. Pulse can show “Open decision: Sam will choose that Saturday’s work.” Activity can preserve this attributed receipt: “Ava compared the options in Card Chat using the Saturday-path brief and this Card Room's visible notes and left “Choose the wedding Saturday” with Sam.”
A useful Card Chat request would be: “Using only the context visible in this Card Room, compare keeping downtown, taking the wedding, and splitting the day if repaired. Do not contact the planner or choose for me.” 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.
Sam's call remains explicit: Sam chooses the event, talks to the planner and city, and owns food safety and spending.
| Surface | Job in this example |
|---|---|
| Stage | Saturday-path brief: Place permit, generator status, and downtown / wedding / split options on one page |
| Chat | Keep Sam's request and Ava's attributed response with the work |
| Pulse | Open decision: Sam will choose that Saturday’s work |
| Activity | Ava compared the options in Card Chat using the Saturday-path brief and this Card Room's visible notes and left “Choose the wedding Saturday” with Sam |
What to ask Ava—and what not to assume
These requests use the visible supported context inside the “Choose the wedding Saturday” Card Room. They do not imply that current Ava automatically surveys the whole Board or follows up on her own; Sam 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 Sam, watch other Lists, or act outside this Card Room.
Sam owns bookings, permits, food safety, and repairs. Ava does not apply for permits, contact planners, or cook.
A Saturday that is only one Saturday: the generator warning is on the Board, the permit is attached to a date, and the wedding is a yes or no.
- Request idea: using only the context visible in this Card Room, compare keeping downtown, taking the wedding, and splitting the day if repaired. Do not contact the planner or choose for me.
- Request idea: use only the Saturday-path 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 cab folder of permits plus email may still be enough
A cab folder of permits plus email is enough when one weekly pitch and a healthy generator.
It starts to break when a wedding, a downtown permit, and a warning light all claim Saturday.
The Event season Saturdays Board earns its place only when the familiar tool—a cab folder of permits plus email—can no longer keep the reason, Saturday-path brief, conversation, current state, decision, and history connected.
A starter recipe to adapt, not obey
Sam should rename every List or Card that feels artificial. This recipe succeeds when “Choose the wedding Saturday” becomes easier to decide and fewer open loops depend on memory—not when the Board looks tidy.
| Step | Action |
|---|---|
| 1. Card each Saturday | Place and permit on the date |
| 2. Put the truck on the Board | Generator, people, stock |
| 3. Attach menus to sites | What that event actually allows |
| 4. Request repair evidence | The quote request stays owned until sent; permits stay attached to Saturdays |
| 5. Choose the wedding Saturday | Open a Room when two events share a truck |
Direction
Direction, not a current promise
Later, Ava may help this Board notice when two Saturday Cards share a date, still leaving every booking with Sam.
A future unified You.one experience could carry relevant context from “Choose the wedding Saturday” 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.
What this realistic example does not claim
- Sam is fictional and is not a customer, testimonial, research participant, or disguised real person.
- This is not food-safety, permitting, or mechanical advice.
- It does not show Ava applying for permits or contacting event staff.
- It is not a measured sales result.