Skip to content

Example

How to launch a community repair café without promising every object can be saved

Unknown appliances are arriving for a room with limited outlets before the venue has confirmed what volunteers may safely handle.

AI assistance helped shape this fictional example from a structured editorial brief. It was reviewed for usefulness, distinctness, accessibility, and product truth.

Superboard exampleRepair café pilot

Run a useful first event with explicit intake, safe limits, and learning even when an item is not repaired

Community promise1

The result Nikhil is trying to create—not every possible task

Promise safe learning and honest intake, not repair for every object

Hold the mission and boundary: run a useful first event with explicit intake, safe limits, and learning even when an item is not repaired

Pilot actions3

The current choice, preparation, and other owned next moves

Accept appliances, restrict to textiles and simple electronics, or use inspection-only intake

Hold the live choice—whether to accept appliances, restrict the pilot to textiles and simple electronics, or use inspection-only intake—so Nikhil can decide from the evidence in this Room

Draft the intake limits

Prepare the next owned move without treating a draft, check, or test as evidence that anyone has agreed

List item categories without safe volunteer coverage

Use the result of the first owned action to update the Pilot-scope brief; record the finding, not merely the effort

Readiness evidence3

Evidence for the live choice, drawn from the situation's actual sources

Skills: textiles 6, simple electronics 4, other or unconfirmed 5, appliances 0 confirmed

Keep confirmed skills beside appliance intake so the pilot is scoped to what volunteers can actually handle, not to what residents might bring

Room has limited outlets

Keep electrical capacity beside the appliance option

Residents are bringing unknown appliances

Make the present intake fact visible before public scope is chosen

Waiting on venue1

The already-requested venue safety-limits reply

Venue safety-limits reply

Record who owns the answer, what was asked, and that venue safety-limits reply is still unconfirmed

An illustrative Board built from this fictional scenario. Adapt the Lists and Cards to your own mission.
01

Nikhil is an explicitly fictional portrait, not a customer or testimonial.

02

The Repair café pilot Board gives one mission a visible field; the Accept appliances, restrict to textiles and simple electronics, or use inspection-only intake Room keeps its evidence, conversation, state, and decision together.

03

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 Repair café pilot needs an operating picture

Nikhil is a fictional 38-year-old makerspace volunteer launching a repair event in Toronto, Ontario. Fifteen volunteers offer different skills, the room has limited outlets, residents are bringing unknown appliances, and Nikhil has already requested the venue's safety limits.

Fifteen volunteers offer useful but different skills while residents are bringing appliances nobody has agreed to handle.

Limited outlets and an unanswered venue safety boundary make broad public intake a risk, not a generous default.

In You.one's Superboard view, Nikhil can give “Run a useful first event with explicit intake, safe limits, and learning even when an item is not repaired” a Board of its own. That Board connects community promises, volunteer capacity, local evidence, and human authority; opening “Accept appliances, restrict to textiles and simple electronics, or use inspection-only intake” creates a Room for its evidence, discussion, state, and decision.

Repair café pilot has one live choice: Accept appliances, restrict to textiles and simple electronics, or use inspection-only intake

The mission is specific: Run a useful first event with explicit intake, safe limits, and learning even when an item is not repaired.

The consequential choice is not something a board or an AI should quietly make: Whether to accept appliances, restrict the pilot to textiles and simple electronics, or use inspection-only intake.

You.one can keep the work, evidence, live dependency, and “Accept appliances, restrict to textiles and simple electronics, or use inspection-only intake” decision visible through its Superboard view. The Owner boundary stays explicit: Nikhil owns the intake-scope recommendation and public promise. The venue owns its safety limits, and qualified people own electrical and repair safety; Ava cannot contact the venue or approve appliances.

Available today

Repair café pilot: one Board shape to adapt

The Repair café pilot Board gives this mission one durable operating picture. Nikhil 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, 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.

Repair café pilot Board shape
ListWhat belongs here
Community promiseThe result Nikhil is trying to create—not every possible task
Pilot actionsThe current choice, preparation, and other owned next moves
Readiness evidenceEvidence for the live choice, drawn from the situation's actual sources
Waiting on venueThe already-requested venue safety-limits reply

Available today

The Cards make the operating picture concrete

These Card titles come directly from Nikhil's situation: “Accept appliances, restrict to textiles and simple electronics, or use inspection-only intake” is the live choice, “Skills: textiles 6, simple electronics 4, other or unconfirmed 5, appliances 0 confirmed” holds evidence, and “Venue safety-limits reply” names something genuinely in motion outside Nikhil's control. The point is recognition, not a perfect taxonomy.

Example Cards for Nikhil
CardListJob
Promise safe learning and honest intake, not repair for every objectCommunity promiseHold the mission and boundary: run a useful first event with explicit intake, safe limits, and learning even when an item is not repaired
Accept appliances, restrict to textiles and simple electronics, or use inspection-only intakePilot actionsHold the live choice—whether to accept appliances, restrict the pilot to textiles and simple electronics, or use inspection-only intake—so Nikhil can decide from the evidence in this Room
Skills: textiles 6, simple electronics 4, other or unconfirmed 5, appliances 0 confirmedReadiness evidenceKeep confirmed skills beside appliance intake so the pilot is scoped to what volunteers can actually handle, not to what residents might bring
Draft the intake limitsPilot actionsPrepare the next owned move without treating a draft, check, or test as evidence that anyone has agreed
Venue safety-limits replyWaiting on venueRecord who owns the answer, what was asked, and that venue safety-limits reply is still unconfirmed
List item categories without safe volunteer coveragePilot actionsUse the result of the first owned action to update the Pilot-scope brief; record the finding, not merely the effort
Room has limited outletsReadiness evidenceKeep electrical capacity beside the appliance option
Residents are bringing unknown appliancesReadiness evidenceMake the present intake fact visible before public scope is chosen

