--- title: "How to correct a wrong claim you published or shared | Len P. van der Hof" description: Correct a wrong claim by fixing the source, telling the people who relied on it and addressing the consequences. With a worked example and a template. image: "https://lenvanderhof.com/media/generated/blog-hero-correction-vs-quiet-edit.72fe0095522b.wide.webp" --- [Venture Building](https://lenvanderhof.com/en/blog/category/venture-building/) Research guide # Correction vs quiet edit: who needs to hear what changed? Updating a page does not update a customer's plans. Follow the earlier claim to the people and decisions it reached. Len P. van der HofPublished 5 November 20269 min read The red ink is on this copy of the chart. Anyone sailing with an earlier copy still needs to hear what changed. Direct answer To correct something you published or told people that turned out wrong, fix the source and contact the people who relied on it. Tell them the earlier claim, what changed, what the evidence now supports and which decision to revisit, and address any cost the error caused. For a material public error, add a visible, dated correction. Edit quietly only when no meaning or decision changes. ## Key takeaways - Edit quietly only when the change leaves meaning and decisions intact. If it could change what someone decided, explain the correction and contact the affected people you know. - A useful correction names the old claim, the evidence behind the revision, the supported replacement and the action that follows. - You can correct unsupported certainty while the underlying question stays open. A correction need not reverse the conclusion. - Track three things separately: the corrected source, contact with affected people and the practical repair. A sent message does not show that a plan changed. **A quiet edit fixes the source; a correction tells the people who relied on the old claim what changed and what they need to reconsider.** If your claim shaped a decision, an accurate page is only part of the repair. Consider a hypothetical founder who publishes an onboarding guide and emails it to three customers. The guide says complete onboarding takes two working days. She later checks the pilot log: it timed file import alone, excluding preparation and staff training. She changes the guide to say that timings vary. One customer’s operations lead has already scheduled staff and plans to retire the old process on Monday. The page has changed. That plan has not. Chapter 5 of [The Evidence-Aware Life](https://lenvanderhof.com/books/the-evidence-aware-life/) joins the two responsibilities: revise the claim according to the evidence, then correct the record where others relied on it. For this founder, that means reaching the customer before the unsupported estimate becomes Monday’s instruction. ## When is a quiet edit enough? A **quiet edit** changes a source without explicitly notifying its earlier audience. A **correction** identifies an earlier error or overstatement, explains the revised position and communicates its implications to the people it affects. Use the effect on meaning to choose between them: ChangeSuitable responseFixing spelling or punctuation without changing the meaningA quiet edit is ordinarily enough.Correcting a figure, date, condition or attribution that could affect a decisionFix the source, explain the change and contact known affected people.Withdrawing a recommendation because its support no longer holdsCorrect the recommendation and identify the decisions that need reconsidering. Call a change **material** when it could alter what someone believes, repeats, commits to or does because of the claim. This is a practical test for ordinary business communication. It is not a universal publishing standard. A typo in a delivery date can be material if someone scheduled work around it. Calling it a typo describes how the error happened; it does not settle what the recipient needs now. Before saving, ask: *Would someone who acted on the earlier version need to reconsider anything?* If yes, plan the message alongside the edit. If the claim was public and you cannot identify its readers, leave a visible correction where they encountered it. ## How should you correct something you published or told people that turned out to be wrong? Use these six steps as a practical application of the book’s update protocol. 1. **Recover the exact claim.** Keep the earlier wording, where it appeared and when you shared it. Include any recommendation attached to it. Preserve enough of the original to show what someone could reasonably have taken from it. 2. **Check the reason for changing it.** Name the evidence and examine what it supports. Does it show that a fact was wrong, that a condition was omitted, or that you sounded more certain than the evidence allowed? Record the reason for the revision. 3. **Write the supported replacement.** Correct the fact, narrow the claim, reduce confidence or withdraw the recommendation as appropriate. Keep what remains supported. If you cannot give a reliable replacement estimate, say so. 4. **Repair the source visibly where it matters.** Put the revised account in the current document. For a material public error, add a dated correction identifying the earlier claim and the change. Do not hide the revision inside a new argument that leaves the old claim standing, or behind a bare “updated” label that leaves the reader to work out what happened. 5. **Contact the people affected.** Identify who received the claim, acted on it or passed it on. Use a channel suited to those people. Correct a private customer email in that same correspondence; for a public claim, keep a public correction as well as contacting the people whose reliance you know about. 6. **Address the consequence.** Say what should stop, change or be checked next. Give unfinished work an owner and a review point. If the error cost someone time or resources, address that consequence explicitly. The message itself can be short. Its recipient should be able to recognize the earlier claim, understand the revised one and see which decision needs attention. ## Worked example: correcting the two-day onboarding promise Return to the hypothetical founder. The pilot log records two working days for file import. It contains no timing for preparation or training. That supports a statement about one part of one pilot. It does not establish how long complete onboarding takes. The founder should therefore withdraw the complete-onboarding estimate. Replacing two days with three or five would introduce another unsupported figure. She corrects the guide and puts a dated note near the timing claim. A sample note: > **Correction [date]:** An earlier version of this guide described complete onboarding as taking two working days. That figure measured file import in one pilot and excluded preparation and training. We have withdrawn it as an estimate for complete onboarding. Please confirm the remaining tasks and schedule with us before setting a switch-over date. That repairs the public account. The operations lead also needs a direct message because the founder knows a decision is pending: > I told you that complete onboarding takes two working days. I should not have presented that as an established timeline. Our pilot log measured file import only; we do not yet have a supported estimate for the complete process. > > Please do not retire your old process on Monday based on my earlier estimate. I have corrected the guide and added a note explaining the change. I will review the remaining tasks with you tomorrow and send a proposed schedule for us to check before you commit staff to it. > > I am sorry my estimate led you to arrange work around that timeline. Please tell me what you have already booked so we can address the consequences. The people, log, timings and messages are invented to show the method. No customer response or successful repair is being reported. The distinction is now visible. “Onboarding times vary” changes the guide but gives the operations lead no reason to revisit Monday. The direct correction names that decision and offers a next step without pretending a reliable schedule already exists. The founder still needs to hear back, agree the plan and address work already booked. Those tasks remain open after the message is sent. ## What if the old claim is only partly wrong? Correct the part the evidence no longer supports. Chapter 5 lists the forms an update can take: adjusting a probability, narrowing the conditions under which you accept a claim, withdrawing a causal explanation, or reversing a conclusion after decisive evidence. Let the evidence set the size of the change. In the example, the file import took two days in the pilot. Keep that observation with its scope. Withdraw the jump from that observation to a promise about complete onboarding for other customers. The correction does not establish that onboarding always takes longer, or that the product fails. You can also correct an overstatement before resolving the underlying question. “I called this proven; the evidence I cited does not establish it” corrects the certainty you expressed. You do not need evidence that the opposite is true to withdraw an unsupported assertion. Chapter 5’s composite founder, Daniel, makes this move: he can stay uncertain about a growth channel’s eventual value while being clear that his earlier recommendation was too strong. Then examine the action that depended on the claim. If a decision must stay blocked, [HOLD is a research result](https://lenvanderhof.com/en/blog/hold-is-a-research-result/) shows how to record what is blocked, who owns the next check and what would reopen the decision. Send the correction now; do not wait for that work to finish. ## How far should the correction travel? Start with the original distribution, then follow the reliance you can identify. Check the email recipients, meeting attendees and shared slides. Ask known recipients whether they passed the claim on, when that matters to the repair. In the hypothetical example, all three customers received the guide, so all three need the correction. The customer with Monday’s switch-over needs particular attention. If a sales colleague used the same estimate in other conversations, include those recipients in the follow-up. Keep a small contact log. For each person or audience, record the affected decision, the message sent, any response and the remaining action. An unanswered message should stay visible as unanswered. If a decision is imminent, use another suitable channel and record the attempt. For public readers you cannot identify, put the correction on the source and share it through the original public channel where feasible. Be clear about the limits of that reach. Posting a notice does not establish who saw it. Fit the disclosure to the audience. Chapter 5 asks you to respect confidentiality and personal safety. You can correct a public estimate without publishing a customer’s private arrangements or exposing a colleague who raised a concern. A belief you kept private does not require a public announcement. ## What should the team record after a correction? Keep three questions separate: is the source corrected, have affected people been contacted, and has the practical consequence been addressed? Record the answer to each. Do not close a customer’s rescheduling task because the guide is now accurate. Chapter 10 adds a responsibility inside the team. When new information changes an assessment, revise the record instead of pretending the new position was always the team’s view. When a colleague raises a concern, acknowledge it, say who will examine it and return with an answer. A review should also distinguish an honest forecast that proved wrong from negligence, concealed information or repeated failure to carry out agreed work. Correcting the claim does not settle those separate questions. Nor does a correction show that trust has returned. In chapter 5’s composite example, Daniel sends his correction to the people who heard his original recommendation. One customer appreciates the explanation; his co-founder wants to know how the lost time will be recovered. Daniel adds a revised work plan and a review date. He has corrected the claim, and the chapter is plain that rebuilding confidence in the decision process takes more than that note. The reason to correct is that people need an accurate record, not that a correction guarantees applause. ## Try this today Find one claim you published or presented this year that you now believe is wrong. If nothing comes to mind, a [belief audit](https://lenvanderhof.com/en/blog/belief-audit-vs-fact-check/) has you write down the ten strongest beliefs guiding your work; check which of them you have also stated to customers, investors or your team. Retrieve the original wording and check the evidence for the revision. Then fill in this record: ``` Earlier claim, place and date: Evidence that changes it: Supported replacement and remaining uncertainty: People who acted on it: Decision each person needs to reconsider: Source correction and contact channel: Practical repair, owner and next review: ``` Draft the correction from those lines. Give it to a colleague without explaining what you meant. Ask them to identify the old claim, the revised claim and the decision they would reconsider. If any answer is unclear, revise the message. Working alone, compare it with the original recommendation and check that it addresses the action you asked someone to take. If the list has names and you have only edited the source, the correction has not happened yet. Contact the people you can identify, record the responses and leave unanswered follow-up open. Give the practical repair an owner. Cite this:Correction vs quiet edit: who needs to hear what changed?Len P. van der Hof. [https://lenvanderhof.com/en/blog/correction-vs-quiet-edit/](https://lenvanderhof.com/en/blog/correction-vs-quiet-edit/) · Published 5 November 2026. ## Sources 1. [The Evidence-Aware Life (chapters 5 and 10)](https://lenvanderhof.com/books/the-evidence-aware-life/) 2. [Belief audit vs fact-check: inspect the claims you already act on](https://lenvanderhof.com/en/blog/belief-audit-vs-fact-check/) 3. [HOLD is a research result, not an unfinished job](https://lenvanderhof.com/en/blog/hold-is-a-research-result/) ## Further reading - [Belief audit vs fact-check: inspect the claims you already act on](https://lenvanderhof.com/en/blog/belief-audit-vs-fact-check/) - [HOLD is a research result, not an unfinished job](https://lenvanderhof.com/en/blog/hold-is-a-research-result/) - [The Evidence-Aware Life](https://lenvanderhof.com/books/the-evidence-aware-life/) About the author ## [Len P. van der Hof](https://lenvanderhof.com/en/authors/len-p-van-der-hof/) Entrepreneur, AI Innovator and Venture Builder Len P. van der Hof builds practical AI systems, digital ventures and evidence-informed tools for founders. ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Person", "@id": "https://lenvanderhof.com/#person", "name": "Len P. van der Hof", "alternateName": [ "Len van der Hof", "L.P. van der Hof", "Leendert Pieter van der Hof" ], "honorificSuffix": "MSc", "url": "https://lenvanderhof.com/", "image": [ "https://lenvanderhof.com/photos/len-portrait-1.jpg", "https://lenvanderhof.com/photos/len-portrait-2.jpg", "https://lenvanderhof.com/photos/len-portrait-3.jpg", "https://lenvanderhof.com/photos/len-portrait-4.jpg", "https://lenvanderhof.com/photos/len-speaking.jpg", "https://lenvanderhof.com/photos/len-hero.jpg" ], "jobTitle": "Entrepreneur, AI Innovator and Venture Builder", "description": "Len P. van der Hof, MSc, is a Dutch entrepreneur and AI innovator in Zwijndrecht. He builds ReasonKit, MindSesh, Undominated.ai, books under his name, the fiction imprint LPH98.lifestyle, and technology ventures through LPH98.ventures. Eleven titles in Systems for the Strategic Self are available now, in English and Dutch.", "address": { "@type": "PostalAddress", "addressLocality": "Zwijndrecht", "addressCountry": "NL" }, "alumniOf": { "@type": "CollegeOrUniversity", "name": "Rotterdam School of Management, Erasmus University" }, "knowsAbout": [ "Artificial intelligence", "AI agents", "Agentic AI systems", "LLM routing", "SEO", "Generative engine optimization", "Answer engine optimization", "Venture building", "Founder performance", "Founder psychology", "Evidence-based decision-making" ], "sameAs": [ "https://www.linkedin.com/in/lenvanderhof/", "https://x.com/LenvanderHof", "https://www.youtube.com/channel/UCTG20buKqYYbitqqf7l3zJA", "https://www.instagram.com/Lenvanderhof/", "https://www.threads.com/@lenvanderhof", "https://github.com/Lenvanderhof", "https://huggingface.co/LPH98", "https://www.npmjs.com/~lenvanderhof", "https://www.goodreads.com/author/show/70983905.Len_P_van_der_Hof", "https://www.amazon.com/author/lenvanderhof", "https://www.bol.com/nl/nl/b/len-p-van-der-hof-msc/609879394/", "https://bsky.app/profile/lenvanderhof.com", "https://mastodon.social/@Lenvanderhof", "https://crates.io/users/Lenvanderhof", "https://cursor.com/@Lenvanderhof", "https://medium.com/@Lenvanderhof", "https://gitlab.com/Lenvanderhof", "https://hub.docker.com/u/lenvanderhof/", "https://dev.to/lenvanderhof", "https://www.facebook.com/Lenvanderhof", "https://soundcloud.com/Lenvanderhof" ], "affiliation": [ { "@id": "https://lenvanderhof.com/#publisher" }, { "@id": "https://lenvanderhof.com/#mindsesh" }, { "@id": "https://lenvanderhof.com/#lifestyle" } ] }, { "@type": "WebSite", "@id": "https://lenvanderhof.com/#website", "url": "https://lenvanderhof.com/", "name": "Len P. van der Hof", "description": "Len P. van der Hof, MSc, is a Dutch entrepreneur and AI innovator in Zwijndrecht. He builds ReasonKit, MindSesh, Undominated.ai, books under his name, the fiction imprint LPH98.lifestyle, and technology ventures through LPH98.ventures. Eleven titles in Systems for the Strategic Self are available now, in English and Dutch.", "inLanguage": [ "en", "nl" ], "publisher": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "Organization", "@id": "https://lenvanderhof.com/#publisher", "name": "LPH98.ventures", "url": "https://lph98.ventures", "founder": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "Organization", "@id": "https://lenvanderhof.com/#mindsesh", "name": "MindSesh", "url": "https://mindsesh.net", "founder": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "SoftwareApplication", "@id": "https://lenvanderhof.com/#reasonkit", "name": "ReasonKit", "url": "https://reasonkit.sh", "creator": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "SoftwareApplication", "@id": "https://lenvanderhof.com/#undominated", "name": "Undominated.ai", "url": "https://undominated.ai", "creator": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "Organization", "@id": "https://lenvanderhof.com/#lifestyle", "name": "LPH98.lifestyle", "url": "https://lph98.lifestyle", "founder": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "ImageObject", "@id": "https://lenvanderhof.com/en/blog/correction-vs-quiet-edit/#primaryimage", "url": "https://lenvanderhof.com/media/generated/blog-hero-correction-vs-quiet-edit.72fe0095522b.wide.webp", "contentUrl": "https://lenvanderhof.com/media/generated/blog-hero-correction-vs-quiet-edit.72fe0095522b.wide.webp", "representativeOfPage": true }, { "@type": "BreadcrumbList", "@id": "https://lenvanderhof.com/en/blog/correction-vs-quiet-edit/#breadcrumb", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://lenvanderhof.com/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://lenvanderhof.com/en/blog/" }, { "@type": "ListItem", "position": 3, "name": "Venture Building", "item": "https://lenvanderhof.com/en/blog/category/venture-building/" }, { "@type": "ListItem", "position": 4, "name": "Correction vs quiet edit: who needs to hear what changed?", "item": "https://lenvanderhof.com/en/blog/correction-vs-quiet-edit/" } ] }, { "@type": "WebPage", "@id": "https://lenvanderhof.com/en/blog/correction-vs-quiet-edit/#webpage", "url": "https://lenvanderhof.com/en/blog/correction-vs-quiet-edit/", "name": "Correction vs quiet edit: who needs to hear what changed?", "description": "Correct a wrong claim by fixing the source, telling the people who relied on it and addressing the consequences. With a worked example and a template.", "isPartOf": { "@id": "https://lenvanderhof.com/#website" }, "primaryImageOfPage": { "@id": "https://lenvanderhof.com/en/blog/correction-vs-quiet-edit/#primaryimage" }, "breadcrumb": { "@id": "https://lenvanderhof.com/en/blog/correction-vs-quiet-edit/#breadcrumb" }, "inLanguage": "en-GB" }, { "@type": "BlogPosting", "@id": "https://lenvanderhof.com/en/blog/correction-vs-quiet-edit/#article", "mainEntityOfPage": { "@id": "https://lenvanderhof.com/en/blog/correction-vs-quiet-edit/#webpage" }, "headline": "Correction vs quiet edit: who needs to hear what changed?", "description": "Correct a wrong claim by fixing the source, telling the people who relied on it and addressing the consequences. With a worked example and a template.", "datePublished": "2026-11-05T20:00:00.000Z", "author": { "@id": "https://lenvanderhof.com/#person" }, "publisher": { "@id": "https://lenvanderhof.com/#person" }, "image": [ "https://lenvanderhof.com/media/generated/blog-hero-correction-vs-quiet-edit.72fe0095522b.square.webp", "https://lenvanderhof.com/media/generated/blog-hero-correction-vs-quiet-edit.72fe0095522b.landscape.webp", "https://lenvanderhof.com/media/generated/blog-hero-correction-vs-quiet-edit.72fe0095522b.wide.webp" ], "articleSection": "Venture Building", "inLanguage": "en-GB" } ] } ```