{ "schema_version": 1, "updated_at": "2026-09-15", "canonical_id": "brali:problem:prevent-recurring-errors", "slug": "prevent-recurring-errors", "acquisition_cluster_id": "prevent-recurring-errors", "title": "Reduce preventable mistakes in recurring work", "question": "How do I stop the same type of work mistake from happening again?", "aliases": [ "stop making the same work mistakes", "reduce errors in a recurring process", "find why a repeated mistake keeps happening" ], "summary": "Turn a repeated mistake into an observable hypothesis, make the handoff or decision point clearer, and test a small process change before standardizing it.", "canonical_url": "https://brali-lifeos.github.io/problems/prevent-recurring-errors/", "json_url": "https://brali-lifeos.github.io/problems/prevent-recurring-errors/index.json", "query_url": "/for-ai/query/?q=I%20keep%20making%20the%20same%20work%20mistake.%20How%20can%20I%20find%20the%20cause%20and%20change%20the%20process%3F", "related_url": "/life-os/areas/work-money-strategy/", "topics": [ { "id": "error-prevention", "title": "Error Prevention", "canonical_id": "brali:topic:error-prevention" }, { "id": "work-systems", "title": "Work Systems", "canonical_id": "brali:topic:work-systems" } ], "related_topics": [ { "id": "critical-thinking", "title": "Critical Thinking", "canonical_id": "brali:topic:critical-thinking" }, { "id": "clear-communication", "title": "Clear Communication", "canonical_id": "brali:topic:clear-communication" } ], "decision_path": [ { "if": "You do not know where the error enters", "try": "State one testable explanation and identify the observation that would support or weaken it." }, { "if": "The error appears at a handoff", "try": "Check whether action, ownership, timing, location, reason, or process information is genuinely missing." }, { "if": "You have two plausible low-risk process changes", "try": "Compare them against one observable error or completion signal before standardizing either one." } ], "stop_rule": "When errors are safety-critical, regulated, security-sensitive, financial, medical, or otherwise consequential, use the required formal controls and qualified review rather than treating a lightweight self-experiment as sufficient.", "protocols": [ { "canonical_id": "brali:protocol:start-with-a-hypothesis", "slug": "start-with-a-hypothesis", "url": "https://brali-lifeos.github.io/life-os/start-with-a-hypothesis/", "title": "When Faced with a Problem, Start by Making an Educated Guess About the Cause", "description": "When faced with a problem, start by making an educated guess about the cause. Write down your hypothesis and what you expect to happen if it’s true.", "action": "When a work problem is unclear, write one plausible explanation, state what you would expect to observe if it were true, run the smallest safe check that could change your mind, and update the hypothesis from the result.", "check_in": "What did I expect to observe, what actually happened, and what changed in my explanation after the test?", "evidence": { "status": "practical", "source_recorded": false, "source_url": null, "reviewed_at": "2026-08-18" }, "topic_ids": [ "problem-solving", "critical-thinking" ], "is_flagship_100": true, "fit": "best-fit", "when": "The same failure repeats but the mechanism is still unclear and can be investigated safely.", "why": "The protocol converts a vague explanation into a prediction and a reversible check, which is more informative than cycling through fixes without a model.", "caveat": "A small check can update a hypothesis but does not prove causality, especially in complex or consequential systems.", "gold_review": { "reviewed_at": "2026-09-15", "review_status": "gold-ready", "first_action": "Write the observable problem separately from your explanation, then write one plausible hypothesis and one concrete pattern you would expect to see if it were useful.", "observable_signal": "Whether the problem, hypothesis, prediction, and observation were kept distinct and whether the result actually caused the explanation or next check to change when evidence disagreed.", "eligibility": [ "The problem can be described through observable facts and at least one plausible explanation can be checked without creating disproportionate risk.", "The user can state a prediction that would differ depending on whether the hypothesis is useful.", "A small reversible check, sample, comparison, log inspection, or safe reproduction can meaningfully update the explanation." ], "when_not_to_use": [ "Do not experiment casually on production, people, finances, safety, security, health, legal obligations, or other consequential systems when the test itself could create material harm.", "Do not treat the first plausible explanation as a conclusion; a hypothesis should make it easier to notice disconfirming evidence, not rationalize it away.", "Do not infer causality from a tiny exploratory check when the final decision requires stronger validation, controls, expert review, or a formal incident process." ], "evidence_boundary": { "status": "practical", "statement": "This is a practical reasoning and troubleshooting template. Brali does not currently attach reviewed evidence claiming that this exact sequence reduces incident time, improves diagnosis by a predictable amount, or provides a statistical test of causality.", "source_decision_ids": [] } } }, { "canonical_id": "brali:protocol:5w1h-communication-checklist", "slug": "5w1h-communication-checklist", "url": "https://brali-lifeos.github.io/life-os/5w1h-communication-checklist/", "title": "Check Who, What, Where, When, Why, and How", "description": "Before an important operational message, check whether the reader has the people, action, place, timing, reason, and next-step details they actually need.", "action": "Review an important operational message using six questions: Who? What? Where? When? Why? How? Add only the missing details the reader needs to act, then send the shortest version that is still clear.", "check_in": "Could the reader act without guessing, and did I include any detail that was unnecessary or sensitive?", "evidence": { "status": "practical", "source_recorded": false, "source_url": null, "reviewed_at": "2026-08-18" }, "topic_ids": [ "clear-communication" ], "is_flagship_100": true, "fit": "alternative", "when": "The recurring mistake is caused by missing or ambiguous operational context at a message or handoff.", "why": "It checks the specific information needed to act without guessing while encouraging removal of unnecessary detail.", "caveat": "Checklist completion does not prove the underlying facts are correct or that the recipient understood them.", "gold_review": { "reviewed_at": "2026-09-15", "review_status": "gold-ready", "first_action": "Write the action or outcome the reader needs first, then scan Who, What, Where, When, Why, and How and add only the missing details required to act without guessing.", "observable_signal": "Whether the recipient could identify the action, owner, relevant timing or location, and next step without avoidable clarification, while unnecessary or sensitive details stayed out.", "eligibility": [ "The message carries an operational request, handoff, meeting detail, decision, or other information where missing context could create delay or avoidable follow-up.", "The sender can identify the reader's actual next action and add only details required to make that action clear.", "Sensitive information can be omitted or moved to an appropriate channel rather than included merely to satisfy a checklist." ], "when_not_to_use": [ "Do not force all six labels into every message when shared context already makes some answers obvious.", "Do not add private, confidential, security-sensitive, or otherwise inappropriate detail merely to make the checklist look complete.", "Do not treat 5W1H as proof that a message is correct, persuasive, legally sufficient, or understood by the recipient." ], "evidence_boundary": { "status": "practical", "statement": "This is an operational clarity checklist. Brali does not attach reviewed evidence that the six questions, this order, or this message format produces a predictable improvement in communication outcomes.", "source_decision_ids": [] } } }, { "canonical_id": "brali:protocol:ab-test-learning-loop", "slug": "ab-test-learning-loop", "url": "https://brali-lifeos.github.io/life-os/ab-test-learning-loop/", "title": "Compare Two Approaches and Learn From the Result", "description": "When a decision is reversible, compare two approaches around one clear question, keep the outcome you care about visible, and avoid treating a tiny informal comparison as statistical proof.", "action": "Choose one reversible decision, define what you want to learn, compare two approaches as fairly as you can, and record the outcome before deciding what to try next. Use proper experimental design when the result needs statistical confidence.", "check_in": "What changed between the two approaches, what outcome did I observe, and is the evidence strong enough to act or only strong enough to suggest another test?", "evidence": { "status": "practical", "source_recorded": false, "source_url": null, "reviewed_at": "2026-08-18" }, "topic_ids": [ "problem-solving", "decision-making", "data-literacy" ], "is_flagship_100": true, "fit": "alternative", "when": "Two safe reversible process changes can be compared and one relevant outcome can be declared before observing results.", "why": "A bounded compare-and-learn loop can tell you whether one local change is promising enough for the next reversible step.", "caveat": "Do not call an informal small comparison statistically conclusive or use it for high-stakes changes without the design and approvals those changes require.", "gold_review": { "reviewed_at": "2026-09-15", "review_status": "gold-ready", "first_action": "Choose one reversible decision, write what you want to learn and the outcome you will inspect, then define versions A and B so one main difference is visible.", "observable_signal": "Whether the question and outcome were defined in advance, one main difference was interpretable, the observed result was recorded honestly, and the user can distinguish a tentative signal from stronger evidence.", "eligibility": [ "The decision is reversible or low-risk enough that trying two approaches does not create disproportionate harm.", "The user can state one clear question and one outcome that matters before observing the result.", "The comparison can keep major surrounding conditions reasonably similar or can explicitly record when they differ." ], "when_not_to_use": [ "Do not run informal experiments on people, production systems, health, safety, security, finances, legal obligations, privacy, or other consequential settings when the test itself can create material harm or requires approval.", "Do not call a small uncontrolled comparison a randomized A/B test or use it to claim statistical confidence, causality, or generalizability.", "Do not change the outcome measure after seeing which version looks better without clearly marking the analysis as exploratory." ], "evidence_boundary": { "status": "practical", "statement": "This is a practical compare-and-learn template. Brali does not claim that an informal two-version comparison establishes causality, statistical significance, a generalizable winner, or an evidence-backed optimal test design.", "source_decision_ids": [] } } } ], "answer_packet": { "schema_version": 1, "canonical_id": "brali:problem:prevent-recurring-errors", "problem": "How do I stop the same type of work mistake from happening again?", "canonical_url": "https://brali-lifeos.github.io/problems/prevent-recurring-errors/", "best_fit": { "canonical_id": "brali:protocol:start-with-a-hypothesis", "slug": "start-with-a-hypothesis", "title": "When Faced with a Problem, Start by Making an Educated Guess About the Cause", "when": "The same failure repeats but the mechanism is still unclear and can be investigated safely.", "why": "The protocol converts a vague explanation into a prediction and a reversible check, which is more informative than cycling through fixes without a model.", "caveat": "A small check can update a hypothesis but does not prove causality, especially in complex or consequential systems.", "first_action": "Write the observable problem separately from your explanation, then write one plausible hypothesis and one concrete pattern you would expect to see if it were useful.", "evidence_state": "practical" }, "alternatives": [ { "canonical_id": "brali:protocol:5w1h-communication-checklist", "slug": "5w1h-communication-checklist", "title": "Check Who, What, Where, When, Why, and How", "when": "The recurring mistake is caused by missing or ambiguous operational context at a message or handoff.", "why": "It checks the specific information needed to act without guessing while encouraging removal of unnecessary detail.", "caveat": "Checklist completion does not prove the underlying facts are correct or that the recipient understood them.", "first_action": "Write the action or outcome the reader needs first, then scan Who, What, Where, When, Why, and How and add only the missing details required to act without guessing.", "evidence_state": "practical" }, { "canonical_id": "brali:protocol:ab-test-learning-loop", "slug": "ab-test-learning-loop", "title": "Compare Two Approaches and Learn From the Result", "when": "Two safe reversible process changes can be compared and one relevant outcome can be declared before observing results.", "why": "A bounded compare-and-learn loop can tell you whether one local change is promising enough for the next reversible step.", "caveat": "Do not call an informal small comparison statistically conclusive or use it for high-stakes changes without the design and approvals those changes require.", "first_action": "Choose one reversible decision, write what you want to learn and the outcome you will inspect, then define versions A and B so one main difference is visible.", "evidence_state": "practical" } ], "stop_rule": "When errors are safety-critical, regulated, security-sensitive, financial, medical, or otherwise consequential, use the required formal controls and qualified review rather than treating a lightweight self-experiment as sufficient." }, "evidence_decisions": [ { "id": "ai-review-correction-friction-boundary-2026", "decision": "propose-protocol", "reviewed_at": "2026-08-29", "source_title": "Bias in the Loop: How Humans Evaluate AI-Generated Suggestions", "source_url": "https://hdsr.mitpress.mit.edu/pub/nrcn4h7d/release/2", "supported_claim": "When humans review AI-generated suggestions, the review interface itself can bias behavior. In this experiment, adding repair work to the act of rejecting an AI suggestion reduced correction activity and increased undercorrection. Brali can therefore justify a bounded workflow rule: make it cheap to flag or reject an AI output, and separate validation from repair when the repair burden would otherwise make acceptance the path of least resistance.", "unsupported_or_overstated_claims": [ "Making correction easier will always increase overall accuracy.", "People who distrust AI are universally better reviewers.", "Performance bonuses cannot improve AI review in other settings.", "The same effect size applies to expert, medical, legal, financial, or safety-critical review.", "A human-in-the-loop label by itself guarantees reliable oversight.", "AI suggestions should be hidden from reviewers." ], "limitations": [ "The experiment used crowdworkers rather than domain experts.", "The task was limited to ten greenhouse-gas reporting tables and one pre-annotation workflow.", "Several difficult items required domain knowledge that many annotators lacked.", "The randomized correction-burden manipulation changed correction behavior, but the regression analysis did not show a clear overall accuracy loss because overcorrections also decreased.", "AI attitudes predicted behavior observationally rather than through randomized manipulation.", "The study did not include a no-AI baseline and could not analyze item-order effects." ] }, { "id": "ai-structured-intake-human-judgment-boundary-2026", "decision": "propose-protocol", "reviewed_at": "2026-08-29", "source_title": "Voice AI in Firms: A Natural Field Experiment on Automated Job Interviews", "source_url": "https://arxiv.org/html/2607.28222", "supported_claim": "A defensible way to divide some repetitive high-volume workflows is to automate structured information collection while keeping consequential evaluation with a human. In this field experiment, that division improved several downstream hiring outcomes without a measured decline in worker productivity. Transcript evidence is consistent with greater standardization and comparability as a mechanism, but does not prove that mechanism independently. Brali should treat this as a task-allocation pattern to test, not as evidence that AI should make final hiring or other high-stakes decisions.", "unsupported_or_overstated_claims": [ "AI interviewers are generally better than human interviewers.", "AI should make final hiring decisions.", "The result generalizes to specialized, relationship-heavy, tacit-knowledge, executive, clinical, legal, or other high-stakes work.", "Automating information collection removes discrimination or guarantees fairness.", "The same voice-AI system will produce the same results in other firms, languages, cultures, or labor markets.", "Human oversight automatically prevents automation bias.", "The controlled-variance mechanism is causally proven by the experiment." ], "limitations": [ "The source is a working paper rather than a peer-reviewed journal article.", "The experiment was conducted with one recruitment-process outsourcing firm and entry-level customer-service hiring in the Philippines.", "Five percent of AI interviews ended because applicants were unwilling to continue with AI and seven percent experienced technical failure.", "The transcript-based mechanism analysis is associative even though interviewer assignment was randomized.", "The candidate-experience survey had a low response rate and may not represent all applicants.", "Applicants who were allowed to choose showed negative sorting into AI, limiting interpretation of the choice condition.", "Employment selection has legal, fairness, accessibility, and accountability requirements that this study does not resolve." ] }, { "id": "communication-coaching-reflective-statements-boundary-2023", "decision": "challenge-existing", "reviewed_at": "2026-08-22", "source_title": "Effect of a Coaching Intervention to Improve Cardiologist Communication: A Randomized Clinical Trial", "source_url": "https://doi.org/10.1001/jamainternmed.2023.0629", "supported_claim": "A multicomponent individual coaching program changed some observed cardiologist communication behaviors, particularly empathic responses and eliciting patient questions. Reflective statements and open-ended questions were explicit trained components, but the intervention did not significantly increase either behavior relative to control. This source is therefore a boundary against claiming that training the Brali sequence by itself has demonstrated communication or patient-outcome effects.", "unsupported_or_overstated_claims": [ "The coaching trial shows that paraphrasing or reflective statements alone improved.", "The Brali sequence of paraphrase, correction and one open question is equivalent to the five-component WISER intervention.", "Active listening improved patient understanding, trust, satisfaction or clinical outcomes in this trial.", "Open-ended questions increased because of the coaching intervention.", "A single conversational attempt is equivalent to three individual coaching sessions with tailored feedback.", "The findings generalize directly from cardiology encounters to ordinary work, family, conflict or digital conversations.", "Patient self-reports confirmed an effect; ceiling effects prevented the planned arm comparison.", "Positive clinician opinions about the coaching demonstrate objective effectiveness of each component." ], "limitations": [ "Five communication skills were trained together, so any observed effect cannot be attributed to paraphrasing or open questions independently.", "There was no significant intervention-versus-control difference in reflective statements or open-ended questions.", "Patient-perceived communication and trust effects could not be assessed because scores had substantial ceiling effects.", "The sample included mostly White male cardiologists in an academic setting and many had prior communication training, limiting generalizability.", "Pre- and post-intervention patient samples were different rather than repeated measures on the same patients.", "The intervention required repeated one-to-one coaching and feedback, so it does not test a self-guided protocol used once.", "Clinical and longer-term outcomes were not established." ] } ], "trust_note": "Recommendations come only from protocols that are both trusted in the Brali Protocol Feed and manually Gold-ready. The problem-to-protocol fit is editorial decision logic; it is not a claim that one sequence is universally best." }