Available today

Available today: Accept appliances, restrict to textiles and simple electronics, or use inspection-only intake becomes a Room

Opening the Card gives the visible item durable depth. Stage can hold Pilot-scope brief: Place skills, equipment, item uncertainty, venue limits, and public expectation together. Live choice: Whether to accept appliances, restrict the pilot to textiles and simple electronics, or use inspection-only intake.. Chat keeps the request and response beside that artifact instead of in a detached thread. Pulse can show “Open decision: Nikhil will decide whether to accept appliances, restrict the pilot to textiles and simple electronics, or use inspection-only intake.” Activity can preserve this attributed receipt: “Ava compared the options in Card Chat using the Pilot-scope brief and this Card Room's visible notes and left “Accept appliances, restrict to textiles and simple electronics, or use inspection-only intake” with Nikhil.”

A useful Card Chat request would be: “Using only the context visible in this Card Room, compare accepting appliances, restricting the pilot to textiles and simple electronics, and inspection-only intake. Cite only notes visible in this Room. Do not contact the venue, volunteers, or residents, approve appliances, publish intake limits, 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.

Nikhil's call remains explicit: Nikhil owns the intake-scope recommendation and public promise. The venue owns its safety limits, and qualified people own electrical and repair safety; Ava cannot contact the venue or approve appliances.

Inside the Accept appliances, restrict to textiles and simple electronics, or use inspection-only intake Room
SurfaceJob in this example
StagePilot-scope brief: Place skills, equipment, item uncertainty, venue limits, and public expectation together. Live choice: Whether to accept appliances, restrict the pilot to textiles and simple electronics, or use inspection-only intake.
ChatKeep Nikhil's request and Ava's attributed response with the work
PulseOpen decision: Nikhil will decide whether to accept appliances, restrict the pilot to textiles and simple electronics, or use inspection-only intake
ActivityAva compared the options in Card Chat using the Pilot-scope brief and this Card Room's visible notes and left “Accept appliances, restrict to textiles and simple electronics, or use inspection-only intake” with Nikhil

What to ask Ava—and what not to assume

These requests use the visible supported context inside the “Accept appliances, restrict to textiles and simple electronics, or use inspection-only intake” Card Room. They do not imply that current Ava automatically surveys the whole Board or follows up on her own; Nikhil 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 Nikhil, watch other Lists, or act outside this Card Room.

Nikhil owns the intake-scope recommendation and public promise. The venue owns its safety limits, and qualified people own electrical and repair safety; Ava cannot contact the venue or approve appliances.

Nikhil finishes “List item categories without safe volunteer coverage,” keeps “Skills: textiles 6, simple electronics 4, other or unconfirmed 5, appliances 0 confirmed” beside “Accept appliances, restrict to textiles and simple electronics, or use inspection-only intake,” and does not treat “Venue safety-limits reply” as resolved before the outside answer arrives.

  • Request idea: using only the context visible in this Card Room, compare accepting appliances, restricting the pilot to textiles and simple electronics, and inspection-only intake. Cite only notes visible in this Room. Do not contact the venue, volunteers, or residents, approve appliances, publish intake limits, or choose for me.
  • Request idea: use only the Pilot-scope 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 volunteer signup sheet may still be enough

A volunteer signup sheet is enough when venue limits are set and public intake already matches the volunteers' actual skills.

It starts to break when “Skills: textiles 6, simple electronics 4, other or unconfirmed 5, appliances 0 confirmed” and “Venue safety-limits reply” must inform the same choice.

The Repair café pilot Board earns its place only when the familiar tool—a volunteer signup sheet—can no longer keep the reason, Pilot-scope brief, conversation, current state, decision, and history connected.

A starter recipe to adapt, not obey

Nikhil should rename every List or Card that feels artificial. This recipe succeeds when “Accept appliances, restrict to textiles and simple electronics, or use inspection-only intake” becomes easier to decide and fewer open loops depend on memory—not when the Board looks tidy.

Start with the Repair café pilot Board
StepAction
1. Write the missionRun a useful first event with explicit intake, safe limits, and learning even when an item is not repaired
2. Open the live choicePut “Accept appliances, restrict to textiles and simple electronics, or use inspection-only intake” in a Room of its own
3. Attach the evidencePilot-scope brief: Place skills, equipment, item uncertainty, venue limits, and public expectation together. Live choice: Whether to accept appliances, restrict the pilot to textiles and simple electronics, or use inspection-only intake.
4. Name the live dependencyKeep “Venue safety-limits reply” visibly waiting
5. Take the first owned actionList item categories without safe volunteer coverage

Direction

Direction, not a current promise

Over time, Ava may connect a change in “Venue safety-limits reply” with the Pilot-scope brief, summarize what moved inside “Accept appliances, restrict to textiles and simple electronics, or use inspection-only intake,” and stop before the named Owner decides.

A future unified You.one experience could carry relevant context from “Accept appliances, restrict to textiles and simple electronics, or use inspection-only intake” 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

  • Nikhil is fictional and is not a customer, testimonial, research participant, or disguised real person.
  • This fictional example is not electrical, tool, repair, insurance, or event-safety advice; qualified people set and enforce the actual safety boundary.
  • It does not show Ava completing external actions or contacting anyone for Nikhil.
  • It does not report a measured result, and this Board is a starting shape to adapt—not a universal prescription.

Use this example as a starting shape—not a claim about your life.

Get early access