Example
How to run an incident learning review without writing a blame timeline
A complete timeline can still teach the wrong lesson. Miguel must recommend whether alert design, deployment control, or on-call decision support receives the first repair while accountable owners retain implementation and verification authority.
Create a review that explains conditions, decisions, and system changes without assigning hindsight personalities
System learning and user impact without assigning hindsight personalities
Keep system learning and user impact as the review promise, without assigning hindsight personalities
Alert-design, deployment-control, and on-call-support repairs Miguel can compare
Compare alert design, deployment control, and on-call decision support as the first repair
Connect every repair option to an observed condition and a user impact
The forty-three-minute sequence, ignored-alert conditions, and user impact behind each repair path
Keep the forty-three-minute sequence as evidence, not a blame record
Rewrite why-did-they questions around the conditions that made each local choice reasonable
Preserve the local conditions that hindsight would erase
Keep repair priority connected to what users could not do
Show the evidence behind the deployment-control path
Show the evidence behind the on-call support path
Questions for accountable repair owners, kept unsent until Miguel chooses the first repair
Draft questions for accountable repair owners without assigning their commitments
In You.one's Superboard view, the Incident to learning Board separates the learning promise, repairs to test, event evidence, questions for accountable repair owners, and only changes those owners have actually verified.
Open Choose first repair: alert design, deployment control, or on-call decision support as the consequential Card Room. Start by rewriting every why-did-they question as what made that local choice reasonable at the time.
After an explicit request, Ava can compare only visible conditions, impacts, and repair evidence or draft a source-bound question set Miguel reviews. Ava cannot assign blame, write the review as fact, contact teams, assign repairs, approve deployment or alert changes, or declare a repair verified; Miguel facilitates and recommends, while named owners decide and implement.
A complete timeline is not learning if it only records what people did wrong
The work has a clear center: Create a review that explains conditions, decisions, and system changes without assigning hindsight personalities.
Organizing the evidence does not authorize the software to decide: Whether the first repair addresses alert design, deployment control, or on-call decision support.
You.one can keep the work, evidence, and “Choose first repair: alert design, deployment control, or on-call decision support” decision visible through its Superboard view. Authority does not move to the software: Miguel owns facilitation, evidence integrity, and the review recommendation. The named repair owners control implementation permissions and commitments.
Available today
Name the work in plain language
These Card titles come directly from Miguel's situation: “Choose first repair: alert design, deployment control, or on-call decision support” is the live choice, “Forty-three-minute timeline” holds evidence, and “Draft the repair-owner questions” is still work Miguel controls—not something already awaiting another person. The point is recognition, not a perfect taxonomy.
Swipe or scroll sideways to see every column.
| Card | List | Job |
|---|---|---|
| Explain why reasonable actions combined badly; the forty-three-minute timeline is not a blame record | Learning promise | Keep system learning and user impact as the review promise, without assigning hindsight personalities |
| Choose first repair: alert design, deployment control, or on-call decision support | Repairs to test | Compare alert design, deployment control, and on-call decision support as the first repair |
| Forty-three-minute timeline | Event evidence | Keep the forty-three-minute sequence as evidence, not a blame record |
| Connect each repair option to one observed condition and one user impact | Repairs to test | Connect every repair option to an observed condition and a user impact |
| Draft the repair-owner questions | Questions for accountable repair owners | Draft questions for accountable repair owners without assigning their commitments |
| Rewrite each why-did-they question as what-made-that-reasonable | Event evidence | Rewrite why-did-they questions around the conditions that made each local choice reasonable |
| Two ignored alerts and why each looked reasonable | Event evidence | Preserve the local conditions that hindsight would erase |
| User impact during the forty-three-minute outage | Event evidence | Keep repair priority connected to what users could not do |
| Deployment-control condition at the trigger | Event evidence | Show the evidence behind the deployment-control path |
| On-call decision-support gap | Event evidence | Show the evidence behind the on-call support path |
Available today
Incident to learning: separate the kinds of attention
The Incident to learning Board gives this mission one durable operating picture. Miguel 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.
The Lists use Miguel's own language so actions, evidence, open questions, and decisions do not collapse into one queue. A separate place for replies is useful only after Miguel has asked someone or a real outside event must happen first.
Swipe or scroll sideways to see every column.
| List | What belongs here |
|---|---|
| Learning promise | System learning and user impact without assigning hindsight personalities |
| Repairs to test | Alert-design, deployment-control, and on-call-support repairs Miguel can compare |
| Event evidence | The forty-three-minute sequence, ignored-alert conditions, and user impact behind each repair path |
| Questions for accountable repair owners | Questions for accountable repair owners, kept unsent until Miguel chooses the first repair |
Ask Ava to prepare the judgment—not make it
These requests stay with the facts Miguel has made visible around “Choose first repair: alert design, deployment control, or on-call decision support.” Miguel supplies the evidence, checks Ava's work, and decides what belongs in the Room.
Current Ava can prepare help after an explicit request. She cannot make the choice, represent Miguel, watch other work on her own, or contact anyone.
Miguel owns facilitation, evidence integrity, and the review recommendation. The named repair owners control implementation permissions and commitments. Ava cannot assign repairs or declare a change verified.
A completed learning review that records why both ignored alerts looked reasonable, names the first repair as alert design, deployment control, or on-call decision support, and assigns implementation only through the accountable owners.
- Request idea: using only this Card Room, compare prioritizing alert design, deployment control, and on-call decision support. Cite only notes visible in this Room. Do not write the review, contact teams, assign repairs, or choose for me.
- Request idea: use only the Repair-priority brief and notes the Owner has placed in this Card Room to separate facts, assumptions, and unanswered questions
- Request idea: in “Choose first repair: alert design, deployment control, or on-call decision support,” group the visible evidence by option and leave the decision open
Available today
One Card Room for the consequential choice
Opening the Card gives the visible item durable depth. Stage can hold Repair-priority brief: Place event evidence, contributing conditions, user impact, repair leverage, and ownership together. Live choice: Whether the first repair addresses alert design, deployment control, or on-call decision support. Chat keeps the request and response beside that artifact instead of in a detached thread. Pulse can show “Open decision: Miguel will decide whether the first repair addresses alert design, deployment control, or on-call decision support.”
A Card Chat request can ask Ava to prepare the specific comparison or extraction in “Choose first repair: alert design, deployment control, or on-call decision support” from the visible evidence. Ava can work from the context Miguel deliberately brings into this Card, List, or Board; she cannot monitor the rest of life, contact anyone, or inherit the decision.
Miguel's call remains explicit: Miguel owns facilitation, evidence integrity, and the review recommendation. The named repair owners control implementation permissions and commitments.
Swipe or scroll sideways to see every column.
| Surface | Job in this example |
|---|---|
| Stage | Repair-priority brief: Place event evidence, contributing conditions, user impact, repair leverage, and ownership together. Live choice: Whether the first repair addresses alert design, deployment control, or on-call decision support |
| Chat | Keep Miguel's request and Ava's attributed response with the work |
| Pulse | Open decision: Miguel will decide whether the first repair addresses alert design, deployment control, or on-call decision support |
Build only enough Board to make the next decision
Miguel should rename every List or Card that feels artificial. This recipe succeeds when “Choose first repair: alert design, deployment control, or on-call decision support” becomes easier to decide and fewer open loops depend on memory—not when the Board looks tidy.
Swipe or scroll sideways to see every column.
| Step | Action |
|---|---|
| 1. Write the learning promise | Put system learning without hindsight personalities on Learning promise |
| 2. Card event evidence | Put the timeline, ignored-alert conditions, and user impact on Event evidence |
| 3. Keep owner questions unsent | Draft repair-owner questions on Owner questions |
| 4. Rewrite the hindsight questions | Ask what made each choice reasonable and keep the result on Event evidence |
| 5. Choose the first repair | Open Choose first repair: alert design, deployment control, or on-call decision support |
Where this example stops
- This is a fictional example, not a customer story.
- This fictional example is not incident-response, security, reliability, employment, legal, or professional operations advice; the accountable team verifies the event and owns every repair.
- It does not show Ava completing external actions or contacting anyone for Miguel.
- It does not report a measured result, and this Board is a starting shape to adapt—not a universal prescription.