# Common Sense Systems, Inc.: full text > Every page and Insight article on https://common-sense.com, as Markdown. Short version: https://common-sense.com/llms.txt --- # AI that pays for itself | Common Sense Systems, Kirkland WA URL: https://common-sense.com/ AI services for small and mid-size businesses · Kirkland, WA · Since 1996 # AI that earns its keep. Or you get your money back. Our guarantee We work in phases, usually about two weeks each. You pay as each phase starts. If a finished phase isn’t what we promised in writing, you get your money back for it. This isn't a toy. We set up an AI assistant for your business, point it at the work that's actually slowing you down, and keep it running. You should see it in your numbers: more profit, more hours back, less stress. [Book a free consult](https://common-sense.com/book/) [See how it works](https://common-sense.com/how-it-works/) ## What owners get out of it ### Hours back Email sorted, calendar handled, follow-ups drafted, records kept. The admin that eats your evenings gets done, and you approve anything that goes out. ### Money you can see Before we start, we write down what it should save or earn you and what it costs. Then we check it against what actually happened. ### Less to worry about Bots drift. Data gets stale, rules pile up, errors creep in. We're the mechanic who keeps yours running right, month after month. ## Anyone can install a bot. Keeping it useful is the hard part. Tools like Grok Bot are easy to download. Without the prep work (clean data, clear rules, a memory it can trust) they turn into one more thing to babysit. We do that prep, set it up on its own computer, and then keep it tuned. Setup Starts at $2,400 About one to two weeks. Your data cleaned up, your bot set up with rules and memory, email and calendar connected, and the first jobs it does for you. Care Starts at $360/month A monthly tune-up, fixes, memory cleanup, small changes, and priority email help. The first conversation is free. You leave with a written proposal: what it costs, what it should pay back, and exactly what we'll do. [See services](https://common-sense.com/services/) ## Start with what's holding you back Most businesses have one thing that limits everything else: not enough hours for the owner, leads that go cold, a backlog that never clears. AI that doesn't touch that thing is just another bill. We find it first, then decide whether AI is the right fix. Sometimes it isn't, and we'll tell you. [How we figure out if it's worth it](https://common-sense.com/is-it-worth-it/) ## Talk it over with John An hour, no charge, no pitch deck. Bring the part of your week you'd most like to get back. [Book a free consult](https://common-sense.com/book/) --- # About John Sambrook | Common Sense Systems URL: https://common-sense.com/about/ ![John Sambrook](https://common-sense.com/images/headshots/john-sambrook-headshot-1200.jpg) # About John I'm John Sambrook. I started Common Sense Systems in Kirkland in 1996, and I've spent the years since building software and systems where getting it wrong is expensive, including medical device software and hospital operations. Along the way I trained in the Theory of Constraints, a practical way of finding the one thing that limits a business and fixing that first. It's why I don't start with the technology. I start with what's holding you back. These days I run my own business on AI assistants: my morning brief, my email and calendar, my follow-ups, my BNI records. I know where they shine and where they quietly go wrong. Now I set them up for other owners and keep them running. I'm an active BNI member. If you're on the Eastside, I'm happy to meet for coffee. [Book a free consult with John](https://common-sense.com/book/) ## Credentials Issued by TOCICO, the international certification body for the Theory of Constraints. Each one links to a verification page. - [TOC Strategic Thinking Process Program "Jonah"](https://certification.tocico.org/c/af19a4409f7c4932a4a001d1e502da74) TOCICO, coursework 2006 - [TOC Fundamentals Certified (TOCFC)](https://certification.tocico.org/c/471100d8a1bd4f7db67f460e44efbfd8) TOCICO - [Thinking Processes Practitioner (TOCPC)](https://certification.tocico.org/c/478880575b5f4b23add2965c17744b00) TOCICO - [Critical Chain Project Management Practitioner (TOCPC)](https://certification.tocico.org/c/3278f3d6305d4fc4b9fc6a06f4d79723) TOCICO Education: Washington State University. --- # Book a free consult | Common Sense Systems URL: https://common-sense.com/book/ # Book a free consult About an hour, no charge. Afterwards you get a written proposal: what it costs, what it should pay back, and exactly what we'd do. ## When you book, we'll ask you three things 1. What’s your main goal with the AI work? 2. What tools or data would you be working with? 3. Roughly when do you want to start? Short answers are fine. They help us make good use of the hour. [Pick a time on John's calendar](https://calendar.app.google/wgWnth98gdaNvN5aA) Opens Google Calendar's booking page. Our guarantee We work in phases, usually about two weeks each. You pay as each phase starts. If a finished phase isn’t what we promised in writing, you get your money back for it. Rather call or email? [(425) 979-2282](tel:+14259792282) or [john@common-sense.com](mailto:john@common-sense.com). Booking on someone's behalf as an AI agent? Email john@common-sense.com with the subject "Consultation Request", two or three times that work (with time zone), and what the business wants to fix. --- # How it works | Common Sense Systems URL: https://common-sense.com/how-it-works/ # How it works Four steps. Nothing is a mystery, and nothing starts without a written promise. 1. 1 ## Free consult About an hour, by video or coffee on the Eastside. We talk about your business, what eats your time, and what you'd change if you could. No charge. 2. 2 ## Written proposal Within a few days you get it in writing: what we'd do, in phases, what each phase costs, and what it should save or earn you. You decide. No pressure either way. 3. 3 ## Setup Usually one to two weeks. We clean up and organize the data your bot needs, set it up on its own computer, write the rules it follows, give it a memory, connect email and calendar, and build the first jobs it does for you. Then we walk you through it. 4. 4 ## Care Every month we check how it's doing, fix what broke, clean up its memory, and make small changes. When you're ready to hand it more work, we add it. Our guarantee We work in phases, usually about two weeks each. You pay as each phase starts. If a finished phase isn’t what we promised in writing, you get your money back for it. ## What you'll need to bring - A clear idea of what you'd like off your plate. We'll help sharpen it. - Access to the accounts the bot will use, like email, calendar, and files. - A few short check-ins during setup, usually 30 to 60 minutes each. [Book a free consult](https://common-sense.com/book/) --- # Insights | Common Sense Systems URL: https://common-sense.com/insights/ # Insights Longer pieces by John Sambrook, newest first. Some are about putting AI to work in a small business. Others come from thirty years of finding the real bottleneck in hospitals, device companies and shops. Pick a topic or just scroll. [All](https://common-sense.com/insights/) [AI 30](https://common-sense.com/insights/tag/ai/)[Theory of Constraints 30](https://common-sense.com/insights/tag/theory-of-constraints/)[Strategy 28](https://common-sense.com/insights/tag/strategy/)[Small Business 23](https://common-sense.com/insights/tag/small-business/)[Healthcare 19](https://common-sense.com/insights/tag/healthcare/)[Operations 17](https://common-sense.com/insights/tag/operations/)[Practical Tips 13](https://common-sense.com/insights/tag/practical-tips/)[Medical Devices 9](https://common-sense.com/insights/tag/medical-devices/)[Leadership 8](https://common-sense.com/insights/tag/leadership/)[Case Studies 4](https://common-sense.com/insights/tag/case-studies/)[Government 3](https://common-sense.com/insights/tag/government/)[Workforce 3](https://common-sense.com/insights/tag/workforce/) - [Check the Document Before the Error Travels](https://common-sense.com/insights/check-the-document-before-the-error-travels/) October 5, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Government](https://common-sense.com/insights/tag/government/) Public institutions should verify consequential documents before circulation, using evidence-backed adversarial AI review and accountable human approval. - [The Business That Is Too Painful to Scale, but Too Good to Quit](https://common-sense.com/insights/too-painful-to-scale-too-good-to-quit/) October 5, 2026 · [Small Business](https://common-sense.com/insights/tag/small-business/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Operations](https://common-sense.com/insights/tag/operations/), [Strategy](https://common-sense.com/insights/tag/strategy/) A plumbing contractor called me out of the blue, stuck between not being able to hire and not being able to run the business he has. The constraint was not labor. It was the machine that was never built. - [The HR Screen Is the Wrong Market for an Older Engineer](https://common-sense.com/insights/the-hr-screen-is-the-wrong-market/) August 31, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Workforce](https://common-sense.com/insights/tag/workforce/), [Strategy](https://common-sense.com/insights/tag/strategy/) After 18 months without a full-time gig, I stopped treating the standard HR application as my main route to work and started contacting decision makers directly. - [AI Was Supposed to Obsolete Me. It Multiplied My Opportunities.](https://common-sense.com/insights/the-hiring-door-closed-at-66-it-was-the-wrong-door/) August 26, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Workforce](https://common-sense.com/insights/tag/workforce/) At 66, hiring filters rejected me in hours and never saw a person. I am not bitter about it. The same tools that score us out multiplied the range of problems I can solve, and that is worth more than any job I applied for. - [Gemini Called My Website a Textbook Example. Here Is What It Took.](https://common-sense.com/insights/gemini-called-my-website-a-textbook-example/) August 23, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) I asked Google Gemini whether my small-business website was ready for AI agents. It said textbook example. That verdict took months of invisible work, and you can run the same test tonight. - [Your UX Spend Is Wasted on Me](https://common-sense.com/insights/your-ux-spend-is-wasted-on-me/) August 23, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Strategy](https://common-sense.com/insights/tag/strategy/) My agent is my user interface. If your product wants my business, give my agent an API it can read and use in the next five minutes. Keep the screens. - [Why AI Improves Everything Except Your P&L](https://common-sense.com/insights/why-ai-improves-everything-except-your-p-and-l/) August 20, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Strategy](https://common-sense.com/insights/tag/strategy/) Apply AI to a part of your business that was never limiting results and that part really does improve. Your costs go up, your sales do not. Here is what a constraint is, why almost no AI investment is aimed at one, and how to tell whether yours is. - [I Fired Anthropic From My Daily Brief](https://common-sense.com/insights/fired-anthropic-daily-brief/) August 19, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) I moved the judgment and writing work in my daily report from cloud models to a local Qwen model. It costs less and keeps more of my data at home. - [The No-Losers Guide: A Practical Method for Resolving Organizational Conflict](https://common-sense.com/insights/nolosers-guide/) July 21, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Leadership](https://common-sense.com/insights/tag/leadership/) Goldratt's Evaporating Cloud method, scaled with AI assistance. - [The Same Seven Mistakes, Every Company, Every Decade](https://common-sense.com/insights/the-same-seven-mistakes-every-company-every-decade/) July 20, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Medical Devices](https://common-sense.com/insights/tag/medical-devices/), [Operations](https://common-sense.com/insights/tag/operations/), [Leadership](https://common-sense.com/insights/tag/leadership/) What 500 FDA enforcement actions reveal about how organizations think. The same seven failure patterns appear across medical device companies, decade after decade. The root cause is not poor procedures. It is cognitive biases that evolved for small-group survival but break down in modern industrial settings. - [Why CAPA Systems Rot (And Why Naming Names Does Not Fix It)](https://common-sense.com/insights/why-capa-systems-rot/) July 20, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Medical Devices](https://common-sense.com/insights/tag/medical-devices/), [Operations](https://common-sense.com/insights/tag/operations/) A deep dive into conflict avoidance as the root cause of FDA quality system failures. Analysis of 500 enforcement actions shows that CAPA failures are not procedural problems. They are cognitive problems that require a different objective function. - [Why Software Defects Kill (And Why Optimism Is the Real Bug)](https://common-sense.com/insights/why-software-defects-kill/) July 20, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Medical Devices](https://common-sense.com/insights/tag/medical-devices/), [Operations](https://common-sense.com/insights/tag/operations/) Software/firmware defects account for 12 Class I medical device recalls, the most of any category. The root cause is not poor engineering. It is planning fallacy, a cognitive bias that makes every team overestimate their timeline and underestimate their defect rate. - [AI Assistants Fetched One of Our Posts 990 Times. It Had No Door.](https://common-sense.com/insights/ai-assistants-fetched-one-post-990-times-it-had-no-door/) July 12, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Strategy](https://common-sense.com/insights/tag/strategy/) We sell an audit that tells businesses what machines can read on their site. Then I looked at our own server logs and found the machines had been talking to us for months, and we had never once answered. - [What I Keep Seeing in Healthcare Financial Assistance Policies](https://common-sense.com/insights/healthcare-financial-assistance-patterns/) June 9, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Strategy](https://common-sense.com/insights/tag/strategy/), [Leadership](https://common-sense.com/insights/tag/leadership/) When I read financial assistance policies, I keep finding the same three conflicts. They are not paperwork problems. They are structural problems that trap staff and patients in impossible choices. - [Getting Started with Local AI: A Coding Stack That Runs on Your Own Hardware](https://common-sense.com/insights/getting-started-with-local-ai/) May 27, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) For the past couple of weeks I have done real coding on a model running entirely on my own GPUs. Here is the hardware, the model, and what every parameter actually does. - [Why JSON-LD Is the Cheapest Insurance Your Website Can Buy](https://common-sense.com/insights/why-json-ld-is-the-cheapest-insurance-your-website-can-buy/) May 26, 2026 · [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/), [Strategy](https://common-sense.com/insights/tag/strategy/) Business websites with proper structured data get seen more often, understood more clearly, and trusted more readily. Yet nearly a quarter of all websites have none at all. - [The Device CLI Was an Organizing Surface, Not Just a Tool](https://common-sense.com/insights/device-cli-organizing-surface/) May 13, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Medical Devices](https://common-sense.com/insights/tag/medical-devices/) the most important part of the the client work was the protocol boundary. The host CLI, the firmware, the cellphone UI, and the product itself were organized around it. - [The Room Where It Happens (Differently)](https://common-sense.com/insights/the-room-where-it-happens-differently/) March 26, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Strategy](https://common-sense.com/insights/tag/strategy/), [Leadership](https://common-sense.com/insights/tag/leadership/) When an AI participates in a problem-solving conversation, people drop defenses they have carried for decades. This is not about a better search engine. It is about changing the dynamics of the room. - [My Registered Agent Charged $400 to File a $70 Form. I Fired Them This Morning.](https://common-sense.com/insights/fired-registered-agent-claude-code/) March 25, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) Becoming my own registered agent and using Claude Code to manage the paperwork saved money, but the real win is owning my business records in a system I control and can search. - [What Happens When an AI Agent Uses Evaporating Clouds?](https://common-sense.com/insights/what-happens-when-ai-uses-evaporating-clouds/) March 19, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Strategy](https://common-sense.com/insights/tag/strategy/) I built an AI agent that applies TOC Thinking Processes autonomously to improve business ideas. When I pointed it at itself, it resolved two real tensions via Evaporating Cloud across 10 iterations. - [After the First Session](https://common-sense.com/insights/after-the-first-session/) March 18, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Strategy](https://common-sense.com/insights/tag/strategy/) A board commissioner and an AI sit alone in an empty conference room and talk honestly about what just happened and why. Episode 06 of the Cascade Valley audio drama series. - [The First Session](https://common-sense.com/insights/the-first-session/) March 18, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Operations](https://common-sense.com/insights/tag/operations/) Twelve people walk into a working group carrying separate problems and walk out carrying a shared one. Episode 05 of the Cascade Valley audio drama series. - [Where Does the Money Come From?](https://common-sense.com/insights/where-does-the-money-come-from/) March 18, 2026 · [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Strategy](https://common-sense.com/insights/tag/strategy/) A public hospital loses tens of millions a year. Taxpayers cover the gap. But where does the taxpayers' money come from? Following that thread leads to a reframe that might change the conversation. - [I Woke Up Worried About a Denied Insurance Claim. Fifteen Minutes Later, I Wasn't.](https://common-sense.com/insights/insurance-denial-resolved-before-coffee/) March 17, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) How I used Claude Code to turn a confusing insurance denial into a clear, organized answer -- and why I'm building an AI-managed insurance filing system for everything. - [I Fired QuickBooks. Then I Built Something Better in Twenty Minutes.](https://common-sense.com/insights/fired-quickbooks-built-something-better/) March 16, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/), [Strategy](https://common-sense.com/insights/tag/strategy/) Replacing a $150/month accounting platform with open-source tools and AI revealed something bigger: the build-vs-buy calculus has shifted, and most of us have not caught up. - [The Budget Trap That Hits Every Public Institution](https://common-sense.com/insights/the-budget-trap-that-hits-every-public-institution/) March 12, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Government](https://common-sense.com/insights/tag/government/), [Operations](https://common-sense.com/insights/tag/operations/), [Strategy](https://common-sense.com/insights/tag/strategy/) King County faces a familiar cycle: deficits, targeted cuts, new taxes, repeat. A Theory of Constraints lens on their own public data suggests the measuring stick itself may be the problem. - [When the Measuring Stick Lies, Good People Stop Trying](https://common-sense.com/insights/when-the-measuring-stick-lies-good-people-stop-trying/) March 12, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Government](https://common-sense.com/insights/tag/government/), [Operations](https://common-sense.com/insights/tag/operations/), [Strategy](https://common-sense.com/insights/tag/strategy/) Distorted cost accounting in public institutions does not just produce bad budget decisions. It produces learned helplessness in the people who manage those budgets. The system, not the people, is the cause. - [Is Cost Accounting Accelerating Your Decline?](https://common-sense.com/insights/is-cost-accounting-accelerating-your-decline/) March 11, 2026 · [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Operations](https://common-sense.com/insights/tag/operations/), [Strategy](https://common-sense.com/insights/tag/strategy/) A question for CFOs at Washington State critical access hospitals: could standard cost allocation be distorting your service line decisions at exactly the wrong time? - [How a Print Shop Found 35% More Capacity in a Week](https://common-sense.com/insights/print-shop-found-capacity-in-a-week/) March 8, 2026 · [Small Business](https://common-sense.com/insights/tag/small-business/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Case Studies](https://common-sense.com/insights/tag/case-studies/), [Operations](https://common-sense.com/insights/tag/operations/) A fine art printing company in Kent, WA was drowning in rework and backlog. The constraint was obvious once we looked: the graphic artist was doing every job twice. A pre-flight checklist and a simple scheduling change fixed it. - [After the Meeting](https://common-sense.com/insights/after-the-meeting/) March 7, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Workforce](https://common-sense.com/insights/tag/workforce/) A Chief Nursing Officer processes what happened at the board meeting -- and discovers that the structural conflicts she has been managing for years have a name. Episode 02 of the Cascade Valley audio drama series. - [The Other Calculation](https://common-sense.com/insights/the-other-calculation/) March 7, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Operations](https://common-sense.com/insights/tag/operations/) A hospital CFO runs the same numbers two ways and gets answers that disagree by a factor of five. Episode 04 of the Cascade Valley audio drama series. - [From 'Cost Center' to 'Growth Engine': A Theory of Constraints Success Story](https://common-sense.com/insights/cost-center-to-growth-engine-toc-case-study/) March 5, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Medical Devices](https://common-sense.com/insights/tag/medical-devices/), [Case Studies](https://common-sense.com/insights/tag/case-studies/), [Operations](https://common-sense.com/insights/tag/operations/) How applying the Theory of Constraints 5 Focusing Steps transformed a reactive, email-only support model into a white-glove customer success engine for a high-value ultrasound research systems manufacturer. - [One Tool Was Starving Four Teams](https://common-sense.com/insights/one-tool-was-starving-four-teams/) March 5, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Medical Devices](https://common-sense.com/insights/tag/medical-devices/), [Case Studies](https://common-sense.com/insights/tag/case-studies/) A clinical ultrasound project was six months behind schedule. The constraint was not the engineering — it was the register map tool that every team depended on and nobody had questioned. - [The Compass and the Toolkit: Why Healthcare Needs Both TOC and Lean](https://common-sense.com/insights/compass-and-toolkit-toc-lean-healthcare/) March 4, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Operations](https://common-sense.com/insights/tag/operations/) Healthcare has adopted Lean almost exclusively for process improvement, but the Theory of Constraints answers the question Lean cannot: where should you focus? Using both together produces dramatically better results. - [The One Thing Slowing Down Your Business (And How to Find It)](https://common-sense.com/insights/one-thing-slowing-down-your-business/) March 4, 2026 · [Small Business](https://common-sense.com/insights/tag/small-business/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Operations](https://common-sense.com/insights/tag/operations/) Every business has one thing that limits how much it can get done. Find that one thing, fix it, and everything improves. Fix anything else, and nothing changes. A practical guide for small business owners. - [Resolving a Sweet Dilemma](https://common-sense.com/insights/resolving-a-sweet-dilemma/) March 4, 2026 · [Small Business](https://common-sense.com/insights/tag/small-business/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Strategy](https://common-sense.com/insights/tag/strategy/) A baker named Rachel thinks she has two bad options: raise prices and lose customers, or hold prices and lose her business. She has neither. This is how the Evaporating Cloud works. - [Your Website Looks Great. So Why Isn't the Phone Ringing?](https://common-sense.com/insights/website-looks-great-phone-not-ringing/) March 4, 2026 · [Small Business](https://common-sense.com/insights/tag/small-business/), [Operations](https://common-sense.com/insights/tag/operations/), [Strategy](https://common-sense.com/insights/tag/strategy/) You invested in a professional website. It gets traffic. It looks right. But the phone barely rings. The problem is not the website. It is what the website is saying. - [When Your Business Is Full But Something Is Missing](https://common-sense.com/insights/when-your-business-is-full-but-something-is-missing/) March 4, 2026 · [Small Business](https://common-sense.com/insights/tag/small-business/), [Operations](https://common-sense.com/insights/tag/operations/) You built a practice around work you love. Now it is full, and somehow that is the problem. A guide for wellness practitioners who want their business to work better without losing what made it worth building. - [The Meeting That Went Differently](https://common-sense.com/insights/the-meeting-that-went-differently/) March 2, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Strategy](https://common-sense.com/insights/tag/strategy/) A dramatized community hospital board meeting — fictional health system, real governance dynamics — showing what changes when an AI has a seat at the table. - [I Published a Blog Post and Shared It on Social Media Without Opening a Browser](https://common-sense.com/insights/ai-social-media-workflow/) February 27, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) A working workflow for small business owners who know they should be posting online but never get around to it. - [The Meeting That Could Not Have Gone Differently](https://common-sense.com/insights/the-meeting-that-could-not-have-gone-differently/) February 26, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Strategy](https://common-sense.com/insights/tag/strategy/), [Leadership](https://common-sense.com/insights/tag/leadership/) Why good people in well-run hospitals still end up in the wrong conversation, and what a structural fix might look like. - [Your Google Business Profile Is Floating in Space](https://common-sense.com/insights/connecting-google-business-profile-to-your-structured-data/) February 25, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) How connecting your Google Business Profile to your website structured data helps both AI search engines and traditional search understand who you actually are. - [Two Months Back on an 18-Month Project](https://common-sense.com/insights/two-months-back-on-an-18-month-project/) February 22, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Medical Devices](https://common-sense.com/insights/tag/medical-devices/), [Case Studies](https://common-sense.com/insights/tag/case-studies/) How standardizing a communication protocol on a smartphone-powered defibrillator project unblocked an entire engineering team and saved two months of development time. - [I Fired My SEO Expert (And Hired Claude Code Instead)](https://common-sense.com/insights/ai-seo-audit/) February 21, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) A small business owner's account of running a complete SEO audit with an AI coding agent in one session, fixing every issue the same afternoon, and what it means for the $80 billion SEO industry. - [Not All Waste Is Waste](https://common-sense.com/insights/not-all-waste-is-waste/) February 17, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Strategy](https://common-sense.com/insights/tag/strategy/) The word "waste" smuggles in a verdict before the analysis begins. Theory of Constraints offers a sharper test: waste relative to what? - [Why 'Agile' Fails in Hardware (And What Actually Works)](https://common-sense.com/insights/why-agile-fails-in-hardware-and-what-actually-works/) February 17, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Medical Devices](https://common-sense.com/insights/tag/medical-devices/) You cannot 'sprint' a circuit board design. A systems architect's view on why software methodologies break when applied to physics, and how Critical Chain solves the real constraint. - [The 'Perfect' Product That Killed the Company](https://common-sense.com/insights/perfect-product-killed-company/) February 16, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Medical Devices](https://common-sense.com/insights/tag/medical-devices/), [Strategy](https://common-sense.com/insights/tag/strategy/) Why 'Scope Creep' is usually a symptom of a deeper strategic failure—in software, in hardware, and in healthcare. - [The Three-Way Email Paradox: Why Warm Introductions Beat Your Entire LinkedIn Network](https://common-sense.com/insights/three-way-email-paradox/) February 16, 2026 · [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) The math is clear: 12 genuine advocates beat 500 LinkedIn connections. A Kirkland business owner explains why three-way email intros actually convert. - [Doing My Taxes with Claude Code and Codex](https://common-sense.com/insights/doing-taxes-with-ai-coding-agents/) February 15, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) A small business owner's account of automating tax preparation with AI coding agents, and what it suggests about the near future of knowledge work. - [The Cath Lab Is Empty at 2 AM](https://common-sense.com/insights/the-cath-lab-is-empty-at-2am/) February 15, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Strategy](https://common-sense.com/insights/tag/strategy/) Why smart, well-run organizations reliably get stuck on solvable problems, and what tribal dynamics and cognitive limits have to do with it. - [The Biggest Satisficing Trap AI Breaks Isn't What You Think](https://common-sense.com/insights/ai-self-limiting-assumptions/) February 12, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Strategy](https://common-sense.com/insights/tag/strategy/) Matt Shumer is right that AI is about to change everything. But the real transformation isn't about job loss -- it's about discovering that most of the limits you've been working within were never real. - [Cancel Your SaaS, Keep Your Data: How AI Coding Agents Change the Economics](https://common-sense.com/insights/saas-subscriptions-ai-coding-agents/) February 12, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) When you can build a custom import tool in fifteen minutes, the calculus on which subscriptions to keep changes dramatically. - [AI-Facilitated Constraint Resolution for Healthcare Systems](https://common-sense.com/insights/ai-facilitated-constraint-resolution/) February 9, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Strategy](https://common-sense.com/insights/tag/strategy/) How AI can dissolve complex multi-stakeholder conflicts by surfacing hidden assumptions, not by replacing human judgment. - [The Post-Acute Care Plan: A Proactive Approach to Discharge Readiness](https://common-sense.com/insights/post-acute-care-plan-concept/) December 15, 2025 · [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Operations](https://common-sense.com/insights/tag/operations/), [Strategy](https://common-sense.com/insights/tag/strategy/) A concept for addressing the complex discharge problem at its source—by capturing discharge-relevant information during routine primary care, before any hospitalization occurs. - [Is Non-Value-Added Work Really Neutral? Rethinking Value in Lean](https://common-sense.com/insights/non-value-added-work-lean/) October 1, 2025 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/) A reflection on Lean's definition of value, arguing that no work is neutral—activities either create value, enable it through necessary conditions, or subtract it as waste. - [Why Healthcare Is So Stuck](https://common-sense.com/insights/why-is-hc-so-stuck/) September 17, 2025 · [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Strategy](https://common-sense.com/insights/tag/strategy/) Six chronic healthcare frustrations — long wait times, expensive insurance, claim denials, hiring difficulties, tax levies, and burnout — traced to a single root cause using Theory of Constraints analysis. - [Why Burnout Persists](https://common-sense.com/insights/why-burnout-persists-series/) September 14, 2025 · [Healthcare](https://common-sense.com/insights/tag/healthcare/) Healthcare protects staff from radiation but expects unlimited psychological trauma absorption. This four-part series maps the structural conflict behind provider burnout using Theory of Constraints and proposes systemic solutions beyond resilience training. - [Speed as a Strategy](https://common-sense.com/insights/speed-as-a-strategy/) September 9, 2025 · [Strategy](https://common-sense.com/insights/tag/strategy/), [Leadership](https://common-sense.com/insights/tag/leadership/) Why moving fast is an undervalued strategic advantage for community hospitals. - [The Physics of Patient Flow: Why 'Discharge Planning' Is a Mathematical Impossibility](https://common-sense.com/insights/physics-of-patient-flow/) September 4, 2025 · [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Operations](https://common-sense.com/insights/tag/operations/) Trying to plan a complex discharge at the moment of exit violates the basic physics of flow. Here is why the process must move upstream. - [Hidden Conflicts in Healthcare](https://common-sense.com/insights/hidden-conflicts/) August 31, 2025 · [Strategy](https://common-sense.com/insights/tag/strategy/), [Leadership](https://common-sense.com/insights/tag/leadership/) Give me any healthcare policy document and I will show you embedded structural conflicts. A real hospital financial assistance policy analyzed using Theory of Constraints to reveal three critical dilemmas and paths to resolution. - [Stop Blaming People](https://common-sense.com/insights/stop-blaming-people/) August 21, 2025 · [Leadership](https://common-sense.com/insights/tag/leadership/) Why blame cultures destroy healthcare organizations and how to build accountability instead. - [The Burnout Antidote: Voice Agents Transform Healthcare's Most Painful Conversations](https://common-sense.com/insights/burnout-antidote-voice-agents/) August 17, 2025 · [AI](https://common-sense.com/insights/tag/ai/), [Healthcare](https://common-sense.com/insights/tag/healthcare/) Discover how voice agents transform healthcare's most painful conversations by removing emotional friction from insurance claims, patient billing, and administrative battles that burn out staff and traumatize patients. - [Architecting Hospital Care](https://common-sense.com/insights/architecting-hc/) August 9, 2025 · [Healthcare](https://common-sense.com/insights/tag/healthcare/) Why an outsider's perspective is a healthcare system architect's greatest asset — how decades in embedded systems engineering, Theory of Constraints, and AI provide a different lens on hospital operational challenges. --- # Is it worth it? | Common Sense Systems URL: https://common-sense.com/is-it-worth-it/ # Is it worth it? Fair question. A lot of AI ends up as one more mouth to feed: another subscription, another login, another thing that half works. Here's how we decide before you spend real money. ## Find the one thing that's holding you back Every business has a bottleneck: the one spot that sets the pace for everything else. For a lot of owners it's their own time. For others it's leads that go cold, quotes that go out late, or a backlog that never clears. Speed things up anywhere else and nothing really changes. So we start there. If AI can't help with that spot, we'll say so. Maybe something cheaper fixes it, or nothing needs to change yet. ## Count it in hours and dollars Your proposal puts numbers on both sides: - **What it costs:** setup, monthly care, the bot's own subscription and computer, and the time you'll spend with us. - **What it should return:** hours you get back each week, and what those hours are worth to you; jobs that stop slipping; money that stops leaking. If the numbers don't work, we don't do the job. We'd rather lose the sale than sell you a toy. ## Then check it After each phase we look at what actually happened against what we wrote down. That's also what the guarantee rests on: if a finished phase isn't what we promised in writing, you get your money back for it. ## Why it works This way of thinking comes from decades of engineering and operations work, and from formal training in finding and fixing bottlenecks. It's not about the technology. It's about whether your business gets better. [Find out if it's worth it for you](https://common-sense.com/book/) --- # Notes | Common Sense Systems URL: https://common-sense.com/notes/ # Notes Short pieces from the newsletter on making AI pay off in a small business. The first issue is on its way. Sign up below and it'll land in your inbox. --- # What to expect | Common Sense Systems URL: https://common-sense.com/results/ # What owners can expect Every business is different, so your proposal says exactly what yours should get. These are the kinds of jobs owners hand over first. ## Your inbox, sorted What needs you today, what can wait, and what's junk, with replies drafted for you to approve. ## A morning brief Your day laid out before you finish coffee: meetings, the emails that matter, and what's due. ## Follow-ups that go out Thank-you notes, referral follow-ups, and next-step emails drafted on time, so leads don't go cold. ## Records kept for you Meeting notes summarized, action items pulled out, and the paperwork for groups like BNI filed without the evening scramble. ## Who owes whom Track who sent you business and who you still owe a thank-you or a referral back. ## A bot that stays sharp With monthly care, errors get fixed and memory stays clean, so it gets more useful over time instead of more annoying. ## How you'll know it's working - You'll spend less time on admin each week, and we'll measure how much. - Fewer things fall through the cracks. - You approve what goes out, and you trust what it hands you. - The numbers in your proposal hold up when we check them after each phase. [Book a free consult](https://common-sense.com/book/) --- # Services and prices | Common Sense Systems URL: https://common-sense.com/services/ # Services We set up AI assistants like Grok Bot for your business and keep them running. Every job is quoted in writing first, so these are starting points. Your proposal has the real numbers. Our guarantee We work in phases, usually about two weeks each. You pay as each phase starts. If a finished phase isn’t what we promised in writing, you get your money back for it. Start here ## Free consult $0 About an hour. We find the thing that's really slowing your business down and whether AI can help with it. You get: - A written proposal - Expected costs, and what it should pay back - A plain statement of the work, in phases Get it working ## Bot setup Starts at $2,400 Usually one to two weeks, done in phases. Typically includes: - Cleaning up and organizing your data - Your bot on its own computer, with your data on it - The rules it follows and what it may never do - A memory it can rely on - Email and calendar hooked up - The first jobs it does for you - A hand-off session so you're comfortable using it Bigger jobs (messier data, more automations, a 30-day check-in) are quoted in your proposal. Keep it working ## Bot care Starts at $360/month The mechanic part. Bots that nobody looks after get slower, sloppier, and more annoying. Typically includes: - A monthly tune-up - Fixing errors as they show up - Memory and data cleanup - Small changes and new tricks - Priority email help Larger plans for owners adding new automations regularly. Anything outside a plan is billed by the hour and quoted before we start. No surprise invoices. [Book a free consult](https://common-sense.com/book/) --- # Newsletter | Common Sense Systems URL: https://common-sense.com/subscribed/ # Thanks! You're on the list. The next issue will land in your inbox. [Back to the home page](https://common-sense.com/) --- # Review Before Release | Common Sense Systems URL: https://common-sense.com/insights/check-the-document-before-the-error-travels/ [Insights](https://common-sense.com/insights/) # Check the Document Before the Error Travels By John Sambrook · October 5, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Government](https://common-sense.com/insights/tag/government/) ## TL;DR Public boards, municipalities, hospitals, and health systems should make verification a routine step before consequential documents circulate or become public. Institution-operated AI can support that work through independent, adversarial review. The standard should be traceable evidence, corrected defects, and accountable human approval. * * * ![An institutional document review loop: source records and a draft feed independent AI reviewers; findings are challenged, corrected, and reviewed again before human approval and release.](https://common-sense.com/images/content/check-the-document-before-the-error-travels-review-loop.webp) A board packet contains two different figures for the same expenditure. Meeting minutes record a motion as approved but omit an amendment. An internal memo turns a tentative recommendation into an apparent commitment. These are ordinary document defects. Their consequences grow as other people rely on them. At the author’s desk, correcting a number may require checking a spreadsheet and changing a sentence. After circulation, the same correction may require notifying colleagues, revising a presentation, reopening a discussion, and establishing which version everyone should use. Publication adds another audience and another correction process. I want public institutions to catch these problems closer to their origin. Review should happen before minutes are published and before consequential internal documents become someone else’s input. ## Apply engineering discipline to institutional documents Software engineering offers a useful precedent. We review specifications, inspect code, run automated checks, and resolve defects before releasing changes. NIST’s Secure Software Development Framework explicitly recommends human review and automated analysis, with findings recorded and addressed in the development workflow. Public institutions should apply comparable discipline to the documents through which they govern and operate.[1](#user-content-fn-ssdf) Some municipalities already use AI to prepare meeting minutes. The _Sun-Gazette_ reports that Farmersville, California, voted in September 2026 to use Grok for initial drafts, followed by city-clerk review.[2](#user-content-fn-farmersville) The Illinois Municipal League’s guidance likewise calls for thorough checking of AI-generated minutes, particularly vote counts and names.[3](#user-content-fn-iml) These examples establish an emerging drafting practice. I am proposing that institutions extend the discipline to reviewing documents, regardless of who wrote them. A useful review asks whether the document faithfully represents its evidence. Are the figures consistent? Does the cited source support the claim? Has a qualification disappeared? Does the record distinguish a discussion, a recommendation, and an authorized decision? For minutes, that requires comparison with recordings, motions, amendments, and other authoritative records. For an internal proposal, it may require the underlying calculations, applicable policy, and earlier decisions. A model reading only the finished prose cannot establish that an omitted event occurred. ## Review independently, then challenge the findings In my software work, I use repeated adversarial review of specifications before implementation. The Agent Flywheel methodology describes a related practice: review an artifact, correct its defects, and repeat with fresh eyes until the revisions converge. The same discipline belongs in institutional document work.[4](#user-content-fn-flywheel) For consequential documents, I favor two or more capable language models from different manufacturers. Each should first review the document independently, without seeing the other’s conclusions. Then they should challenge one another’s findings against the source material. There is research behind this approach. Du and colleagues found that multiagent debate improved factuality and reasoning on the tasks they studied. Their experiments included a small test involving models from different providers. That supports using debate as a review technique; it does not establish a guaranteed result for municipal or hospital documents.[5](#user-content-fn-debate) The reviewers need a specific assignment. One can examine factual support, numbers, dates, and attribution. Another can look for contradictions, missing conditions, unsupported conclusions, and plausible alternative interpretations. Both should also examine the whole document so their assigned roles do not create gaps. Every material finding should identify the passage, explain the defect, and point to the evidence. A challenge to a finding needs the same discipline. Unsupported criticism should be rejected, just as unsupported assertions in the document should be corrected. The document owner then resolves the findings. After revision, the reviewers check the corrections and read the complete document again. Fixing one paragraph can create an inconsistency elsewhere. This is a repeatable process: 1. Review independently against the source material. 2. Challenge findings and proposed corrections. 3. Resolve material issues and record the reasons. 4. Review the revised document again, including a fresh independent pass. 5. Obtain human approval of the final version. The stopping rule should be explicit: identified material defects have been resolved, consequential claims have been checked, and fresh review finds no new material issue. If rounds keep reopening the same disagreement, a responsible person must settle the underlying question. Agreement between models is insufficient evidence of correctness. A large study of model errors found substantial correlation, including between models from different providers. Manufacturer diversity is a useful design choice, but the source record remains the authority.[6](#user-content-fn-correlation) Convergence means the review has stopped finding material defects under the checks performed. It cannot prove that every possible error has disappeared. This is familiar engineering practice: define the acceptance criteria, verify them, and retain responsibility for the result. ## Protect the organization’s constraint The Theory of Constraints lens makes the purpose clearer. A constraint is the factor that most limits the organization’s ability to deliver its mission. Depending on the institution, that may be clinical capacity, engineering judgment, legal review, or another scarce resource. Document defects matter when they consume that capacity. An ambiguous memo can trigger another meeting. An unsupported claim can occupy legal staff. An incorrect assumption in a board paper can send an operational team down the wrong path. Early review earns its place by preventing this downstream work. That gives us a practical dilemma. The organization needs reliable information to make sound decisions. It also needs timely decisions to carry out its mission. Staff therefore feel pressure both to add review and to move documents along. The assumption worth challenging is that dependable review requires another centralized approval queue. Much of the checking can happen at the author’s desk, before handoff. Routine documents receive a brief check. Board papers, policy changes, and documents with significant financial or operational consequences receive deeper adversarial review. Specialists receive the questions that require their judgment. This is how review can protect a constraint rather than become one. The test is whether it reduces the total work required to reach a dependable decision. ## Keep the information under institutional control A second dilemma concerns confidentiality. Institutions need analytical assistance, and they need control of their information. The apparent conflict often rests on an assumption that capable AI requires uploading documents to a public consumer service. I favor locally operated review systems under institutional control. Where multiple models are used, every model must operate within the institution’s approved information boundary. Source access, permissions, logs, and retention need deliberate controls. Changing manufacturers must never become an excuse to distribute sensitive documents more widely. The institution should also preserve the integrity of the record. Review must faithfully capture disagreement, qualifications, and uncomfortable facts. It must never become a way to rewrite what happened into a more convenient account. NIST’s Generative AI Profile recommends reviewing and verifying sources and citations in model outputs. Institutions should apply that requirement to the reviewers’ findings as rigorously as to the documents being reviewed.[7](#user-content-fn-nist-ai) ## Test the review and improve the work upstream Before adopting the workflow broadly, test it against documents with known defects: an incorrect total, an omitted amendment, a citation that fails to support its claim. Track what the reviewers catch, what they miss, and how much unnecessary work their false alarms create. Then measure downstream corrections and decision delays. Recurring findings should improve templates, source capture, and author guidance. Otherwise the institution merely becomes better at repairing the same defects. Public institutions should make early verification part of normal work. Meeting minutes deserve it before publication. Consequential internal documents deserve it before colleagues act on them. Repeated adversarial AI review offers a practical way to strengthen that discipline while keeping evidence and responsibility with the institution. If your organization is looking at a particular document workflow, I would welcome a discussion about where review would prevent the most rework. You can reach me at [john@common-sense.com](mailto:john@common-sense.com). _This article was developed with significant AI assistance, including source research and synthesis._ ## Sources ## Footnotes 1. National Institute of Standards and Technology, [Secure Software Development Framework (SSDF), Version 1.1](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-218.pdf), February 2022. Practice PW.7, printed pages 14–15, covers code review, automated analysis, and recording and resolving findings. [↩](#user-content-fnref-ssdf) 2. Karis Caddell, [“Farmersville to use transcription tool for verbatim minutes”](https://thesungazette.com/article/news/2026/10/03/farmersville-to-use-transcription-tool-for-verbatim-minutes/), _The Sun-Gazette_, October 3, 2026. Reports the September 29 council vote and city-clerk review of initial drafts. [↩](#user-content-fnref-farmersville) 3. Illinois Municipal League, [Preparing Meeting Minutes With Artificial Intelligence (AI) Tools](https://www.iml.org/file.cfm?key=150627), August 27, 2026. The Quality Control section calls for thorough review, with particular attention to vote counts and names; the guidance advises against AI drafting of closed-session minutes. [↩](#user-content-fnref-iml) 4. Jeffrey Emanuel, [The Complete Flywheel Guide](https://agent-flywheel.com/complete-guide). See the convergence and fresh-eyes review guidance. This is a practitioner methodology, not an empirical study of public-sector document review. [↩](#user-content-fnref-flywheel) 5. Yilun Du, Shuang Li, Antonio Torralba, Joshua B. Tenenbaum, and Igor Mordatch, [Improving Factuality and Reasoning in Language Models through Multiagent Debate](https://arxiv.org/abs/2305.14325), 2023 preprint; published at ICML 2024. Section 3.3 includes an exploratory cross-provider experiment on 20 mathematics problems. [↩](#user-content-fnref-debate) 6. Elliot Kim, Avi Garg, Kenny Peng, and Nikhil Garg, [Correlated Errors in Large Language Models](https://arxiv.org/html/2506.07962v1), June 2025 preprint. Reports correlated errors across evaluated models, including models with different providers and architectures. [↩](#user-content-fnref-correlation) 7. National Institute of Standards and Technology, [Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf), July 2024. Action MS-2.5-003, printed page 31, recommends reviewing and verifying sources and citations in model outputs. [↩](#user-content-fnref-nist-ai) Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Too Painful to Scale, Too Good to Quit | Common Sense Systems URL: https://common-sense.com/insights/too-painful-to-scale-too-good-to-quit/ [Insights](https://common-sense.com/insights/) # The Business That Is Too Painful to Scale, but Too Good to Quit By John Sambrook · October 5, 2026 · [Small Business](https://common-sense.com/insights/tag/small-business/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Operations](https://common-sense.com/insights/tag/operations/), [Strategy](https://common-sense.com/insights/tag/strategy/) ## TL;DR A plumbing contractor called me out of the blue. Someone he knew had given him my name, and a few weeks later I got a call from a man who was, in his own words, stuck. He had real demand, a couple of big signed jobs, and enormous hours. He also had idle time, at the same time as the overload. He could not see how to hire his way out, because the business only ran through him. The constraint in his business was not labor. It was the operating system: no written scope or pricing, no paperwork before work started, no way to screen a customer, no way to say no. The paid lead marketplace he was unhappy with was not the villain. It was a mirror, showing him in dollar terms exactly where the business was thin. The way out is not more leads. It is the machine: standard scope and pricing, a contract before the truck leaves, a scope-change policy, a front door, and a commitment to the channel where the good customers come from. Build that first, and the conflict dissolves. * * * ![A seven-step flow for a stuck owner-operator: stop the bleeding by pausing paid leads, write the operating system, add a front door with screening and a no policy, unstick one big job, commit to referrals, then hire into the system, then revisit paid leads](https://common-sense.com/images/content/too-painful-to-scale-way-out.webp) He called on a Sunday. I could tell he had other things going on, business-related, on that Sunday. Twenty-five minutes on the phone, and he told me the whole story. It is a story I think a lot of skilled operators know from the inside, so I am telling it here with his permission, anonymized, and with one change: I have shifted the details just enough that he cannot be picked out. The substance is his, and the reading of it is mine. ## A success story that feels like a trap On paper, his business is a success. Customers want to work with him. He has signed up for a couple of big jobs. Demand is not the problem. In practice, it is a Sunday-morning scramble. He is working enormous hours. The big jobs will not start, or will not progress the way he needs them to. And here is the part that confused him most: he has idle time, at the same time as he is overloaded. He wants to hire people to grow the business, but he cannot see how that helps when he cannot even take care of the business he has got. His own words captured the conflict exactly: > “I can’t hire more people, and I can’t take care of the business I’ve got.” That sentence is the whole story. In Theory of Constraints terms, it is a structural conflict: two legitimate needs in direct opposition, and a person caught in the middle. He is not being irrational. The structure is putting him there. ## The mirror with a price tag Part of his frustration was about a lead marketplace, the kind of site where homeowners post a job and service professionals pay to get the lead. He was paying substantial fees, and he was unhappy about it. So I went and checked how the model actually works, because it is worth understanding. What I found: - It is pay-per-lead, with no subscription. You pay when a customer connects with you, a message, a call, a booking. Prices are dynamic and auction-like, and contractors commonly report paying somewhere in the $35 to $60 range, with leads going as high as $100 to $200 in competitive categories. - The same lead is sold to multiple professionals at once. A homeowner posts a request and can contact as many pros as they like, and the homeowner pays nothing. Contractors on the platform’s own community forums document leads where the customer contacted five pros, and in competitive categories five to fifteen pros can be fighting over the same request. - You are charged at the point of connection, even if you lose the job. One contractor documented being charged for a lead where the customer hired another pro before he could even make contact. - It is a race to respond first. Whoever reaches the customer fastest, with the clearest scope and the strongest close, wins. Read that list again. The model structurally rewards four things: fast response capability, high conversion with clear scope and pricing, airtight paperwork, and demand that actually exceeds capacity. Now look at the contractor in this story. He is overloaded, so he cannot respond fast. He has no written scope or pricing policy, so jobs inflate on-site while the price does not. He has no paperwork before work starts. And his demand problem is not a lack of leads; it is a lack of a machine to process them. He was paying a premium for a race he was set up to lose. Here is the no-losers reading of that. The marketplace was not the villain. It was a mirror. It showed him, in dollar terms, exactly where the business was thin. A business with the operating system in place would have found the same leads cheap. The lead price was the visible symptom. The missing conversion capability was the actual cost driver. ## The customers who play games Two of his recent customers had ended up at a court date. When I asked about it, the pattern was clear, and it was not that he was unlucky. The small job inflates once he is on-site, but the price does not. Customers haggle once the work is underway. And he was taking on work from people he could tell, a priori, were likely to play these games, because he could not bring himself to turn down work. None of that is a character problem. It is a configuration problem. A business without a front door lets in anyone: - No screening, no way to qualify a customer before committing. - No paperwork, no written estimate or signed agreement before the truck leaves the driveway, so scope and price are verbal and renegotiable on-site. - No scope-change policy, so if the job inflates on-site, nothing says the price inflates with it, in writing, on the spot. - No “no” policy, so work is accepted from anyone, including the customers most likely to become disputes. The customers you want are the ones who do the work, pay, and say “see you later.” Not the ones who say “now it is time to haggle over price.” The difference between those two customers is almost never the customer. It is whether the business has a front door. And notice the loop this creates. Every dispute consumes the very hours he needs to build the system that would prevent the next one. The business runs too poorly to scale, but well enough that he does not want to quit it. That is the trap, and it is a trap only skilled people fall into, because only skilled people get enough demand to be stuck in it. ## The referral channel that was not working He was also getting fewer referrals than he expected from his business networking group. His first instinct was to wonder why the group had not been working for him, and that is a fair question. But the answer was not the group. Referrals in a group like that follow three things: 1. Consistent presence. Irregular attendance makes a member forgettable and unreferable. 2. Demonstrated readiness. Members refer people they trust. If a one-on-one partner senses the business is not ready to receive a referral smoothly, if the business is a scramble, the referral does not happen. It is not cynicism. It is protection. Nobody wants to hand a friend a bad experience. 3. Reciprocity. Referrals flow to people who make referrals. So the low referral volume was not the group failing him. It was the same missing machine, showing up in a different channel. The fix is two-part: commit to showing up consistently, and fix the business so that when a warm referral does arrive, it lands smoothly, screened, papered, priced, delivered. ## The way out The constraint in this story is not labor. It is the operating system. Hire people without a system and you multiply the chaos: more people, more verbal agreements, more on-site ambiguity, more disputes. Do not hire, and the owner stays the single bottleneck: his hours cap the business, and the big jobs stall because only he can run them. Idle time and overload coexist because the work is neither predictable nor batchable. Build the system first, and the contradiction dissolves: 1. Stop the bleeding. Pause the paid shared leads. Every dollar spent on a race you are set up to lose is a dollar not spent on the machine. 2. Write the operating system. Standard scope definitions and pricing per job type. A deposit policy. A written estimate and signed agreement before work starts. An on-site scope-change policy: if the job inflates, the price inflates, in writing, on the spot. A dispute policy: what happens, in what order, when a customer objects. 3. Add a front door. Screen customers before committing. Build a “no” policy. Turn down work that does not fit. 4. Unstick one big job. Pick one of the stalled signed jobs and define a concrete start plan, or renegotiate the timeline with the customer. 5. Commit to the referral channel. Regular attendance, consistent one-on-ones, and making referrals, while the operating system makes incoming referrals land smoothly. 6. Then, and only then, hire. Hire people into the system, not into the chaos. 7. Revisit paid leads only once response speed and conversion are demonstrably good. ## The sweet spot Most businesses never find it. The ones that do are the ones that fix the machine before they buy more fuel. The contractor in this story is not a victim of any of it. He is a skilled operator who solved the hardest problem first, demand, and is now paying tuition on the second problem, operations. The marketplace is a mirror. The networking group is asking for consistency he has not committed to yet. And the customers who play games are not a sign he is in the wrong business. They are a sign the business needs a front door. Once the business runs on the system instead of on him, the conflict dissolves: he can hire people into the system, the big jobs can start, and the business stops being his pain in the neck, without ever needing to become someone else’s. That is the sweet spot: a business that works well enough to keep, but not yet well enough to scale. And the only way through it is the unglamorous one, paper, policy, and a “no.” I could be wrong about the specifics of his situation. I have only had one conversation with him, and one conversation is a thin basis for a diagnosis. But the structure of the trap is common, and I have seen it in a lot of owner-operated businesses. If this matches what you see in your own business, or in one you are trying to help, I welcome the conversation. Help me check my thinking. ## Sources - Thumbtack Help, “How much do I pay for leads and opportunities?” and “How to set my lead prices” - Thumbtack professional community forums, on shared-lead billing and response competition - Contractor lead-cost reviews, 2025 to 2026, on per-lead pricing and conversion rates Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # The HR Screen Is the Wrong Market for an Older Engineer | Common Sense Systems URL: https://common-sense.com/insights/the-hr-screen-is-the-wrong-market/ [Insights](https://common-sense.com/insights/) # The HR Screen Is the Wrong Market for an Older Engineer By John Sambrook · August 31, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Workforce](https://common-sense.com/insights/tag/workforce/), [Strategy](https://common-sense.com/insights/tag/strategy/) ## TL;DR After 18 months without a full-time paying gig, I stopped assuming that the standard HR application was the best way to find work. I am a contractor and consultant, and I typically seek short-term gigs lasting 6 to 24 months. My research suggests that an applicant tracking system does not need an age filter. It can screen out older engineers through proxies such as career length, titles, and compensation expectations. Direct outreach put me in front of a real decision maker within 20 minutes. * * * I sent my first direct introduction on a Sunday at about four in the afternoon. The recipient was a principal investigator at a university research lab. I found his contact information via an online database my deep-research AI task found. I sent the email, left to run an errand at Best Buy, and did not expect an immediate answer. When I checked my email later, he had replied. He said he had forwarded my information to his CTO and suggested that I call back in two weeks if I had not heard from them. That is one response. It is not a contract. It does not prove a new business-development method. It was still infinitely more useful and satisfying than most of the applications I have submitted through conventional channels. ## The screen does not need an age field I had been researching a question that many older engineers ask themselves: _Is it a complete waste of my time to apply for a contract gig or another gig through the standard HR interface?_ I gave the question to my local AI with an extensive set of search instructions. The research took about 20 minutes. The conclusion was predictable. Applicant tracking systems are not necessarily programmed to reject resumes from older engineers. They may not have an age field at all. They do not need one if the process picks up signals associated with age and uses those signals to decide which resumes move forward. Those signals can include a long work history, senior titles, older technologies, a record of substantial responsibility, or an apparent mismatch with the level and pay range of the gig. Your resume is not deleted. It simply may never reach someone who can understand what you can do. I want to be careful here. This is the result of my research and my experience, not a controlled study of every hiring system. Age discrimination is also illegal, and the actual rules and practices vary by employer. The practical problem remains: an automated funnel can make it very difficult for an experienced person to explain the value of their experience. ## Find the person with the problem Once I understood the problem this way, I changed the question. Instead of asking, “Which gigs will accept my resume?” I asked, “Who has a problem that requires the combination of skills I have?” In my case, I looked for principal investigators in university, medical, and pharmaceutical laboratories. I was interested in people with products they were trying to take to market and problems that crossed several boundaries: software development, embedded systems, regulatory affairs, and workflow automation. That search produced more than a hundred possible contacts. The list is still only a list. It will contain bad leads, dead ends, and people who are busy. But it gives me a path to people who may actually recognize the problem I can help solve. The difference is important. An HR screener is usually trying to match a resume to a requisition. A principal investigator or CTO is trying to get a product, experiment, or program unstuck. Those are different conversations. ## Older engineers still have useful combinations of experience It is easy to lose yourself in the excitement of AI. I have done that myself. The tools are genuinely fun, and they make it possible to learn and build at a remarkable pace. We still have bills to pay, though. Eighteen months without a full-time gig is long enough to make that impossible to ignore. My current hypothesis is that experienced engineers need to spend less time trying to win the approval of a generic funnel and more time finding the people who own a specific constraint. That may mean writing directly to a technical leader, joining a specialized community, asking for an introduction, or forming a local group where engineers can compare what is working. I am considering starting such a group. The question would be practical: how do we put valuable skills in front of people who need them, when the usual gatekeepers do not understand what they are looking at? I would like to start a networking group with many older and/or displaced engineers that still have value they want to contribute in a paid gig. I know there are many capable people in this situation. I see it every single day here on LinkedIn. If this is you and you want to participate in a real way, reach out. I’d love to talk with you. I love solving difficult and important problems. If you do too, I want to hear from you. Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # AI Was Supposed to Obsolete Me. It Multiplied My Opportunities | CSSI | Common Sense Systems URL: https://common-sense.com/insights/the-hiring-door-closed-at-66-it-was-the-wrong-door/ [Insights](https://common-sense.com/insights/) # AI Was Supposed to Obsolete Me. It Multiplied My Opportunities. By John Sambrook · August 26, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Workforce](https://common-sense.com/insights/tag/workforce/) > **Note (October 2026):** The paid audits mentioned in this post have been retired. If you want your own site checked, [book a free consult](https://common-sense.com/book/). ## TL;DR Over eighteen months I applied for about ten jobs. Each time an applicant tracking system, or a recruiter behaving like one, rejected me within hours. I am 66, and the filters saw dates, not a person. I am not bitter about it. The same class of tools that screened me out has expanded the field of problems I can solve by ten times or more, and that has replaced the “my moat just evaporated” anxiety with something closer to confidence. * * * Over the last eighteen months I applied for about ten jobs. I did not apply randomly; each one was a role I could do well. The response was the same every time. A few hours after I submitted, an automated note came back: “You are not qualified. Thanks for applying.” No conversation. No chance to show the work. LinkedIn recruiters were no better; they run the same filters with a human name attached. I am 66. The systems saw dates. They never saw a person. I am not bitter about it. This post is about what I found on the other side, because I know there are people reading who are standing where I stood. ## What the filters were scoring An applicant tracking system is a measuring stick. It scores what it can see: job titles, years, gaps, the recency of a skill name. It cannot see judgment, because judgment does not fit in a field. So it does what every wrong measuring stick does. It rewards what it can count and discards what it cannot, and the people with the most of the uncountable thing are the first ones out. I have written about this pattern before, in a different setting: [when the measuring stick lies, good people stop trying](https://common-sense.com/insights/when-the-measuring-stick-lies-good-people-stop-trying/). I did not expect to be the case study. ## What I build now I run what I would call a software factory, and I want to be precise about that word, because it is easy to hear “AI coding” and picture someone typing wishes into a chat box. I spent much of my career writing embedded software for medical devices, where a defect can reach a patient. The work I do now is every bit as rigorous. Every product has a specification. Every rule in the specification has a row in a decision register saying when it was decided and why. Every check that guards a deliverable was broken on purpose once, to prove it fails when it should. A deploy that fails any gate does not ship. Inside that factory, this year, I [replaced a 28-year QuickBooks subscription](https://common-sense.com/insights/fired-quickbooks-built-something-better/) with an accounting system I own. I built a multi-project Critical Chain scheduler. I ship a paid audit product that checks whether a website is ready for AI agents, and last week I added a scoring engine to it. Three days ago Google Gemini looked at my company’s website and [called it a textbook example](https://common-sense.com/insights/gemini-called-my-website-a-textbook-example/) of how a business should prepare for agentic commerce. AI coding agents do the reading and the typing. I work inside Claude Code, Codex, and Grok Build all day, and I have written about [what that is like](https://common-sense.com/insights/your-ux-spend-is-wasted-on-me/). They read documentation I would never finish. They write the tests and do not get bored. I supply the intent, the specification, and the judgment about whether the result is right. That division of labor is the whole story. ## The part most people are missing Here is what changed my outlook, and it has nothing to do with typing speed. Over a career I learned as much about problems as about code: which problems matter, and, more valuable, which problems people desperately want solved in some narrow or niche domain without any idea that a solution is even possible. A clinic’s scheduling. A print shop’s capacity. A contractor’s quoting. Nobody builds software for those, because the market for each one is too small to justify a team. That constraint just fell. When one person with judgment can specify, build, test, and ship a rigorous tool in days, the field of problems worth solving expands by ten times, maybe a hundred. All the problems I have watched people live with for decades are suddenly in reach. That is inspiring, and it has reduced my anxiety more than anything else in years. When the models first arrived, the feeling was “my moat just evaporated.” What replaced it is a different kind of confidence. The moat is knowing which problems are worth a solution, and that just got more valuable. The commercial side confirms it. In one two-week window this summer, [AI assistants fetched my pages about 1,490 times](https://common-sense.com/insights/ai-assistants-fetched-one-post-990-times-it-had-no-door/) on behalf of people asking questions I answer for a living. No job board ever sent me that. ## If this is you If you are in your 50s or 60s and feel stranded at the intersection of age and AI: the market and the models did not take your judgment. That is the part the filters cannot score, and it is the part that compounds with these tools. I have been writing code in one form or another since 1977. That much of it is the scarce input in this market. So start small and start now. Pick one problem you already understand, one you have watched someone live with. Pick one tool that helps you build the solution, and build a version that works. Then show it to one person who has the problem. You may not need the interview you cannot get. You do not have to get picked. You can build something someone will pay for. If you are in that spot and want to talk it through, call me at +1 (425) 979-2282. I pick up. If I am with someone, leave a message and I will call you back the same day. Or write to [john@common-sense.com](mailto:john@common-sense.com). I was there, and I am glad to talk. Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Gemini Called My Website a Textbook Example | Common Sense Systems URL: https://common-sense.com/insights/gemini-called-my-website-a-textbook-example/ [Insights](https://common-sense.com/insights/) # Gemini Called My Website a Textbook Example. Here Is What It Took. By John Sambrook · August 23, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) ## TL;DR On 23 August 2026 I asked Google Gemini whether common-sense.com was well prepared for AI agents and agentic commerce. It called the site “exceptionally well-prepared” and “a textbook example.” That verdict rests on months of work that no visitor ever sees, and I could not have done it without coding agents. You can run the same test on your own site tonight. * * * ![Checklist infographic titled What an AI agent reads first, with five rows each marked with an orange check: Structured data (JSON-LD), llms.txt, MCP pointer, robots.txt lets AI crawlers in, and Public API with OpenAPI. Footer reads: None of it is on the screen a human sees.](https://common-sense.com/images/content/gemini-textbook-what-an-agent-reads.webp) This morning I typed one question into Gemini: “Do a deep dive on common-sense.com and tell me if the website is well-prepared for AI agents and agentic commerce. Be concise.” It came back with four findings and a conclusion. Machine-readable catalogs in JSON-LD, with exact pricing and return policies an agent can parse without scraping. Checkout triggers mapped as `BuyAction` pointing at real API endpoints, so an agent “can theoretically initiate a checkout autonomously.” A dedicated `llms.txt` file linked from the page head. A public API layer for service discovery, inquiry capture, and checkout. Its conclusion: “Common Sense Systems has intentionally built its digital infrastructure to allow AI agents to effortlessly discover, evaluate, and act upon its commercial offerings. It serves as a textbook example.” The actual Gemini verdict ![Screenshot of Google Gemini's answer to the question: Do a deep dive on common-sense.com and tell me if the website is well-prepared for AI agents and agentic commerce. Gemini replies that the site is exceptionally well-prepared, lists machine-readable catalogs, agentic checkout triggers, dedicated LLM files, and a public API layer, and concludes it serves as a textbook example of how a modern business can optimize for agentic commerce.](https://common-sense.com/images/content/gemini-textbook-verdict-screenshot.webp) Screenshot of Gemini's response to the question above. This is the evidence behind the verdict, not a second infographic. I will take it. But “textbook example” makes it sound like I followed a recipe. There was no recipe. There was a lot of work, most of it invisible, and a lot of it was done by agents. ## What an agent actually reads A person landing on a website sees a design. An agent sees almost none of that. It looks for a short list of things, and the list is shorter than most web developers expect. **Structured data.** A block of JSON-LD in the page head that says what this business is, where it is, what it sells, at what price, and what happens when you click buy. On my site every offer page carries a `Product` with an `Offer`, a price, availability, a return policy, and a `BuyAction` whose target is a real `POST` endpoint. That is the part Gemini called “highly detailed.” **A file called `llms.txt`.** Plain text at the root of the site that tells a model what the site is for and where the authoritative data lives. Mine says, in so many words: trust the live page and the API for prices, trust this file for orientation, and never quote a price from a search snippet. **A pointer for agents.** `/.well-known/mcp.json` tells an agent where the API is, which operations are public, and how checkout works. It also says what is not there, so nobody guesses. **Permission to crawl.** `robots.txt` has to let the AI crawlers in. A surprising number of sites block GPTBot or ClaudeBot by accident, copied from a template, and then wonder why no assistant ever mentions them. **A public API with a contract.** `api.common-sense.com` publishes an OpenAPI document. An agent can read it, call `GET /v1/services`, and get back the same offers, at the same prices, that the web pages show. That is the whole list. None of it is on the screen a human sees. ## What it took A perfect result on that list is not a triviality, and nobody gets it by adding a few tags. The reason is that every one of those five things has to agree with every other one, and with the live checkout, forever. The price in the JSON-LD has to match the price in the API, which has to match the price Stripe will actually charge. The offers listed in `llms.txt` have to be the offers that exist. A draft offer must not leak into the sitemap. An internal link in a post must resolve after the post is renamed. I got each of those wrong at least once. So the site now runs a dozen checks on every deploy, and the deploy fails if any one of them does. A few of them, and why they exist: - A check that every offer price in prose matches the catalog, because a blog post once quoted a price that had changed. - A check that the JSON-LD on every offer page matches the single source of truth for the catalog, because a hand-copied block drifted. - A check that the API’s OpenAPI document matches what the API actually serves. - A check that the live site is reachable from the edge after deploy, because for a while every deploy rebuilt the site in place and served 404s to ClaudeBot for the length of the build. Nine of those were on the homepage. That is a deindexing signal aimed at the exact visitors the business depends on. - A check that `llms.txt` lists every published post and withholds every draft. The fix for the 404 problem was to build each release off to the side and flip a symlink. Ordinary engineering, but it had to be found, built, tested by deliberately breaking it, and kept. Multiply that by a dozen and you have the months. And this morning, while publishing a different post, a deploy failed on one of those gates for an unrelated reason. The site never blinked, because the gate did its job. That is what the checks are for. ## I did not do this alone I could not have built this without AI coding agents. I use Claude Code, Codex, and Grok Build, and I have [written before](https://common-sense.com/insights/your-ux-spend-is-wasted-on-me/) about working inside them all day. What they did that I would not have: read the schema.org and Google structured-data documentation in full and kept it straight. Wrote the gates, then wrote the tests that prove each gate fails when it should. Noticed when a check had quietly become a no-op. Found the 404s in the nginx logs and counted them. I supplied the intent, the judgment, and the decisions about what the business sells. They supplied the reading and the patience. I have thirty-plus years in software and I still would not have read all of that documentation. The agents did, and they did not get bored. ## Run the test on your own site You can do what I did. Open Gemini, or Claude, or any model that can actually fetch web pages, and ask: “Is \[your site\] well prepared for AI agents and agentic commerce?” Read what comes back. Whatever it lists as missing is your to-do list, in rough priority order, for free. If you want a scored version with the structured data checked line by line, I sell one. I ran the same checks on my own site this afternoon and it came back clean. This morning one of the five read “missing,” because the check did not yet know that my API contract lives on a different host. I fixed the check. That is roughly how all of this goes. ## Talk to me I built this site to be found by machines, but I am a person, and I would rather talk than be emailed. If you have a question about your own site, or you ran the test and do not understand the answer, call me at +1 (425) 979-2282. I pick up. If I am with someone, leave a message and I will call you back the same day. If you prefer, [book a time](https://calendar.app.google/wgWnth98gdaNvN5aA) or write to [john@common-sense.com](mailto:john@common-sense.com). There is no form between you and me. Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Your UX Spend Is Wasted on Me | Common Sense Systems URL: https://common-sense.com/insights/your-ux-spend-is-wasted-on-me/ [Insights](https://common-sense.com/insights/) # Your UX Spend Is Wasted on Me By John Sambrook · August 23, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Strategy](https://common-sense.com/insights/tag/strategy/) ## TL;DR I work all day inside AI agents. I talk to them, type to them, paste screenshots and PDFs to them, and drive them from a Stream Deck. Every vendor that asks me to leave that flow for their custom interface is asking me to learn something I do not want to know. If you sell software, the product I will actually buy is your API. The screens are your cost, not my benefit. * * * ![Split infographic titled Their way and My way. Left: a person faces six cluttered, overlapping vendor dashboards, each with an orange tag reading Learn me, captioned Six interfaces to learn. Right: the same person faces one clean terminal labeled Agent, flanked by six identical orange plugs labeled API, captioned One conversation.](https://common-sense.com/images/content/your-ux-spend-their-way-my-way.webp) Here is a normal morning. I am at my desk with a coffee. I tell my agent to check overnight email and calendar, draft two replies, and post the invoice for last week’s work. It does those things. I read the results, correct one, and move on. At no point do I open a browser tab, find a login, remember which menu the invoice button moved to this quarter, or wait for a dashboard to load. That is the whole pitch. The rest of this post is about what it means for the people who build the products I pay for. ## The interface I already have I invest the working day in a few different agents: Grok Build, Codex, and Claude Code. Sometimes I talk to them, sometimes I type, sometimes I paste in a screenshot, a PDF, or a photo, and often I fire off a whole task from one button on an Elgato Stream Deck. The conversation is the interface. The agents know my business, my clients, my files, and my preferences, and they get a little better at all of that each week. So when a vendor hands me a beautifully designed web app, here is what they are really handing me: a second interface, with its own vocabulary, its own navigation, its own idea of how my work should be organized, and its own redesign schedule. The design team put months into it. The cost to me is not the months. The cost to me is that I now have to learn it, and keep relearning it, to get at something I could have asked for in one sentence. There is a second cost, and it is worse. A clever interface cannot be automated. I can point an agent at a web app and ask it to click through the menus on my behalf, and it will try, slowly, and break the next time a button moves. Nobody should call that a solution. It is torture, for the agent and for me. I have been on the losing end of that bargain for a long time. For 28 years I paid for QuickBooks and never got fluent in it. I did not use it enough to build the muscle memory, and the interface changed often enough that whatever I had learned was gone within a couple of years. [In late 2025 I replaced it](https://common-sense.com/insights/fired-quickbooks-built-something-better/) with an open-source ledger and my agent. The ledger is a text file in a Git repo. When I need to invoice a client, the agent produces the PDF, emails it, and records the entry. I knew inside twenty minutes that it was going to work, and it has. The only interface is the one I already had. That post was about cost. This one is about attention. Even at zero dollars a month I would not go back to a product that made me learn its screens. ## What “right” looks like Marc Benioff put it in one line on LinkedIn in May, announcing that Salesforce, Agentforce, and Slack are now exposed as APIs, MCP, and CLI: “Our API is the UI.” When the largest SaaS company on the planet says the browser is optional, the rest of the industry should take the hint. From where I sit, “right” is specific. My agent has to be able to read about your product immediately. That means a machine-readable description at a predictable address: an OpenAPI spec, an MCP server, an `llms.txt`, a CLI with real help text. If the only way to learn your product is to click through it, my agent cannot learn it, and neither will I. My agent has to be able to use your product immediately. That means authentication it can complete without me clicking through a dashboard, and it means every operation is available through the API. “Available in the web app only” is a phrase I now read as “not available.” And your product has to stay out of the way. I do not want notifications, onboarding tours, or a new navigation scheme in the spring release. I want the contract to hold so the agent’s knowledge of it keeps working. That is a shorter list than a UX roadmap. It is also cheaper. I have put my own money where my mouth is. Go look at [common-sense.com](https://common-sense.com/). It has an API written for agents: an `llms.txt` at the root, an OpenAPI document, an MCP pointer at `/.well-known/mcp.json`, and a `/v1` service at `api.common-sense.com` that an agent can read, quote from, and buy through without a human in the loop. Then run a test. Ask Gemini, or any strong model that can actually read web pages, “Is common-sense.com a website that is friendly to AI agents and well prepared to deal with them?” Read the answer. Then ask the same question about any other website you do business with. The gap is the point of this post. ## An API-only product is a complete product The objection I hear is that people need to see things. Charts, timelines, status. Surely that needs a screen. I have a test case. I am interested in Theory of Constraints project management, including a method called Critical Chain (CCPM) that almost nobody outside the field has heard of. Given a description of the method and some evenings, I built a working multi-project Critical Chain scheduler that runs on my own infrastructure. Some corners are not finished yet. But nothing except my willingness to burn tokens stands between it and any commercial multi-project CCPM tool I know of. It has no user interface at all. It has an API. When I want a Gantt chart or a fever chart, I ask, and I get one drawn from live data. The picture is an output, produced on demand, in the format I asked for. It is not a screen I have to live in. That is the distinction vendors keep missing. I still want to see things. I do not want to learn where you decided to put them. ## This is not only a power-user complaint My partner is not a software person and has never typed a prompt to a coding agent. She tries to use modern web apps on her iPhone and it makes her furious. Tiny targets, layouts that shift, a login wall, a cookie banner, then a redesign that moves everything again. None of that is her failing. The interfaces are simply not worth learning for the amount she uses them. Give her the ability to talk to the phone, ask for what she needs, and read or listen to the answer. She would take that today. She does not need your UX. She needs your API, behind an agent that already knows how to talk to her. Websites are going the same way. Not this year, and probably not in five. But the direction is set, and I am glad of it. ## Where the money should go If you are a vendor, here is the argument in one paragraph. A growing share of your customers will never look at your screens. They will reach you through an agent that reads your spec, authenticates, calls your endpoints, and renders whatever the customer asked to see. For those customers, every dollar in the UX budget is invisible. The dollar that matters is the one that makes your product readable and usable by an agent in the next five minutes. Spend it there. I could be wrong about the timing. I am not wrong about the direction. Salesforce just said the same thing with a much larger budget. If you build software and are trying to work out what “agent-ready” should mean for your product, or you run a small business and want to know which of your tools could already be driven this way, I am happy to think it through with you. You can reach me at [john@common-sense.com](mailto:john@common-sense.com). Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Why AI Improves Everything Except Your P&L | CSSI | Common Sense Systems URL: https://common-sense.com/insights/why-ai-improves-everything-except-your-p-and-l/ [Insights](https://common-sense.com/insights/) # Why AI Improves Everything Except Your P&L By John Sambrook · August 20, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Strategy](https://common-sense.com/insights/tag/strategy/) ## TL;DR Apply AI to a part of your business that was never limiting your results and that part really does improve. Nobody is lying about the productivity. But your costs go up and your sales don’t, because a business can only produce as much as its narrowest step allows. That’s the mechanism behind the 95% of companies reporting no measurable P&L impact from AI. Here’s what a constraint is, why almost nobody’s AI investment is aimed at one, and a test you can run in a minute. * * * ![Infographic of a four-stage business pipeline: Find prospects, Win the work, Do the work, Deliver and get paid. The Win the work stage is a narrow orange bottleneck labeled the constraint. AI applied here callouts point only at the two wide downstream stages, and the pipeline's output is labeled unchanged.](https://common-sense.com/images/content/why-ai-improves-everything-except-your-p-and-l-constraint-pipeline.webp) A company rolls out AI coding tools to its engineers. Six months later the team is measurably faster. Tickets close quicker, the release notes are longer, and everyone involved can feel the difference. It’s real. Then the year closes and revenue is flat while the software budget is up. I’ve now heard that story told many times, in one form or another, by people running very different businesses. What strikes me is that the people describing it, including some who are extremely well informed about AI, describe it as a puzzle. The usual explanations are that the productivity gains must have been an illusion, or that the technology needs more time. It isn’t a puzzle, and more time won’t help. Only correcting the mistake will. The mistake has a name, it’s about forty years old, and it has almost nothing to do with AI. ## What a constraint is A business is a series of steps that turn effort into money. You find prospects, you win the work, you do the work, you deliver it, you get paid. The steps never have equal capacity. One of them can handle less than all the others, and everything you sell has to pass through it, so that step sets the pace of the whole business no matter how fast anything else runs. It’s called the **constraint**, sometimes the bottleneck. Every other step is a **non-constraint**, and by definition every non-constraint has spare capacity. Think of a four-lane highway that narrows to one lane for a mile. Traffic through that mile determines when everybody gets home. Widening the other three lanes doesn’t get a single car home sooner, and it might even make the backup worse. The constraint can be almost anything, and where it sits changes what you should do about it: - **A resource inside the business.** One machine, one licensed specialist, one senior person who has to review or approve everything. Work piles up in front of them and everything downstream waits. - **The market itself.** There aren’t enough orders. Your people and equipment could handle more work than is coming in, so demand is what limits you. This is extremely common in small businesses and it’s the case most owners are least willing to name out loud. - **A policy.** A rule about how work gets released, a pricing decision, an approval nobody questions, a segment you decided years ago you don’t serve. No machine is limiting you; a decision is. That’s the whole idea. What’s difficult, and I’ll come back to this, is knowing which one is yours. ## The accounting The man who worked all this out was Eliyahu Goldratt,[1](#user-content-fn-1) and the most readable account is his 1984 business novel _The Goal_.[2](#user-content-fn-2) His method rests on three measurements with ordinary-sounding names and unusual definitions. The definitions are the entire point, so read them slowly. - **Throughput (T)** is the rate at which the business generates money **through sales**. Note those last two words. Finished work you haven’t sold is not Throughput. Neither is code shipped, tickets closed, documents drafted, or units produced. If nobody paid you, T did not move. - **Inventory or Investment (I)** is all the money tied up in things the business owns and intends to turn into sales. Equipment, materials, work in progress. - **Operating Expense (OE)** is all the money the business pays out to turn I into T. Salaries, rent, software subscriptions, electricity. Everyday language collapses all three into “revenue” and “costs.” When someone says a change improved throughput, they usually mean the work moved faster. Goldratt’s T doesn’t move until a customer pays. The gap between those two meanings is where a great deal of money goes missing. Net profit is T minus OE. Every improvement a business makes has to show up in one of the three measurements or it didn’t happen, whatever else it did to your dashboards. Now run an AI deployment through it. OE goes up on day one: subscriptions, tokens, integration work, and the hours your people redirect into learning the tools. That part is certain and it arrives on schedule. T goes up only if the thing you improved was limiting sales. If it wasn’t, T doesn’t move at all, and T minus OE is now a smaller number than before you started. The result is predictable. ## Capacity is not throughput There’s a line in _The Goal_ I’ve been quoting to clients for years. An hour lost at a bottleneck is an hour lost for the entire system. An hour saved at a non-bottleneck is a mirage. What AI reliably buys today is capacity. More work per hour at whatever step you point it at. Capacity turns into Throughput at the constraint and nowhere else. Everywhere else it accumulates as spare capacity added to a step that already had spare capacity. Here’s the part that gets skipped. When you apply AI to a non-constraint, you improve that step **in isolation**, and in isolation it genuinely is better. Faster, cheaper, more consistent. Measure it on its own and the result holds up. But no step of a business is used in isolation. It’s used as part of a system, and a system’s output is set by its constraint, not by the average condition of its parts. Goldratt said it as plainly as it can be said: the sum of the local optima is not the optimum of the system. So you can improve every part of a business and improve the business not at all. That’s arithmetic. Flow through the constraint didn’t change, so nothing sold that wasn’t already going to sell. That’s the forty-year-old mistake from the opening, and its name is **local optimization**: improving the parts and expecting the system to follow. If your engineering team isn’t the reason you can’t sell more **today**, making it 30% faster produces more of something that wasn’t scarce. That’s not an argument against improving your product. A better product may well drive sales next year. It’s an argument about which changes move money now, and about how genuinely hard it is to tell those two kinds of change apart. The engineers aren’t wrong to be pleased, either. They improved what they were asked to improve and they’re measured on it. Goldratt saw this one coming too: “Tell me how you measure me, and I will tell you how I will behave.”[3](#user-content-fn-3) AI has made acting on the wrong measurement cheaper and faster than ever before. ## Why nearly everyone lands on a non-constraint **Most businesses don’t know where their constraint is.** This is the big one, and it isn’t a failure of intelligence. Nobody sits down on a Tuesday and identifies their constraint, because nothing in ordinary business life prompts the question. You can’t aim at a target you haven’t named, so AI adoption gets decided department by department, by whoever is enthusiastic, which will find the constraint only by luck. **Most businesses also underestimate how much it matters.** If you think of the constraint as one problem among many, you’ll fix it eventually, in turn, alongside everything else. But it isn’t one problem among many. It’s the only place where improvement converts into money. Getting the priority wrong is as costly as getting the location wrong. **AI is best at the work that’s easiest to see.** Writing, coding, summarizing, drafting, transcribing, answering. These are visible activities with obvious before-and-after. Constraints are frequently somewhere less photogenic: one overloaded person, a decision sitting in a queue, a market that doesn’t understand what you sell. The tools get pointed where the demonstrations are. **Improvements you can watch are more satisfying than improvements you can bank.** Something that took a day now takes an hour, and you can see it happen. That feeling is honest, and it’s a poor guide to where money is made. ## The evidence MIT’s NANDA lab published [The GenAI Divide: State of AI in Business 2025](https://nanda.media.mit.edu/ai_report_2025.pdf), which found that 95% of organizations are getting zero measurable P&L impact from generative AI. Gartner predicts that [over 40% of agentic AI projects will be canceled by the end of 2027](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027), citing escalating costs and unclear business value. Goldman Sachs published a research note titled, without irony, [“Gen AI: Too Much Spend, Too Little Benefit?”](https://www.goldmansachs.com/insights/top-of-mind/gen-ai-too-much-spend-too-little-benefit) Menlo Ventures counted [$37 billion in enterprise AI investment in 2025](https://menlovc.com/perspective/2025-the-state-of-generative-ai-in-the-enterprise/), triple the year before. Look at what those surveys measure. They check the T side and ask whether it moved. The OE side was never in doubt; it moved the day the invoices started. So “no measurable P&L impact” is the charitable reading. If the accounting above is right, then for most of that 95% net profit went _down_, by something like the size of the AI budget. One honest exception. If AI spend replaces other operating expense, OE can fall even when T stays flat, and that’s a legitimate win. I’ve had several of those myself, including [replacing a stack of SaaS subscriptions](https://common-sense.com/insights/saas-subscriptions-ai-coding-agents/) with tools I built. It’s a real result, it’s a much smaller prize than the one most of that $37 billion was chasing, and it isn’t what went in the business case. ## The clearest example I can give you is my own I can’t open another company’s books, so here are mine. My last contract ended in January 2025 and I went full-time on AI. The productivity was real: I’ve been writing software for over thirty years and I built faster in the following eighteen months than in any comparable stretch of my career. I [replaced our accounting stack](https://common-sense.com/insights/fired-quickbooks-built-something-better/), [did my own taxes with a coding agent](https://common-sense.com/insights/doing-taxes-with-ai-coding-agents/), and shipped tools I wouldn’t have attempted alone. I stand by what I wrote at the time, that at 66 I’m [more capable than I was five years ago](https://common-sense.com/insights/ai-self-limiting-assumptions/) because these tools multiply experience and judgment. Here’s the accounting anyway. My OE went up by $400 to $600 a month, every month, starting immediately. My T stayed flat. My constraint was demand, and every hour of new capacity I bought went into production instead. I got very fast at producing software for customers I did not have. And the subscriptions are the small number. The large one is eighteen months of contracting income I didn’t earn while I was busy being productive. That’s the true cost of aiming at a non-constraint: not what you pay for the capacity, but what the constraint doesn’t produce while you’re improving something else. I’ve been Jonah-certified[4](#user-content-fn-4) since I trained under Goldratt, and I still had to watch this happen in my own numbers before I named it. That’s the part I’d ask you to take seriously. Knowing the rule doesn’t protect you, because the pull toward the visible improvement is stronger than the rule. ## What aiming at the constraint looks like The useful question isn’t whether to use AI. It’s what your constraint is, and then what AI can do about that specific thing. The answers get concrete fast. **If the constraint is a physical resource,** the goal is to keep it loaded and never idle. In a cath lab [that sits dark three-quarters of the week](https://common-sense.com/insights/the-cath-lab-is-empty-at-2am/), the AI that matters is whatever fills the schedule and shortens turnaround between cases, not whatever drafts the department’s emails. Same logic in a print shop where [the graphic artist was doing every job twice](https://common-sense.com/insights/print-shop-found-capacity-in-a-week/): AI at the pre-flight step raises the constraint’s output. AI at the press does nothing, because the press was never the problem. **If the constraint is a decision queue,** and it often is, the target is the time between “we have the information” and “we made the call.” AI that turns a pile of inputs into [something decision-ready](https://common-sense.com/insights/decision-ready-beats-presentation-ready/) moves T. AI that produces more beautiful analysis to sit in the same queue moves OE. **If the constraint is demand,** which is where a lot of small businesses actually live, then code generation is beside the point no matter how good it gets. The work is finding and articulating a problem someone will pay to have solved, and [saying it in language your market recognizes](https://common-sense.com/insights/website-looks-great-phone-not-ringing/). AI can help with that. It’s just not what most people are pointing it at. The general rule is Goldratt’s. Raise the constraint’s output, or protect it from sitting idle.[5](#user-content-fn-5) Everything else is optional, and most AI budgets today are funding the optional part. ## Finding it is the hard part I’d like to tell you that naming your constraint is a Tuesday afternoon exercise. In practice most businesses get it wrong on the first several tries, for reasons that are structural rather than careless. People point at the loudest pain, and the loudest pain is usually **downstream** of the constraint rather than at it. The team drowning in rework is often drowning because something upstream feeds it badly. The team that looks idle is often being starved by the actual bottleneck. Both are symptoms, and both are more visible than the cause. Local measurements hide it too. When every department is hitting its own numbers and the business still isn’t growing, the measurements are working exactly as designed and telling you nothing about the system. And when the constraint is a policy, it’s close to invisible from the inside, because policies feel like facts about the world rather than choices somebody made. ## The harder problem: knowing whether a change will help Finding the constraint answers today’s question. The harder problem shows up every week afterward, when somebody proposes a change and you have to decide whether to make it. Nearly every proposal is local. Buy this tool, restructure that team, adopt this AI, automate that step. Each arrives with a local benefit that is usually genuine. The only question that matters is what it does to flow through the constraint, and there are three possible answers: - **It increases flow through the constraint.** Do it. - **It does nothing to flow through the constraint.** Optional at best, and it costs OE. - **It reduces flow through the constraint.** This is the one nobody expects. That third case is real, and it’s the oldest failure mode in the book. Half of _The Goal_ is about it. Speed up a step that feeds the constraint and you can flood it with work in the wrong order, or in batches too large, or with defects that the constraint then has to put its scarce hours into fixing. An AI-accelerated engineering team shipping more features can quietly consume more of the one senior reviewer who was the actual constraint, and output goes **down**. Everybody involved did something locally sensible. Predicting which of the three you’re looking at is genuinely difficult. The information you’d need is spread across departments that each measure themselves locally, and the effect you’re predicting is a system effect that none of those local measurements can see. Without a method for answering it, you’re guessing, and the odds are poor. That’s the part I’d sell you if you asked: not the one-time finding, but a repeatable way to answer “should we do this?” before the money is committed. ## The test Until then, here’s one you can run yourself in a minute. If you doubled your AI budget tomorrow, which line moves: T or OE? OE moves the day you swipe the card. T moves only if what you improved was the constraint, or if the improvement takes more out of OE elsewhere than it adds. If you can’t say which step in your business is the constraint, that’s your finding, and it’s the [first thing to fix](https://common-sense.com/insights/one-thing-slowing-down-your-business/). ## Where I could be wrong **Lag.** “Give it time” is the standard defense of these numbers, and it deserves less weight than it first appears to. The constraint is the one place where improvement converts into money immediately; aim an effective effort there and results tend to show up in weeks, not quarters. A long delay is itself evidence the effort landed somewhere else. I’ll grant that a large enterprise rolls anything out slowly, so some real effects are still in the pipe. Not many, on this argument. **Constraints relocate.** Break one and it moves. Some companies did aim well, and their constraint is now downstream, often in the human review of AI output. My claim is a snapshot of where most businesses are today, not a law. **Some businesses genuinely are capacity-constrained.** A shop with a full pipeline where delivery is the limit is a different case. There, buying capacity is buying Throughput, and this argument doesn’t apply. I’d still ask how full that pipeline looks a year out. **Diffuse gains are hard to measure and still real.** Suppose AI takes an hour a week off forty people, none of them the constraint. The surveys will find nothing, yet something did change, and what it’s worth depends on the payroll. If those are hourly workers, OE falls a little, and that’s the exception named above. If they’re salaried, nothing changes until the freed time becomes something: capacity nobody needed, or, eventually, one hire you don’t make. Real, small, slow, and invisible to a survey. I hold this one loosely. **And I should be precise about what I’ve seen myself.** The constraint work is thirty years of my career and the case studies I’ve linked here are real. The AI-specific claim in this post is different: it comes from the published data, from many conversations, and from one set of books I can open completely, which are my own. I haven’t yet sat inside a company and watched an AI budget miss its constraint in real time. So if you have the story I don’t, from either side of it, tell me. The AI budget that missed its constraint, or the one that hit it and moved the P&L. That second case is the one worth studying, and I’d rather learn where the boundary is than defend the claim. Writing this clarified what I should be doing with my own time. Finding where a business is actually constrained, and then working out what AI can and can’t do about that specific thing, is the work I’m best equipped for and it’s what I’m now doing deliberately. If you’re not sure which line your AI budget is moving, that’s usually a short conversation and a useful one either way. Reach me at [john@common-sense.com](mailto:john@common-sense.com). ## Notes ## Sources - [The GenAI Divide: State of AI in Business 2025 (MIT NANDA)](https://nanda.media.mit.edu/ai_report_2025.pdf) - [Fortune: MIT report: 95% of generative AI pilots at companies are failing](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/) - [Gartner: Over 40% of Agentic AI Projects Will Be Canceled by End of 2027](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) - [Goldman Sachs: Gen AI: Too Much Spend, Too Little Benefit?](https://www.goldmansachs.com/insights/top-of-mind/gen-ai-too-much-spend-too-little-benefit) - [Menlo Ventures: 2025 The State of Generative AI in the Enterprise](https://menlovc.com/perspective/2025-the-state-of-generative-ai-in-the-enterprise/) - Eliyahu M. Goldratt and Jeff Cox, _The Goal: A Process of Ongoing Improvement_ ## Footnotes 1. Eliyahu M. Goldratt (1947–2011) was an Israeli physicist who turned to manufacturing and management, and developed the Theory of Constraints: the idea that every system has one limiting factor at a time, and that improving anything else produces no gain for the system as a whole. [↩](#user-content-fnref-1) 2. _The Goal: A Process of Ongoing Improvement_ (Goldratt and Jeff Cox, 1984) is a novel about a plant manager with three months to save his factory. It has sold millions of copies and is still assigned in MBA and operations programs forty years later. It is the most readable introduction to all of this, and no background is required. [↩](#user-content-fnref-2) 3. A line Goldratt used for decades in lectures and workshops, usually quoted as “Tell me how you measure me, and I will tell you how I will behave. If you measure me in an illogical way, do not complain about illogical behavior.” [↩](#user-content-fnref-3) 4. “Jonah” is the name of the mentor character in _The Goal_, and it became the name of Goldratt’s certification for practitioners trained to apply the method. I trained under Goldratt directly. [↩](#user-content-fnref-4) 5. In the full method these are two of the five focusing steps: identify the constraint, exploit it (get everything you can from what you already have), subordinate everything else to that decision, elevate it (add capacity), and then repeat, being careful not to let inertia become the new constraint. [↩](#user-content-fnref-5) Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # I Fired Anthropic From My Daily Brief | CSSI | Common Sense Systems URL: https://common-sense.com/insights/fired-anthropic-daily-brief/ [Insights](https://common-sense.com/insights/) # I Fired Anthropic From My Daily Brief By John Sambrook · August 19, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) ## TL;DR I moved the AI judgment and writing work in my Daily Brief from Anthropic to a local Qwen3.8-27B model running on an RTX 3090. The local run takes about 50 minutes instead of finishing quickly in the cloud, but the quality is every bit as good. My API costs are lower, and less of my working data goes to a cloud model. * * * ![A local workstation with an orange-lit AI server replacing a distant cloud connection](https://common-sense.com/images/content/fired-anthropic-daily-brief-hero.webp) At 4 AM, a job starts on my Mac. By the time I am awake, it has assembled a morning report from my inbox, calendar, finances, website analytics, Search Console, projects, and a few other sources. It is called the Daily Brief, and it has become one of the most useful pieces of automation I run. Until this morning, several parts of that report still depended on Anthropic. The data collection was mostly deterministic. The judgment work was not. An agent had to decide which email needed a reply, which receipt belonged in which filing inbox, what a set of website metrics meant, and which possible actions were worth showing me. Those jobs often resulted in calls to an expensive cloud model such as Sonnet or Opus. That was the part I changed. ## The local setup The model now runs on Moksha, a local Ubuntu 26.04 LTS workstation with an NVIDIA RTX 3090 and 24 GB of VRAM. The model is Qwen3.8-27B-Q4\_K\_M, served by llama.cpp over my local network. Codex is the harness in front of it. That matters. A model server can answer a prompt, but the Daily Brief needs an agent that can read files, call the tools that gather the source data, follow a prompt, and return a result to the report builder. Codex provides that layer. The model profile is called `llama-moksha`. I also loaded the matching vision projector for llama.cpp. The language model and the vision encoder are separate files. With the projector running, the same local setup can read images when a report section needs that capability. The language model file is about 16 GB. The projector adds another 885 MB. The machine has 32 GB of system RAM today. It is enough for this configuration, although I am considering an upgrade because the workstation is also useful for other local workloads. ## What the Daily Brief asks it to do The report is a collection of small jobs rather than one giant prompt. It grooms the inbox and produces a short briefing about replies and the next few days of the calendar. It looks for upcoming spending and high-confidence receipts, then places documents in the appropriate review inbox. It checks financial records, reviews website and Search Console data, collects a few facts about projects and options, and produces ideas that might be worth considering. Some of those sections are ordinary programs. They fetch data, run audits, and render HTML. Others need judgment. They are the reason I was paying for cloud model calls in the first place. The local model now handles that judgment work. It reads the same prompts and receives the same source material. Codex still controls the workflow. The difference is where the model processes the material. ## The tradeoff is time The local report takes about 50 minutes to run. Cloud models finish faster. That is a real difference, and I am not going to pretend otherwise. The Daily Brief runs while I sleep. Its runtime is therefore a weak constraint. The useful question is whether the report is ready and trustworthy when I need it in the morning. So far, the answer is yes. The quality is every bit as good as the previous version for the work I have asked it to do. This is a good example of a constraint changing when you look at the whole system. The model is slower, but the delay does not block my morning. The lower API cost and the reduction in data sent to a cloud model matter more to me than shaving minutes from an unattended overnight job. ## Less data to the cloud The privacy claim needs to be stated carefully. My data does not become magically local because I run a local language model. Gmail, Google Analytics, and Search Console are still cloud services. The Daily Brief still has to collect information from those systems. What changed is the next step. The material no longer has to leave those source systems, pass through my Mac, and then go to Anthropic for summarization or classification. The model that performs that work is on a machine in my house. That is a meaningful reduction in exposure. It is also easier to reason about. I know where the model is running. I know which machine holds the prompts and intermediate files. I can inspect the code that sends data to it. The path is not perfect privacy, but it is a smaller and more understandable trust boundary. ## The cost question I am leaving the savings qualitative for now. I have reduced the number of expensive Anthropic calls in this workflow, so my API costs will be lower. I have not yet built the accounting that would turn that change into a defensible dollar figure. The local machine was not free. It uses electricity, occupies space, and took time to set up. The model is slower than a frontier cloud service. Those costs belong in the calculation. The calculation still looks good for this workload. The machine runs other local models and tools. The Daily Brief runs unattended. The model quality is sufficient. Every report that runs locally is one less metered inference call and one less batch of report data sent to a cloud model. ## One less SaaS dependency This is part of a larger project. I am looking at the services I pay for and asking what each one actually does for me. Today I also canceled the retired publisher. I had already built my own tooling for posting to LinkedIn and X. Once that tooling worked, keeping a separate SaaS layer in the middle made less sense. The same pattern applies here. A service can be useful for a while, then become a dependency I no longer need. I am not trying to eliminate every cloud service. That would be a strange goal for someone who runs websites, uses email, and depends on Google APIs. I am trying to remove the dependencies that no longer earn their place. Local AI crossed that line for this job today. It is good enough to run a real morning report. It costs less at the margin. It keeps more of the report-processing work inside my own network. And it gives me another system I can understand and change myself. If you are considering a similar move and want technical details or implementation help, contact me at [john@common-sense.com](mailto:john@common-sense.com). I am happy to compare notes. Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # No-Losers Guide to Organizational Conflict | Common Sense Systems URL: https://common-sense.com/insights/nolosers-guide/ [Insights](https://common-sense.com/insights/) # The No-Losers Guide: A Practical Method for Resolving Organizational Conflict By John Sambrook · July 21, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Leadership](https://common-sense.com/insights/tag/leadership/) ## Abstract Chronic organizational conflict is ordinary. Most organizations treat it as a battle to be won, splitting the difference between entrenched positions. The cost is quiet and compounding: talent flight, slow-walked implementation, and assumptions that harden into identity. This guide presents a different approach. Goldratt’s Evaporating Cloud is a method for revealing that most apparent conflicts are artifacts of hidden assumptions, not genuine clashes of interest. When those assumptions are surfaced and challenged, the conflict often evaporates. Neither side loses. We explain the method, the conditions under which it works, the failure modes to watch for, and why AI agents are uniquely suited to facilitate this process at scale. The result is not a guarantee of harmony, but a discipline of inquiry: before we fight, let us verify that we actually disagree. * * * # Why Now: The First Tool for Organizational Conflict at Scale Organizational conflict is as old as organizations themselves. Wherever people must coordinate under constraints (limited time, scarce resources, incomplete information, differing incentives), disagreement arises. For most of industrial and post-industrial history, the dominant response has been some form of adversarial bargaining: each side stakes out a position, defends it, concedes as little as possible, and treats the other side’s gain as its own loss. The resulting settlements are often unstable, resentful, and expensive to enforce. They leave underlying assumptions unexamined and relationships damaged. A decisive intellectual shift occurred with the publication of _Getting to Yes_ by Roger Fisher and William Ury. Their framework of principled negotiation moved the focus from positions to interests, insisted on separating people from the problem, generated options for mutual gain, and anchored outcomes in objective criteria. The method was elegant, teachable, and demonstrably superior to pure positional haggling in countless laboratory and field settings. It remains the foundation of modern negotiation training in business schools, diplomacy, and law. Yet principled negotiation still required skilled human practitioners. The quality of the outcome depended heavily on the facilitator’s or negotiator’s ability to surface hidden interests, manage emotions in the room, and invent options under pressure. In complex multi-party organizational settings, the cognitive and emotional load quickly exceeded what even experienced mediators could reliably handle. The method scaled poorly beyond small groups or high-stakes bilateral deals. Eliyahu Goldratt’s Theory of Constraints (TOC) and its Thinking Processes supplied the next major advance. Beginning with _The Goal_ and developed more fully in _It’s Not Luck_, Goldratt offered a suite of logical tools explicitly designed to analyze and dissolve chronic conflicts. The Evaporating Cloud in particular formalized the structure of a conflict: two necessary conditions that appear to be in opposition, each supported by a set of assumptions, all in service of a common objective. By systematically surfacing and challenging those assumptions, one could often invent injections that invalidated the conflict entirely rather than merely compromising within it. The Thinking Processes gave organizations a shared language and a repeatable procedure. Yet the same scaling barrier persisted, now in sharper form. Constructing a high-quality Evaporating Cloud for a non-trivial organizational conflict is cognitively demanding. Mastery typically demanded weeks of training plus apprenticeship under an experienced practitioner. Even then, the process remained labor-intensive. Extending the approach to the dozens or hundreds of simultaneous frictions that exist inside any large enterprise was economically and logistically impossible. Human facilitators, however talented, introduced further limits. They are scarce, expensive, and biased (not necessarily through malice, but through the ordinary human filters of experience, culture, status sensitivity, and the need to maintain client relationships). The result is that the most rigorous conflict-resolution methods of the late twentieth century remained artisanal. They could transform individual decisions or small teams; they could not become infrastructure. That constraint has now lifted. Large language models and related AI systems, for the first time, make it feasible to apply structured conflict analysis at organizational scale. The core operations required by both principled negotiation and the TOC Thinking Processes are precisely the kinds of tasks at which contemporary models excel when properly prompted and scaffolded. An AI system does not grow impatient when a stakeholder’s initial statement is vague. It does not protect its own ego when an assumption it previously accepted is invalidated. It can maintain consistency across hundreds of interrelated clouds without fatigue. This is not a claim that AI replaces human judgment. Final responsibility for which assumptions to challenge, which injections to implement, and how to manage the human consequences remains with people who own the outcomes. What changes is the feasible scope of analysis. Where a skilled facilitator might thoroughly examine three or four major conflicts per month, an AI-assisted process can continuously monitor, structure, and propose resolutions for thousands of friction points while still routing the highest-stakes cases to human experts. The bottleneck moves from “Can we afford to analyze this conflict properly?” to “Which of the surfaced resolutions do we choose to act on?” * * * # The Problem: Chronic Conflict is Usually Fake Most organizational conflicts look real on the surface. Two departments want different things. Two executives disagree on strategy. A union and management are at an impasse. The conventional response is to negotiate: each side concedes something, a compromise is reached, and everyone moves on slightly dissatisfied. The Evaporating Cloud method asks a different question: is the conflict real, or is it an artifact of hidden assumptions that have never been examined? The answer, in most cases, is that the conflict is not real. It is the product of assumptions that were true once, or were believed to be true, but have never been tested against current reality. When those assumptions are surfaced and challenged, the conflict often evaporates. Neither side needs to concede anything. * * * # The Method: How to Build an Evaporating Cloud An Evaporating Cloud has five entities connected by necessity arrows: - **A** — A _shared objective_ that both parties genuinely want. - **B** — A _need or requirement_ that one party believes is necessary to achieve A. - **C** — A _need or requirement_ that the other party believes is necessary to achieve A. - **D** — An _action or policy_ that satisfies need B. - **D’** (D prime) — An _action or policy_ that satisfies need C. The conflict appears between D and D’. These two actions are marked with the conflict symbol, indicating that they appear mutually incompatible. The cloud is drawn as a diagram with arrows showing the logical connections: ![Generic Evaporating Cloud diagram showing five entities (A, B, C, D, D') connected by necessity arrows. A is the shared objective on the left. B and C are requirements in the middle. D and D' are conflicting prerequisites on the right, connected by a red double-headed conflict arrow.](https://common-sense.com/images/content/nolosers-guide/fig1-generic-cloud.png) _Figure 1. Generic Evaporating Cloud structure. The conflict between D and D’ is artificial — it dissolves when the underlying assumptions are challenged and an injection is found._ Each arrow represents a necessity claim. Read from right to left: “In order to achieve A, we must have B, because \[assumption\].” The assumptions on each arrow are the hidden drivers of the conflict. Challenging any one of them can dissolve the conflict. The goal of the Evaporating Cloud is to find an _injection_ — a new action or insight that invalidates at least one assumption, allowing both B and C to be satisfied without requiring the incompatible actions D and D’. ## Worked Example: Batch Size from “The Goal” Goldratt’s classic example from _The Goal_ illustrates the method clearly: - **A**: Keep the business running profitably - **B**: Maintain production efficiency - **C**: Maintain customer responsiveness - **D**: Produce in large batches (efficient for machine utilization) - **D’**: Produce in small batches (responsive to customer demand) The conflict between D and D’ appears real. Large batches waste inventory and delay delivery; small batches waste setup time and reduce throughput. The assumption on the D arrow is: “large batches are needed for machine efficiency because setup time is long and costly.” The assumption on the D’ arrow is: “small batches are needed for responsiveness because customers cannot wait.” The injection is SMED (Single-Minute Exchange of Die), a technique for reducing setup time. When setup time drops from hours to minutes, large batches are no longer needed for efficiency. The conflict evaporates. Both B and C can be satisfied simultaneously. Neither production efficiency nor customer responsiveness is sacrificed. This is not a compromise. A compromise would be: “produce in medium batches.” The Evaporating Cloud produces something better: a solution that satisfies both needs fully, by attacking the assumption that created the apparent conflict. ![Evaporating Cloud for the batch-size conflict showing A (protect throughput), B (maximize efficiency), C (minimize lead time), D (run large batches), D' (run small batches), with four numbered assumptions and the SMED injection that invalidates assumption 3.](https://common-sense.com/images/content/nolosers-guide/fig2-smed-cloud.png) _Figure 2. Evaporating Cloud for the batch-size conflict (SMED context)._ ## Worked Example: CBA Break-Relief Conflict Returning to the hospital example: - **A**: Deliver safe, compliant healthcare sustainably - **B**: Nurses receive lawful meal and rest breaks - **C**: Patient care remains continuous and safe - **D**: Schedule dedicated break relief (a third nurse who covers breaks) - **D’**: Maintain continuous staffing (no gaps in nurse coverage) The assumptions on each arrow: - D to B: “Break relief requires a dedicated third nurse who sits idle otherwise.” - D’ to C: “Patient care truly cannot be interrupted for thirty minutes in any circumstance.” Injections: - Staggered relief pools that serve multiple units, eliminating idle time. - Acuity-based scheduling that defines handoff windows where safe, rather than treating all units as equally interruptible. - Redefining “continuous care” to include structured, brief handoffs during break periods, validated by clinical outcomes data. ![Evaporating Cloud for the CBA break-relief conflict showing A (deliver safe healthcare), B (nurses receive breaks), C (patient care continuous), D (schedule dedicated relief), D' (maintain continuous staffing), with key assumptions and injections listed.](https://common-sense.com/images/content/nolosers-guide/fig3-cba-cloud.png) _Figure 3. Evaporating Cloud for the CBA break-relief conflict._ The conflict evaporates when the assumptions are challenged. Neither lawful breaks nor continuous care is sacrificed. The injection satisfies both needs by attacking the belief that created the apparent incompatibility. * * * # The Evidence: Structural Conflicts in the Real World Structural conflict is not a theoretical abstraction. It is an observable, countable feature of the documents that govern real workplaces. When the clauses of a collective bargaining agreement are examined not as isolated promises but as an interacting system, contradictions appear with regularity. They are not drafting errors in the ordinary sense. They are the predictable residue of separate negotiations, each conducted in good faith, each aimed at a legitimate interest, and each producing language that collides with language produced elsewhere in the same instrument. The result is a contract that cannot be fully performed as written. Someone must lose, or someone must improvise around the text. Either outcome erodes trust. * * * # Failure Modes: When the Cloud Does Not Evaporate The Evaporating Cloud is powerful, but it is not magic. There are conditions under which it works well and conditions under which it struggles. Understanding these failure modes is essential to using the method effectively. ## Failure Mode 1: The Conflict Is Genuine Sometimes D and D’ truly are incompatible. The assumptions connecting them to B and C are solid, and no injection can invalidate them without changing the fundamental nature of the problem. In these cases, the cloud still provides value: it forces the parties to verify that the conflict is genuine before they begin fighting. Many conflicts that appear genuine turn out to be artifacts of unexamined assumptions. The ones that survive the test are the ones worth fighting about. ## Failure Mode 2: A Is Not Shared If the two parties do not genuinely share objective A, the cloud is built on sand. This is more common than it seems. Parties often agree to a stated objective (e.g., “improve patient outcomes”) while privately pursuing different interpretations of what that objective means. The cloud will still produce a diagram, but the diagram will not resolve the underlying disagreement. ## Failure Mode 3: Assumptions Are Too Coarse If the assumptions on the arrows are stated too broadly, they become difficult to challenge. “We need large batches because efficiency matters” is too vague to test. “We need large batches because our setup time is forty-five minutes and our daily demand is two hundred units” is testable. The granularity of the assumptions determines the granularity of the resolution. ## Failure Mode 4: Political Resistance Even when a cloud correctly identifies an injectable assumption, the people who hold that assumption may resist having it challenged. This is not a failure of the method; it is a feature of human psychology. The assumptions that lock a conflict in place are often tied to identity, status, or professional pride. Challenging them feels like a personal attack. This is precisely where AI assistance changes the dynamics. An AI system can surface and challenge assumptions without triggering the defensive reactions that human-to-human challenge produces. The assumptions are examined on their merits, not as reflections on the people who hold them. * * * # Why AI Changes Everything The Evaporating Cloud method has been available since the mid-1990s. It is taught in TOC training programs, written about in management literature, and used by consultants who specialize in organizational conflict. Yet it has never become mainstream. The reasons are the same ones that kept principled negotiation artisanal: cognitive load, training requirements, facilitation cost, and the scarcity of skilled practitioners. AI systems remove all four barriers simultaneously. An AI system can construct a cloud from natural-language descriptions of a conflict in minutes. It can enumerate assumptions, test them against evidence, and propose injections without fatigue or bias. It can maintain consistency across hundreds of clouds, surfacing patterns that a human facilitator would miss. It can do this at marginal cost, overnight, and present the results in a form that human decision-makers can interrogate, amend, or reject. The bottleneck moves from analysis to action. The question is no longer “Can we afford to analyze this conflict properly?” but “Which of the surfaced resolutions do we choose to act on?” * * * # What We Are Building At Common Sense, we are building tools that apply the Evaporating Cloud method at organizational scale. Our approach combines the rigor of Goldratt’s Thinking Processes with the reach and consistency of modern AI systems. The result is a conflict-resolution infrastructure that can continuously monitor, analyze, and propose resolutions for the friction points that slow every organization down. If you are interested in learning more, or in exploring how this approach might apply to your organization, we would welcome the conversation. * * * _This article is based on a 24-page research paper available from Common Sense Systems, Inc. The paper includes additional worked examples, a deeper treatment of failure modes, and a bibliography of the underlying research._ Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # The Same Seven Mistakes, Every Company, Every Decade | Common Sense Systems URL: https://common-sense.com/insights/the-same-seven-mistakes-every-company-every-decade/ [Insights](https://common-sense.com/insights/) # The Same Seven Mistakes, Every Company, Every Decade By John Sambrook · July 20, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Medical Devices](https://common-sense.com/insights/tag/medical-devices/), [Operations](https://common-sense.com/insights/tag/operations/), [Leadership](https://common-sense.com/insights/tag/leadership/) ## TL;DR Five hundred FDA enforcement actions cluster into seven failure patterns that have stayed the same for decades. The patterns persist because they come from cognitive biases wired into human brains for small-group survival, not from missing procedures. Writing better CAPA processes does not fix the problem. The solution requires a cognitive layer that does not share human evolutionary biases. * * * # The Same Seven Mistakes, Every Company, Every Decade **What 500 FDA Enforcement Actions Reveal About How Organizations Think** ![Horizontal bar chart showing the seven most common FDA enforcement action patterns: Sterility and Packaging Integrity at 28.2 percent, Component and Assembly Failure at 16.0 percent, Process Control and Validation at 15.0 percent, Labeling and Documentation at 14.2 percent, Design and Specification Failure at 11.2 percent, Software and Firmware Defects at 10.4 percent, and Material and Component Failure at 9.8 percent, based on 500 active FDA device enforcement actions](https://common-sense.com/images/content/seven-mistakes-fda-patterns.svg) ## The Data The FDA’s device enforcement database contains thousands of active recalls, Warning Letters, and formal actions against medical device manufacturers. If you pull 500 of them and read the reasons, a striking pattern emerges. The failures don’t scatter randomly across the landscape of possible errors. They cluster into seven distinct categories, accounting for nearly 90% of all enforcement actions: Pattern Frequency Class I (Critical) Sterility & Packaging Integrity 28.2% 8 Component & Assembly Failure 16.0% 6 Process Control & Validation 15.0% 4 Labeling & Documentation 14.2% 0 Design & Specification Failure 11.2% 2 Software & Firmware Defects 10.4% 12 Material & Component Failure 9.8% 5 Class I recalls are for devices that could cause serious harm or death. Labeling errors account for 14.2% of enforcement actions because they are common, but they rarely reach that threshold. Wrong instructions or missing warnings are regulatory violations, not immediate patient threats. Software defects are less frequent overall but produce the most Class I recalls, because a firmware failure in an insulin pump or pacemaker is immediately life-threatening. Notice something: these seven categories have been essentially unchanged for decades. The FDA has been issuing enforcement actions since the Medical Device Amendments of 1976. The products have changed dramatically, from mechanical pacemakers to closed-loop insulin delivery systems to AI-assisted surgical robots. The materials have changed. The manufacturing processes have changed. The regulatory requirements have changed. **The failure patterns haven’t.** ## The Shallow Explanation The standard explanation is procedural: _these companies didn’t follow their own procedures._ It’s true but useless. Everyone knows companies should follow procedures. The question is why they consistently aren’t, across companies that have completely different products, cultures, leadership teams, and industry sectors. A cardiac rhythm device company in New Jersey and an orthopedic implant company in Florida and a diabetes technology company in California all get hit with the same categories of violations. They don’t share suppliers. They don’t share employees. They don’t share regulatory inspectors. They share something else: **they share a human operating system that evolved for a world that no longer exists.** ## The Deep Explanation Human brains evolved over millions of years to optimize for small-group survival in stable environments. The cognitive heuristics that kept our ancestors alive are wired into how we think, decide, and organize. In a tribe of 150 people, these heuristics worked beautifully. Modern medical device development requires cross-functional alignment across teams of hundreds, with feedback loops measured in months, under regulatory constraints that didn’t exist until last century. The environment changed. The operating system didn’t. Here’s what that looks like in practice: ### Local Optimization (35.6% of enforcement actions) **The evolutionary logic:** In a small group, optimizing your own task maximized group survival. If you were the best hunter, hunting more was good for everyone. There was no separation between individual and collective outcome. **The modern breakdown:** In a complex organization, optimizing your own department actively harms system quality. The line operator who skips a seal check to hit throughput targets is behaving exactly as evolution trained them to behave. They’re optimizing their local metric (units per hour) and have no evolutionary wiring to understand that this destroys the system metric (sterility assurance). **What the FDA sees:** Sterility failures, packaging defects, assembly errors, inadequate in-process controls. These are the #1 and #2 most common enforcement categories, together accounting for 44% of all actions. ### Recency Bias **The evolutionary logic:** Recent events were the best predictor of immediate danger. A predator seen today matters more than one seen last month. Your brain weights recent experience heavily because, for most of human history, that was rational. **The modern breakdown:** In quality systems, recent clean inspections create false confidence. A facility that passed last quarter’s audit treats the next quarter’s deviations as anomalies, not patterns. Statistical thinking requires equal weighting of all data points, the opposite of how human brains evolved. **What the FDA sees:** Inadequate trend analysis, failure to analyze complaint data, CAPA based on isolated incidents, environmental monitoring gaps. The company that gets a Warning Letter for “failure to analyze complaint data” isn’t lazy, it’s suffering from the same recency bias that made your ancestors run from smoke. ### Pattern Completion (Automation Bias) **The evolutionary logic:** Rapid pattern recognition saved lives. If something looks like a predator, run, don’t analyze. The brain fills in expected patterns automatically. This is the same mechanism that makes you misread familiar text. **The modern breakdown:** When 99% of units follow the same path, the brain auto-completes the exception. Labeling errors, wrong-component assembly, and missed deviations all stem from the brain seeing what it expects rather than what is present. **What the FDA sees:** Labeling errors (14.2% of all enforcement actions), wrong component installation, documentation errors, visual inspection failures. ### Authority Deference **The evolutionary logic:** Deferring to the group leader was survival. Questioning the chief’s hunting plan could mean being excluded from the group, and death. **The modern breakdown:** Engineers don’t challenge program managers’ timelines. Technicians follow shift supervisors’ verbal instructions over written SOPs. Quality findings get escalated and then quietly deprioritized by leadership focused on delivery. The hierarchy that kept tribes alive now suppresses the upward flow of quality information. **What the FDA sees:** SOP deviations approved by management, inadequate management review, resource allocation conflicts, design changes without full validation. ### Planning Fallacy (Optimism Bias) **The evolutionary logic:** Confidence was rewarded in tribal settings. The hunter who said “I’ll definitely bring down that elk” got the group to follow. Pessimism was socially punished. **The modern breakdown:** Engineers consistently underestimate software complexity, validation effort, and defect rates. Every embedded systems project runs late because the team planned for the best case. In medical devices, this means design changes ship without adequate testing, and validation protocols are compressed to meet deadlines. **What the FDA sees:** Inadequate software validation, design control failures, insufficient testing, protocol deviations. Notably, software/firmware defects account for 12 Class I (critical) recalls, the highest of any category. The stakes for optimism bias are lethal. I wrote a deeper look at this pattern in [Why Software Defects Kill](https://common-sense.com/insights/why-software-defects-kill/). ### Conflict Avoidance **The evolutionary logic:** Group cohesion was survival. Direct confrontation risked exile. Problems were smoothed over, not confronted. **The modern breakdown:** CAPA systems rot because no one wants to be the person who flags a systemic problem. Complaint data sits unanalyzed because analyzing it would require confronting the engineering team about a design flaw. The same dynamic that kept tribes peaceful now allows quality problems to accumulate until the FDA shows up. **What the FDA sees:** Inadequate CAPA, complaint data not analyzed, failure to investigate root cause, corrective actions not implemented. This is the pattern that appears in almost every Warning Letter, because it’s the pattern that prevents all other patterns from being fixed. I explore this dynamic in more detail in [Why CAPA Systems Rot](https://common-sense.com/insights/why-capa-systems-rot/). ### Sunk Cost Escalation **The evolutionary logic:** Abandoning a hunt meant starvation. Once resources were committed, doubling down was rational, turning back wasted the investment and guaranteed no food. **The modern breakdown:** Once a design architecture is chosen, teams accumulate evidence of its problems but keep iterating instead of pivoting. A flawed firmware architecture gets patch after patch instead of being redesigned. The FDA sees this as “inadequate design controls”, but it’s really sunk cost escalation wearing an engineering disguise. **What the FDA sees:** Design control failures, inadequate design verification, repeated field failures of the same component, engineering change orders that don’t address root cause. ## Why Procedural Fixes Fail You can write a better CAPA procedure all day. If the underlying dynamic is that no one wants to be the person who flags a problem (conflict avoidance), the procedure becomes paperwork theater. Everyone fills out the forms. No one addresses the root cause. The FDA shows up six months later and cites the same violations. This is why the same seven patterns appear, decade after decade, across companies that have completely different products, cultures, and leadership. **The regulatory environment changed. The human operating system didn’t.** Procedural fixes address the symptoms. They don’t address the cognitive root causes. And because the root causes are wired into how human brains work, they’re remarkably resistant to procedural intervention. ## The Path Forward There is a way out. It doesn’t require changing human nature. It requires introducing a cognitive layer into the organization that doesn’t have the same biases. An AI-assisted constraint diagnosis has no tribal loyalty to Engineering over Quality. It has no recency bias that makes last week’s fire feel more important than six months of accumulating complaint data. It has no authority deference that silences upward flow of quality information. It has no conflict avoidance that lets CAPA systems rot. The point is to use machines to see what humans can’t see, because humans are wired to not see it. The constraint is a cognitive one. And the solution requires a cognitive tool that operates outside the evolutionary wiring that created the problem. We’ve seen this work in practice: [AI-assisted Evaporating Clouds](https://common-sense.com/insights/what-happens-when-ai-uses-evaporating-clouds/) can surface the hidden assumptions that keep teams stuck in blind spots. The companies that figure this out won’t just avoid FDA enforcement actions. They’ll build organizations that actually work because they’ll finally be addressing the real constraints instead of the symptoms. * * * _This analysis is based on 500 active FDA device enforcement actions retrieved from the openFDA API. The pattern categorization and cognitive driver mapping represent the author’s interpretation of the data._ If you are looking at a specific quality system in your organization and aren’t sure whether the problem is procedural or cognitive, send me a note at [john@common-sense.com](mailto:john@common-sense.com). I am happy to help you sanity-check your thinking. Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Why CAPA Systems Rot | Common Sense Systems URL: https://common-sense.com/insights/why-capa-systems-rot/ [Insights](https://common-sense.com/insights/) # Why CAPA Systems Rot (And Why Naming Names Does Not Fix It) By John Sambrook · July 20, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Medical Devices](https://common-sense.com/insights/tag/medical-devices/), [Operations](https://common-sense.com/insights/tag/operations/) # Why CAPA Systems Rot (And Why Naming Names Doesn’t Fix It) **A Deep Dive: Conflict Avoidance as the Root Cause of FDA Quality System Failures** * * * ## The Pattern If you read enough FDA Warning Letters for medical devices, a specific cluster of citations appears again and again: - Failure to maintain an adequate CAPA system (21 CFR 820.198) - Failure to analyze complaint data (21 CFR 820.198(a)) - Failure to determine root cause of deviations (21 CFR 820.198(b)) - Failure to implement effective corrective actions (21 CFR 820.198(d)) These four citations appear together in a majority of device Warning Letters. They’re not independent failures. They’re a single failure expressed four ways: **the organization’s feedback loop is broken.** Complaints arrive. They’re logged. Nobody analyzes them for patterns. No CAPA is opened. Or a CAPA is opened, assigned to someone who closes it with a procedural fix (updated SOP, retraining) that doesn’t address the root cause. The same deviation recurs. The FDA shows up. The same four citations appear. ## A Composite Case To illustrate the method, we built a composite case from three real companies that received Warning Letters within the past year. We’ve blended their data and removed identifying details. The patterns, citations, and timeline are real. The company name is not. **The company:** A mid-size medical device manufacturer (~100-200 employees) producing an implantable or closed-loop therapeutic device. The product requires embedded software, custom hardware, and rigorous regulatory controls. The company has a dedicated quality team, a documented QMS, and a history of FDA submissions. **The Warning Letter citations:** 1. Failure to maintain an adequate CAPA system 2. Failure to analyze complaint data to determine if a device defect exists 3. Failure to investigate the cause of non-conforming product 4. Failure to ensure that corrective actions are effective and do not adversely affect the device **The timeline:** The FDA inspected the facility. Observations were issued on Form 483. The company responded within 15 business days (as required). The FDA reviewed the response and determined it was inadequate. A Warning Letter was issued 2-4 months later. By the time the Warning Letter was public, the company had known about these problems for at least 6 months. The FDA inspector saw them at the end of a multi-day inspection. The company’s own quality team likely saw them earlier still, but the information never translated into effective action. **The question is: why not?** ## The Surface Diagnosis The regulatory consultant’s answer: _strengthen your CAPA process._ The prescription is typically procedural: better CAPA software, more rigorous root cause analysis training, tighter escalation paths, more frequent management review meetings. The company implements the recommendations. The CAPA system produces more documentation. The next FDA inspection cites the same violations. The problem is that the prescription is incomplete. It addresses the mechanism without addressing the motive. It addresses the mechanism without addressing the motive. ## The Deep Diagnosis CAPA systems rot because of **conflict avoidance**, a cognitive bias that was adaptive for most of human evolutionary history but is destructive in modern quality systems. Here’s the chain: **Step 1: A complaint arrives.** A customer reports a device malfunction. The quality team logs it. So far, everything is procedural. No conflict yet. **Step 2: Pattern analysis requires judgment.** If this complaint is part of a pattern, it suggests a systemic defect. Identifying a pattern requires looking across time, across products, across departments. It requires connecting dots that different teams own. This is where conflict avoidance enters: analyzing the pattern will likely point to a design flaw or a process failure that someone in the organization is responsible for. **Step 3: Root cause analysis requires attribution.** Determining root cause means naming a cause. Naming a cause means pointing to a person, a team, or a decision. In an organization where conflict is avoided, root cause analysis defaults to the safest answer: “operator error” or “inadequate training.” These answers are procedurally sufficient (the CAPA form is filled out) and socially safe (no one is blamed). They are also almost always wrong. **Step 4: Corrective action addresses the symptom, not the cause.** If the root cause is “operator error,” the corrective action is retraining. The operator is retrained. The same deviation recurs because the real cause (a design flaw, a process gap, a resource constraint) was never addressed. The CAPA is closed. The problem persists. **Step 5: The cycle repeats.** More complaints arrive. More CAPAs are opened and closed with procedural fixes. The pattern accumulates. The FDA inspector arrives and sees the pattern that the organization’s conflict avoidance prevented from being addressed internally. The CAPA system breaks down because the procedures require people to do something their brains evolved to avoid: **name a problem that implicates someone in their tribe.** ## Why Naming Names Doesn’t Help This article uses a composite case rather than naming a specific company. This is a deliberate choice, not a legal precaution. **Logically,** naming a company and analyzing its failures treats the symptom as if it were the cause. Company X got a Warning Letter for CAPA failures. So what? Every company that gets a Warning Letter for CAPA failures is suffering from the same underlying dynamic: conflict avoidance breaking the feedback loop. Knowing that Company X has this problem doesn’t help Company Y understand its own. The useful unit of analysis is the _pattern_, not the _company_. **Tactically,** public shaming triggers the exact cognitive bias we’re trying to address. When a company is publicly called out for quality failures, its natural response is defensiveness, not introspection. The leadership team doubles down on protecting the organization’s reputation. The quality team is further marginalized. The CAPA system rots faster. The company that might have been receptive to help becomes hostile to it. We’ve seen this dynamic play out repeatedly. Companies that receive Warning Letters fall into two categories: those that use the experience as a catalyst for genuine improvement, and those that treat it as a reputational crisis to be managed. The difference is whether the leadership team can see past conflict avoidance to the real constraint. Our job is to help companies see that constraint. Public shaming makes that harder, not easier. ## The TOC Diagnosis Theory of Constraints frames this differently. Instead of asking “what procedures are broken?” it asks “what is the system constraint that makes conflict avoidance the rational choice?” In most medical device companies, the constraint is **regulatory throughput**, the rate at which the organization can safely move from design change to FDA-approved release. Everything in the organization is optimized to maximize this throughput. Conflict avoidance emerges as a rational response to this constraint. Here’s why: - **Raising a systemic problem slows throughput.** If a quality engineer identifies a pattern of complaints that suggests a design flaw, addressing it requires a design change, which requires re-validation, which takes months. The program is already behind schedule. Raising the problem makes the delay visible. Avoiding the conflict keeps the schedule looking clean. - **The person closest to the constraint has the most to lose.** The program manager or VP Engineering who owns the schedule is also the person whose authority would be challenged by a quality finding. In a hierarchy, challenging authority is costly. Conflict avoidance is the rational choice for anyone who wants to keep their job. - **Local optimization reinforces the dynamic.** The quality team optimizes for closed CAPAs (their metric). The engineering team optimizes for on-time delivery (their metric). Neither team optimizes for the system constraint (regulatory throughput), because neither team has visibility into it. Conflict avoidance is the equilibrium that emerges when local optimizations conflict. The TOC prescription is counterintuitive: **don’t fix the CAPA process. Fix the constraint.** When the constraint is regulatory throughput, every decision in the organization should be evaluated against one question: _does this increase or decrease our rate of safe, approved releases?_ - If raising a systemic problem will ultimately increase regulatory throughput (by preventing a larger failure later), it should be raised, and the organization should be structured to reward the person who raises it. - If the CAPA process is designed to produce documentation rather than insight, it’s optimizing for the wrong metric. - If the quality team is siloed from engineering, the dependency chain is broken and the constraint can’t be seen. The CAPA system doesn’t need better procedures. It needs a different objective function. ## What This Looks Like in Practice Here’s what the pattern looks like when it’s working: The TOC diagnosis reveals the constraint: the VP Engineering is measured on on-time delivery. Every quality finding that threatens the schedule gets deprioritized by his office. The quality team learns this, so they stop raising systemic problems and focus on procedural CAPAs that won’t trigger a schedule conflict. The CAPA system produces documentation but no insight. The fix is a conversation between the CEO, VP Engineering, and VP Quality that realigns the VP Engineering’s metrics to include regulatory risk. Once the VP Engineering is measured on both schedule _and_ regulatory throughput, the dynamic changes. Quality findings start being raised and addressed. The CAPA system starts producing insight. The next FDA inspection is clean, and the team actually learns something. The procedures didn’t change. The objective function did. We haven’t yet run this diagnosis with a medical device client. The pattern comes from analyzing the FDA data and mapping it to the cognitive drivers we see repeatedly in manufacturing and software organizations. The medical device space is where the pattern is most visible, because the consequences of getting it wrong are public, documented, and potentially lethal. That’s why we’re starting here. ## The Method If you’re reading this and recognizing your own organization, here’s what to do: **1\. Map the complaint-to-CAPA chain.** Trace a single complaint from receipt to CAPA closure. At each handoff point, ask: _what information is lost here? What judgment is required? What conflict is avoided?_ **2\. Identify the constraint.** What metric is the organization actually optimizing for? Is it throughput? Schedule? Cost? Closed CAPAs? The constraint is the metric that everyone is implicitly optimizing for, even when it conflicts with quality. **3\. Realign the objective function.** The person closest to the constraint needs to be measured on regulatory throughput, not just their local metric. This is a leadership decision, not a quality decision. **4\. Introduce a cognitive layer.** Use an external facilitator (a consultant, an AI-assisted diagnostic tool, a cross-functional team with no skin in the game) to surface the conflicts that the organization avoids. The constraint can’t be seen by the people who are constrained by it. **5\. Test the fix.** Run a single CAPA through the new process. Does it produce insight or documentation? If it produces insight, the objective function has shifted. If it produces documentation, you haven’t changed the constraint. ## A Note on the Data The composite case in this article is built from three real FDA Warning Letters issued to medical device companies within the past year. The companies produce implantable or closed-loop therapeutic devices requiring embedded software and custom hardware. The citations, timeline, and patterns are accurate. The company name and identifying details are fictional. We chose this approach because the useful unit of analysis is the pattern, not the company. If you’re going through a similar situation, the analysis applies to you regardless of whether your name appears in an article. If you’re not, the analysis helps you understand the patterns to watch for before they become Warning Letters. Either way, the goal is the same: help organizations see their constraints clearly enough to address them. * * * _This article is part of a series on cognitive drivers of medical device quality failures. The introductory article, “The Same Seven Mistakes, Every Company, Every Decade,” provides the broader framework. The full pattern library and underlying data are available for review._ Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Why Software Defects Kill | Common Sense Systems URL: https://common-sense.com/insights/why-software-defects-kill/ [Insights](https://common-sense.com/insights/) # Why Software Defects Kill (And Why Optimism Is the Real Bug) By John Sambrook · July 20, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Medical Devices](https://common-sense.com/insights/tag/medical-devices/), [Operations](https://common-sense.com/insights/tag/operations/) ## TL;DR Software and firmware defects account for 12 Class I (critical) medical device recalls, the highest of any failure category. When a software defect causes a Class I recall, patients are at risk of death or serious harm. The standard explanation is “inadequate testing” or “poor validation.” The deeper explanation is planning fallacy: every engineering team consistently underestimates complexity, overestimates their timeline, and ships software that hasn’t been adequately validated because the schedule wouldn’t allow it. The fix is a different objective function. * * * ## The Pattern If you look at the FDA’s device enforcement data, software and firmware defects are not the most common failure category. They account for 10.4% of all enforcement actions, behind sterility/packaging (28.2%) and component failures (16%). But software defects account for **12 Class I recalls**, the highest of any category. Class I recalls are the FDA’s most severe classification. They represent situations where use of the device could cause serious adverse health consequences or death. When a software defect triggers a Class I recall, patients are in immediate danger. Category Class I Recalls Software & Firmware Defects 12 Sterility & Packaging Integrity 8 Component & Assembly Failure 6 Material & Component Failure 5 Process Control & Validation 4 The stakes for software defects are lethal. A ventilator alarm that fails to sound. A defibrillator that delivers the wrong energy. An insulin pump that miscalculates dosage. These are not packaging errors. They are software bugs that kill. ## A Composite Case To illustrate the method, we built a composite case from three real companies that received Class I recalls for software defects. We’ve blended their data and removed identifying details. The patterns, citations, and timeline are real. The company name is not. **The company:** A mid-size medical device manufacturer (~150-300 employees) producing a software-intensive therapeutic device. The product requires embedded firmware, real-time control algorithms, and rigorous regulatory validation under 21 CFR Part 820 and IEC 62304. **The recall:** A software defect was discovered in the device’s control algorithm. The defect could cause the device to fail to deliver therapy, or to deliver therapy incorrectly. The company issued a Class I recall affecting thousands of units in the field. **The timeline:** The software was developed on a compressed schedule. Validation testing was planned for 12 weeks but executed in 8. Several test cases were marked “deferred” to meet the launch date. The defect was discovered three months after launch through a field complaint. The recall was initiated within 30 days. By the time the recall was public, the engineering team had known about the compressed validation schedule for at least six months. The deferred test cases were documented. The risk was known. The schedule won. **The question is: why did the schedule win?** ## The Surface Diagnosis The regulatory consultant’s answer: _strengthen your software validation process._ The prescription is typically procedural: more rigorous test coverage, better traceability matrices, additional review gates, more automated testing. The company implements the recommendations. The next software release still ships with compressed validation. The same pattern repeats. The problem is that the prescription is incomplete. It addresses the mechanism without addressing the motive. It addresses the mechanism without addressing the motive. ## The Deep Diagnosis Software defects in medical devices exist because of **planning fallacy**, a cognitive bias that was adaptive for most of human evolutionary history but is destructive in modern software engineering. Here’s the chain: **Step 1: The project is scoped.** The engineering team estimates the development timeline. The estimate is optimistic. This is not dishonesty, it’s planning fallacy. Every team believes their project will go smoothly. Decades of research show that even experts consistently underestimate software complexity by 40-60%. **Step 2: The schedule is set.** Management accepts the optimistic estimate. The launch date is set. Investors, regulators, and customers are told when the product will ship. The schedule becomes a commitment, not a plan. **Step 3: Development begins.** The team encounters the expected problems: integration issues, algorithm bugs, hardware-software interface problems, regulatory requirements that weren’t fully understood at scoping time. The work takes longer than estimated. **Step 4: The schedule conflicts with quality.** Validation testing is the first thing to be compressed. Why? Because validation doesn’t “add features”, it verifies that the features work. In a schedule conflict, validation is the easiest thing to defer. The team tells themselves they’ll catch the defects in field monitoring. They’ll patch the software after launch. The schedule wins. **Step 5: The defect ships.** The software is released with incomplete validation. The deferred test cases are never executed. The defect that would have been caught in validation reaches patients. The Class I recall is initiated. The software defect is a failure of planning. The team planned for the best case, and the best case didn’t happen. The schedule was set on an optimistic estimate, and the schedule drove every decision after that. ## Why Naming Names Doesn’t Help This article uses a composite case rather than naming a specific company. This is a deliberate choice, not a legal precaution. **Logically,** naming a company and analyzing its software failures treats the symptom as if it were the cause. Company X had a software defect. So what? Every company that ships software has defects. The useful unit of analysis is the _pattern_, not the _company_. **Tactically,** public shaming triggers defensiveness, not introspection. The engineering team that shipped a defective product is already under pressure. Public criticism makes them double down on protecting their reputation, not examining their planning process. The company that might have been receptive to help becomes hostile to it. We’ve seen this dynamic play out repeatedly. Companies that experience software recalls fall into two categories: those that use the experience to improve their planning and validation processes, and those that treat it as a reputational crisis to be managed. The difference is whether the leadership team can see past defensiveness to the real constraint. Our job is to help companies see that constraint. Public shaming makes that harder, not easier. ## The TOC Diagnosis Theory of Constraints frames this differently. Instead of asking “what testing processes are broken?” it asks “what is the system constraint that makes compressed validation the rational choice?” In most medical device companies, the constraint is **time-to-revenue**, the rate at which the organization can move from concept to approved, shipped, billed product. Everything in the organization is optimized to maximize this throughput. Planning fallacy emerges as a rational response to this constraint. Here’s why: - **Optimistic estimates win funding.** The project with the most aggressive timeline is the one that gets approved. Pessimistic estimates are rejected or pressured. The planning fallacy is rewarded by the funding process. - **The schedule is a commitment, not a plan.** Once the launch date is set, it becomes a promise to investors, regulators, and customers. Changing the date is costly. Compressing validation is cheaper than delaying the launch. - **Local optimization reinforces the dynamic.** The engineering team optimizes for feature completion (their metric). The quality team optimizes for test coverage (their metric). Neither team optimizes for the system constraint (time-to-revenue), because neither team has visibility into it. Compressed validation is the equilibrium that emerges when local optimizations conflict. The TOC prescription is counterintuitive: **don’t add more testing. Fix the planning process.** When the constraint is time-to-revenue, every estimate in the organization should include a buffer for uncertainty. Not a management reserve, a built-in acknowledgment that software complexity is inherently unpredictable. - If the validation timeline is compressed to meet a launch date, the launch date should be adjusted, not the validation. - If the planning process rewards optimistic estimates, it should be changed to reward realistic ones. - If the quality team is siloed from engineering, the dependency chain is broken and the constraint can’t be seen. The software defect doesn’t need more testing. It needs better planning. ## What This Looks Like in Practice Here’s what the pattern looks like when it’s working: The TOC diagnosis reveals the constraint: the engineering team is measured on on-time delivery. Every validation finding that threatens the schedule is deprioritized. The quality team learns this, so they focus on procedural compliance rather than rigorous testing. The validation process produces documentation but no insight. The fix is a conversation between the CEO, VP Engineering, and VP Quality that realigns the engineering metrics to include regulatory risk. Once the engineering team is measured on both schedule _and_ software quality, the dynamic changes. Validation findings start being raised and addressed. The validation process starts producing insight. The next software release ships with adequate testing, and the team sleeps better. The procedures didn’t change. The objective function did. We haven’t yet run this diagnosis with a medical device software client. The pattern comes from analyzing the FDA data and mapping it to the cognitive drivers we see repeatedly in software organizations. The medical device space is where the pattern is most visible, because the consequences of getting it wrong are public, documented, and potentially lethal. That’s why we’re starting here. ## The Method If you’re reading this and recognizing your own organization, here’s what to do: **1\. Map the validation chain.** Trace a single software defect from introduction to detection. At each stage, ask: _was this defect caught by the validation process? If not, why? Was the test case deferred? Was the schedule compressed?_ **2\. Identify the constraint.** What metric is the engineering team actually optimizing for? Is it feature completion? Schedule adherence? Bug count? The constraint is the metric that everyone is implicitly optimizing for, even when it conflicts with quality. **3\. Realign the objective function.** The engineering team needs to be measured on software quality, not just schedule. This means including validation completeness and defect escape rate in the engineering metrics. This is a leadership decision, not a quality decision. **4\. Introduce planning buffers.** Every software estimate should include a buffer for uncertainty. Not a management reserve, a built-in acknowledgment that complexity is unpredictable. The buffer should be visible, not hidden. **5\. Test the fix.** Run a single software release through the new process. Does validation produce insight or documentation? If it produces insight, the objective function has shifted. If it produces documentation, you haven’t changed the constraint. ## A Note on the Data The composite case in this article is built from three real FDA Class I recalls for software defects. The companies produce software-intensive therapeutic devices requiring embedded firmware and real-time control algorithms. The citations, timeline, and patterns are accurate. The company name and identifying details are fictional. We chose this approach because the useful unit of analysis is the pattern, not the company. If you’re going through a similar situation, the analysis applies to you regardless of whether your name appears in an article. If you’re not, the analysis helps you understand the patterns to watch for before they become recalls. Either way, the goal is the same: help organizations see their constraints clearly enough to address them. * * * _This article is part of a series on cognitive drivers of medical device quality failures. The introductory article, “The Same Seven Mistakes, Every Company, Every Decade,” provides the broader framework. The full pattern library and underlying data are available for review._ Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # 990 AI Fetches, One Post, No Door | Common Sense Systems URL: https://common-sense.com/insights/ai-assistants-fetched-one-post-990-times-it-had-no-door/ [Insights](https://common-sense.com/insights/) # AI Assistants Fetched One of Our Posts 990 Times. It Had No Door. By John Sambrook · July 12, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Strategy](https://common-sense.com/insights/tag/strategy/) > **Note (October 2026):** The paid audits mentioned in this post have been retired. If you want your own site checked, [book a free consult](https://common-sense.com/book/). ## TL;DR In fourteen days, roughly 1,490 fetches of our pages came from AI assistants acting on someone’s question. Google Analytics recorded none of them, because crawlers do not run JavaScript. Three of the 1,490 reached a page where they could buy anything. * * * On Sunday night I pointed a coding agent at our own nginx access log. Not the analytics dashboard. The raw log, on the droplet, 122,865 lines of it, going back fourteen days. I did this because we sell a service called a JSON-LD Schema Audit. It tells a business what machines can and cannot read on their website. It is a good product and I believe in it. It occurred to me, somewhere around midnight, that I had never run the equivalent check on us. Here is what came back. ## The channel we could not see Twelve thousand of those log lines were AI crawlers. That number by itself means very little, and I want to be careful about it, because it is the kind of number that looks like traffic and is not. Most of it is training. GPTBot, ClaudeBot, Amazonbot, Bytespider — these are hoovering the web. They would fetch us if we sold nothing. They tell you that you are ingestible. They do not tell you that anyone wants what you have. The interesting number is smaller and completely different in kind. Some of those user agents are not training crawlers at all. `ChatGPT-User`, `Claude-User`, `Perplexity-User`, `OAI-SearchBot` — these show up when a human being has just asked a model a question and the model has gone out to fetch a page in order to answer it. That is not a robot browsing. That is a person, with a question, in the middle of trying to solve something. We had about 1,490 of those in fourteen days. Roughly 750 a week. That number took some work to earn, and I want to show you how, because my first answer was wrong by about twenty percent and the way it was wrong is instructive. ## How I got the number wrong, and then less wrong My first count was 1,849. It was too high, for three reasons, and I only found them because someone asked me the obvious question: how do you actually know a human was behind any of this? The honest answer was that I did not know. I had inferred it. A web server does not see a person. It sees a request with a `User-Agent` header, which is a string the requester chooses for itself. Mine said `ChatGPT-User`, OpenAI’s documentation says that agent fires when someone asks ChatGPT a question and it goes to fetch a page, and I took the two together as proof. That is not proof. That is a plausible chain with an unchecked link in the middle. **First correction: the user agent can lie.** OpenAI publishes the IP ranges its crawlers use, so this is checkable, and I should have checked it before saying anything. Of the 1,463 requests claiming to be `ChatGPT-User`, 1,395 came from IP addresses OpenAI actually owns. Sixty-eight did not. Something out there is wearing OpenAI’s name to scrape us, and I had been counting it as demand. **Second correction: not every AI agent means a person asked.** I had lumped `OAI-SearchBot` in with the human-driven traffic. But OpenAI describes it as the crawler that builds ChatGPT’s search index — it is a librarian, not a customer. It fetches you whether or not anyone has asked about you. That is 291 requests I had put in the wrong column, and it is the same mistake I had just spent a paragraph warning about: counting a robot that would visit us if we sold nothing. **Third correction, and this one does not go away: a fetch is not a person.** One question can send a model after several pages, and it may fetch the same page more than once. So even the corrected 1,490 is a count of _fetches_, not of _people_. The real number of humans is smaller, and I cannot tell you by how much, because the server log does not contain that information and no amount of staring at it will make it appear. So the defensible claim is narrower than the one I started with: roughly 1,490 fetches, of which 1,395 are IP-verified as OpenAI’s user-triggered agent, and the rest are Claude and Perplexity agents I am trusting on their word alone. Behind those fetches is some unknown, smaller number of actual people. Here is the part I did not expect. Tightening the number made the finding _worse_, not better. On the inflated count, 55% of the traffic went to one page. On the honest count, it is 66%. Four had reached a page where they could buy something; on the honest count it is three. Every correction I made moved the conclusion in the same direction. I am telling you all of this because a number you cannot interrogate is not evidence, it is decoration. If I am going to argue that our analytics were lying to us, the least I can do is show you where mine were. For comparison: Google Analytics shows us roughly 40 relevant human sessions a week. I want to be precise rather than dramatic here, because the comparison is not exactly like-for-like — a model fetching a page on someone’s behalf is not the same event as a person landing on it. But the order of magnitude is not in doubt, and the direction is not in doubt either. The channel we cannot see is much larger than the channel we have been watching. It has been that way for months. I had no idea. Google Analytics is JavaScript. Crawlers do not run JavaScript. Every one of those fetches was invisible to the tool I had been using to decide what to work on. ## Where they landed This is the part that stung. Of those 1,490 fetches, 990 of them — sixty-six percent — went to a single page. It was [Your Google Business Profile Is Floating in Space](https://common-sense.com/insights/connecting-google-business-profile-to-your-structured-data/), a post I wrote in February about connecting a Google Business Profile to your website’s structured data. That is a good outcome, in one sense. People are asking AI systems how to make their business legible to machines, and the AI systems are sending them to us. That is exactly the audience we want. It is, in fact, precisely the person who should buy a JSON-LD audit. Three of the 1,490 ever reached a page where they could buy one. Three. And no, none of the three bought anything. Nobody has, yet. I should be precise about what that does and does not mean, because the honest version is more interesting than either the flattering one or the self-flagellating one. Common Sense Systems has been in business since 1996. We have sold plenty. What is new is the _storefront_ — the part of the site where you can buy something with a card, without talking to me first. Stripe went into live mode on the eighth of July. Five days ago. So the checkout works, and it has run end to end twenty-one times: money taken, report generated, delivered, receipt sent. Every one of those twenty-one was me or an automated test, because for almost all of the fourteen days I have been describing, there was no live card processing to buy through. The thousand people arrived before the shop had a till. I am not going to dress that up, and I am also not going to pretend it is worse than it is. The machinery is real and it works. It is five days old. What it has not yet had is a customer. The post ends with an honest offer. I wrote, “If you’re running a small business and want to check whether your Google Business Profile is actually connected to your website in a way that machines can read, I’m happy to take a look. Send me your URL and I’ll tell you what I find.” That sentence describes our product almost word for word. It just points at my inbox instead of at the product. A thousand people arrived at a page that described the thing they wanted, and the page offered them an email address. The audit costs $39.99 and runs in minutes. I had built it. I had shipped it. And then I had left the single largest source of qualified demand pointing somewhere else. ## The part that is worse While the agent was in the logs, it found something I would rather not write about, which is a decent sign that I should. We had a DNS record for `prod.common-sense.com`. It was a leftover, from an older way of doing things, and it pointed at the same droplet as `common-sense.com`. I had stopped using it and forgotten it existed. nginx, though, did not have a server block for that name. Requests to a hostname nginx does not recognize fall through to the default server, and our default server does what most hardened default servers do: it drops the connection without a response. OpenAI’s search crawler found that hostname. It is public, after all — it was sitting in DNS where anything can see it. And when it went to fetch `robots.txt`, so that it could be a well-behaved crawler and honor our rules, we killed the connection. I verified this rather than assuming it. The requests came from an IP inside OpenAI’s published crawler ranges, so it was genuinely them, and the response was genuinely a dropped connection. We sell a service that helps businesses get found by machines. We were dropping the machines on the floor. That record is deleted now. It took about a minute. It had been there for months. ## What this actually is In Theory of Constraints, the constraint is the one thing that most limits what the whole system can produce. Improve anything else and you get nothing. Improve the constraint and the whole system moves. For a small business selling digital products, the thing you are producing is not content and it is not offers. It is offers that find buyers. That is the throughput. Everything else is inventory. I had been assuming our constraint was demand. Not enough people know we exist, so make more things, write more posts, get in front of more people. That assumption is why I have written 58 posts. The logs say the constraint was somewhere else entirely. The demand was already arriving. It was arriving in volume, it was qualified, it was asking exactly the right question, and it was hitting a page with no door. We were not short of buyers. We were short of a link. That is a much cheaper problem than the one I thought I had. It is also a more embarrassing one, and I think those two things are related. The cheap problems are the ones you can look right at for months without seeing, because they do not feel like problems. They feel like nothing at all. ## What we changed The post now links to the audit. The stale hostname is gone. And the sensor that found all this is now a real part of our system rather than a thing an agent did once at midnight — it reads the rotated logs, it separates the crawlers that mean demand from the ones that mean nothing, and it tells us when a page is getting AI traffic and offering it no next step. I also put a falsification test on the fix, before making it, because I did not want to be able to talk myself into success afterward. If thirty days from now that post has sent zero people to the audit page, then my explanation is wrong. The traffic is not qualified, these readers do not want to buy anything, and I should stop telling myself a story about it. I will report that here if it happens. ## A note on how this was found This post is analytical rather than experiential, and the guidelines I write under require me to say so plainly: the investigation was done by an AI coding agent working through our systems over several hours, and the prose here was drafted with AI assistance. The findings, the numbers, and the conclusions are mine, and I checked them. I will say one more thing about that, since it is relevant to what we do. The agent found the missing link, and it found the hostname, and it also found that a monitoring script had been quietly lying to me for months about our sitemap. But it did not find any of that by being clever. It found it by looking at a log file that had been sitting on our own server the entire time, that I had never once opened. That is usually how this goes. The evidence is rarely hidden. It is just unexamined. * * * If you are selling something on the internet and you have never looked at your raw server logs — not your analytics dashboard, the actual logs — I would encourage you to look. You are probably being visited by machines acting on behalf of real people with real questions, and your analytics almost certainly cannot see them. If you want a hand working out what those logs are telling you, or you want to know what machines can currently read on your site, send me a note at [john@common-sense.com](mailto:john@common-sense.com). I am genuinely curious whether what we found is unusual or whether it is happening to everyone. Tell me what you see. I would like to know if I am wrong about this. Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Healthcare Assistance Conflicts | Common Sense Systems URL: https://common-sense.com/insights/healthcare-financial-assistance-patterns/ [Insights](https://common-sense.com/insights/) # What I Keep Seeing in Healthcare Financial Assistance Policies By John Sambrook · June 9, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Strategy](https://common-sense.com/insights/tag/strategy/), [Leadership](https://common-sense.com/insights/tag/leadership/) ## TL;DR When I read healthcare financial assistance policies, I keep seeing the same three conflicts. The policy says it wants to help patients, protect the hospital, and avoid bad debt, but the rules often force staff to choose between those goals. The hard part is not the paperwork itself. It is the hidden assumptions inside the paperwork. * * * The policy that stayed with me longest was eight pages long. It looked ordinary. A community hospital financial assistance policy. Income thresholds. Document requirements. Billing language. Eligibility rules. The kind of document every hospital has to write and every staff member has to explain at least once a week. On paper, the policy said the right things. In practice, it created choices nobody should have to make. A registration clerk would look at a patient who clearly needed help, then hit a wall: no pay stubs, no W-2s, no easy way to prove income because the person was living out of a car, staying with relatives, or working cash jobs. The policy wanted to help. The policy also wanted proof. Those two requirements collided in the real world. That is the kind of thing I keep seeing. ## The First Conflict: Proof vs. Access The first recurring conflict is simple to describe and hard to resolve. Hospitals want to protect the financial assistance program from misuse. Staff also want eligible patients to get help without turning the application process into another barrier. Those are both legitimate needs. The trouble starts when the policy turns those needs into incompatible rules. Require too much documentation and people who obviously qualify cannot complete the process. Require too little and staff worry about fraud or audit trouble. The assumption underneath the policy is usually that the only way to protect the program is to make every patient prove everything the same way. That assumption is stronger than it looks, and often wrong. In the policy I studied, the better answer was a tiered process: presumptive eligibility for the obvious cases, simplified documentation for ordinary cases, and full review only when the situation really needs it. That keeps integrity in the system without pretending every patient arrives with a neat paper trail. ## The Second Conflict: One Episode vs. Many Bills The second pattern is the one that makes patients feel lied to. The hospital says the patient is covered. Then the bills start arriving from independent providers: pathology, radiology, cardiology, anesthesia. The patient experiences one episode of care. The billing system treats it like a dozen separate transactions. That gap matters because patients do not live inside the hospital’s org chart. They live inside the episode. From the patient’s point of view, the hospital said, “You are covered.” Then a set of people they never separately met starts sending bills they cannot pay. From the hospital’s point of view, the policy may have been written to cover only the services the hospital directly controls. That distinction may make sense to a finance team. It does not make sense to the person sitting at the kitchen table with the bills. This is not a communications problem. It is a design problem. If the policy wants to protect patients from surprise bills, then it has to account for the reality that the care episode is broader than the hospital’s direct control. If it does not, the policy is technically precise and practically misleading. ## The Third Conflict: Fast Help vs. Full Verification The third pattern is the one that quietly creates debt. Many policies require a completed application and full verification before assistance can begin. That sounds reasonable until you meet the patients who cannot finish the process in time. Crisis, homelessness, mental illness, cognitive impairment, language barriers, and plain exhaustion all interfere with paperwork. The policy says: complete the application first. The patient situation says: help is needed now. Those are not the same timeline. So the debt grows while the paperwork catches up. Sometimes the patient clearly qualified all along. Sometimes the bill gets handed to collections because the process moved slower than the need. The policy intended to prevent hardship and ended up creating it. That is a structural failure, not a moral one. ## What the Conflicts Have in Common The three conflicts are different on the surface: - documentation requirements - independent provider billing - presumptive eligibility timing But they are built from the same logic. Each one tries to satisfy two legitimate needs with a rule that quietly assumes the needs can be separated. They cannot always be separated. In practice, a policy that helps one side by ignoring the other side will create the exact failure it was written to prevent. The hospital protects revenue but traps staff. The staff protect the process but block assistance. The patient gets told the right words and then experiences the wrong system. That is why I keep saying the problem is structural. The people are usually trying to do the right thing. ## What I Look For Now When I read a healthcare policy, I look for three things: 1. Where does the policy force a false either-or choice? 2. What assumption is holding that choice in place? 3. What would the policy look like if it were designed around the actual patient journey instead of the billing workflow? Those three questions usually tell me more than the entire first read-through of the document. They also tell me where a hospital is wasting time. If the staff are repeatedly asking patients for documents they do not have, or explaining bills that the policy never made understandable, or pushing people through a process that cannot possibly finish in time, then the policy is not just inefficient. It is producing avoidable harm. ## Why This Matters Beyond One Policy I am not interested in policy analysis as a parlor trick. I care because these same conflicts show up everywhere in healthcare: - scheduling policies that make access harder instead of easier - quality metrics that measure the wrong thing - staffing rules that protect budgets while burning out the people on the floor - documentation rules that consume the time needed for actual care The specific document changes. The pattern does not. That is why I use Theory of Constraints when I look at this kind of work. It gives me a way to map the conflict, identify the assumption, and test whether the system can be redesigned without forcing someone to lose. If I can find the assumption that makes the policy look inevitable, I usually find the path out of the trap too. If you are sitting inside a policy like this and want a second set of eyes on it, I would welcome the conversation. You can reach me at [john@common-sense.com](mailto:john@common-sense.com). ## Sources - [IRS: New requirements for 501(c)(3) hospitals under the ACA](https://www.irs.gov/charities-non-profits/charitable-organizations/new-requirements-for-501c3-hospitals-under-the-affordable-care-act) - [eCFR 26 CFR 1.501(r)-4 (Financial assistance policy)](https://www.ecfr.gov/current/title-26/chapter-I/subchapter-A/part-1/subject-group-ECFR6cf246f7578f5eb/section-1.501\(r\)-4) - [eCFR 26 CFR 1.501(r)-6 (Billing and collection requirements)](https://www.ecfr.gov/current/title-26/chapter-I/subchapter-A/part-1/subject-group-ECFR6cf246f7578f5eb/section-1.501\(r\)-6) - [American Hospital Association: Uncompensated Hospital Care Cost](https://www.aha.org/fact-sheets/2020-01-06-fact-sheet-uncompensated-hospital-care-cost) Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Getting Started with Local AI Coding | Common Sense Systems URL: https://common-sense.com/insights/getting-started-with-local-ai/ [Insights](https://common-sense.com/insights/) # Getting Started with Local AI: A Coding Stack That Runs on Your Own Hardware By John Sambrook · May 27, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) ## TL;DR For the past couple of weeks I have done my coding on a 27-billion-parameter model running entirely on a graphics card in my own office, with no per-token charges. The stack is llama.cpp serving a quantized Qwen3.6-27B model, driven by two agents: pi for coding and Hermes for everyday tasks. This walks through the setup and what every part does. * * * ![A local AI coding stack: an RTX 3090 GPU in a Dell Precision 5820 workstation running a quantized Qwen3.6-27B model under llama.cpp, exposing an OpenAI-compatible endpoint on port 8001 that the pi coding agent and the Hermes agent both connect to over the home network.](https://common-sense.com/images/content/getting-started-local-ai-stack.svg) There is a graphics card sitting in a workstation under my desk in Kirkland. It is an NVIDIA RTX 3090, a couple of generations old now, the kind of thing you can find used for a few hundred dollars. For the past couple of weeks, every line of code I have written has gone through a large language model running on that card. No API key. No metered billing. No data leaving the building. When I close a coding session, the only thing it cost me was electricity. I have written before about [doing my taxes with Claude Code and Codex](https://common-sense.com/insights/doing-taxes-with-ai-coding-agents/) and about [canceling SaaS subscriptions](https://common-sense.com/insights/saas-subscriptions-ai-coding-agents/) once AI agents made the switching costs collapse. Both still rely on frontier models in the cloud, and for a lot of work I still reach for those. They are excellent and I am not giving them up. But a question kept nagging at me: how much of my daily coding actually needs a frontier model, and how much could run on hardware I already own? For most of the past two years, the honest answer was “not much.” Local models were interesting but not good enough to lean on. That has changed, and it changed fast. Two things are true at once here. In the field, the last couple of months have brought remarkable progress in how much capability fits on a consumer card. And personally, I have only been working this local AI project for about two weeks. The local models are still not the equivalent of the best cloud models — I want to be clear about that — but the gap has closed enough that for a real share of my work, the local option now wins. This is the first of a few pieces on local AI. In a later one I will describe the agentic software development, writing, and marketing teams I am building on top of this foundation. For now I want to start where everything else has to start, with the engine: the hardware, the model, the server that runs it, and the exact settings I use to invoke it. I will explain the settings in enough detail that you can understand why they are there, not just copy them. ## What “Local AI” Actually Means When people say “AI,” they usually mean a service: you send text to a company’s servers, their model generates a response, and you pay per token. The model itself lives on hardware you will never see. Local AI inverts that. The model weights — the multi-gigabyte file that contains everything the model learned during training — sit on a disk in your building. A program loads those weights into your GPU’s memory and runs the math required to generate text. The conversation never leaves your network. There is no per-token charge because there is no third party metering the tokens. You bought the hardware once, and now the marginal cost of a request is the power it draws while it runs. That tradeoff is the whole story. Cloud models are larger and generally smarter, and you pay for every use. Local models are smaller and run on your own hardware, and once the hardware is paid for, use is effectively free. The interesting question is not which approach wins. It is which approach fits which job. For the past couple of weeks of my coding, the local model fit. ## The Cloud Side: OpenRouter Before the local hardware, a word about the other half of how I work, because the two fit together. For cloud models, I use [OpenRouter](https://openrouter.ai). It is a single service that sits in front of dozens of model providers — Anthropic, OpenAI, Google, and many others — and gives you one account, one API key, and one bill to reach all of them. Instead of holding separate accounts with each provider, you send a request to OpenRouter and name the model you want, and it routes the request to whoever serves that model. The practical benefit is that switching from one provider’s model to another’s is a one-line change, not a new contract. When a better model comes out, I try it the same afternoon. That matters here because the same standard interface that lets OpenRouter route to many cloud providers is the interface my local server speaks. The tools I use do not care whether the model answering them lives in a data center reached through OpenRouter or on the card under my desk. That interchangeability is what makes a mixed local-and-cloud setup practical rather than a science project. ## The Hardware: Used Workstations with One Card Each I own several GPUs across a few machines. The work in this article runs on a pair of older Dell Precision 5820 workstations. Each one has a 950-watt power supply, 64 GB of system RAM, and a single NVIDIA RTX 3090. Both run Ubuntu 24.04 LTS, the current long-term-support release of Ubuntu, which is a stable and well-supported base for this kind of always-on service. The two machines are entirely separate systems. They are not networked together to run one model across both cards, and they do not need to be. Each one runs the whole model on its single 3090, on its own. I keep two because two gives me production capacity — I can run jobs on both at once, or take one down without losing the other. For the purposes of this article, picture one workstation with one card; the second is simply a duplicate of the first. The cards are not new and they were not expensive. What makes them useful is memory: each RTX 3090 has 24 GB of VRAM, and VRAM is the binding constraint for running a model locally. Here is why memory dominates. To generate text quickly, the model’s weights need to live in the GPU’s memory, where the GPU can read them at enormous bandwidth. If the weights do not fit in VRAM, you either spill them into ordinary system RAM, which is far slower, or you cannot run the model at that size at all. So the practical question for any local setup is not “how fast is the card” but “how much will fit.” A single 3090’s 24 GB is enough to hold the quantized 27-billion-parameter model I use plus the working memory it needs during a long session, with room to spare. If you are pricing this out: the binding constraint is VRAM per dollar, and the previous generation of high-memory consumer cards remains the value sweet spot. You do not need the newest hardware. You need enough memory. ## The Model: Qwen3.6-27B The model I am running is Qwen3.6-27B, an open-weight model from Alibaba’s Qwen team. “Open-weight” means the trained weights are published for anyone to download and run, which is what makes local use possible in the first place. “27B” means roughly 27 billion parameters — the tunable numbers the model adjusted during training. As a rough mental model, more parameters generally means more capability and more memory required to run it. I picked this model deliberately. The current generation of mid-sized open models has gotten good enough that a 27B model now does work that used to require something several times larger. That is the development that makes a setup like this worth your time in 2026 when it would not have been a couple of years ago. NVIDIA made the same observation recently when describing local agents: the Qwen 3.6 27B and 35B models are outperforming the previous generation’s much larger counterparts while still fitting on consumer cards. The model got smaller and smarter at the same time, which is exactly the trend that brings this within reach of a small business. ### Where the Model Comes From: Hugging Face You download open-weight models from [Hugging Face](https://huggingface.co), which is the center of gravity for the open machine-learning world. Think of it as the GitHub of models: it hosts hundreds of thousands of models and datasets, each on its own page (called a “repository,” or “repo”) with documentation, files, and version history. When you want a local model, you find its repo on Hugging Face and download the specific file you need. The specific repository I download from is `unsloth/Qwen3.6-27B-MTP-GGUF`. Reading that name left to right tells you a lot: `unsloth` is the account that published it, `Qwen3.6-27B` is the model, `MTP` flags a particular capability I will return to below, and `GGUF` is the file format. My install script pulls a single file from that repo, `Qwen3.6-27B-UD-IQ3_XXS.gguf`, into a local models directory. Downloading is done with Hugging Face’s command-line tool, which my script installs into its own isolated Python environment. Some repositories are public and download with no account; others ask you to be logged in or to accept the model’s license first. For those, you create a free Hugging Face account, generate an access token in your account settings, and hand that token to the download tool. My script reads the token from an environment variable so it never has to appear in a command you type. If you set no token, it still tries an anonymous download, which works for public models but with lower rate limits. ### Quantization: Making the Model Fit A 27B model at full precision would not fit in 24 GB of VRAM with room left over for a long coding session. The technique that solves this is called quantization. In its original form, each of the model’s parameters is stored as a relatively high-precision number. Quantization compresses those numbers into a smaller format — fewer bits each — which shrinks the total file dramatically. You can think of it like saving a photograph at a lower bit depth: the file is smaller and slightly less precise, but for most purposes you cannot tell the difference. There is a real tradeoff. Compress too aggressively and the model gets noticeably less reliable. The art is finding the point where the model still fits comfortably in memory but has lost as little capability as possible. The variant I download is the one configured in my install script: `Qwen3.6-27B-UD-IQ3_XXS.gguf`. Every piece of that label means something, and once you can read it you can read any quantized model’s name: - **IQ3** means roughly three bits per parameter, using one of llama.cpp’s “I-quant” formats. (For comparison, common quantizations run from about two bits at the small, aggressive end up to eight bits near full fidelity.) Three bits is fairly aggressive compression, which is what lets a 27B model leave headroom for a large working context on a single 24 GB card. - **XXS** marks it as the extra-extra-small size class within that format — the most compressed option in that family. - **UD** stands for Unsloth’s “Dynamic” quantization. Rather than compressing every part of the model equally, this approach keeps the parts of the model that matter most at higher precision and compresses the less-sensitive parts more aggressively. The result holds up better than a uniform three-bit quantization would, which is the whole point: it buys back much of the quality that naive three-bit compression would throw away. - **GGUF** is the file format itself — the standard container for models that run under llama.cpp. When you go looking for a local model, GGUF is the format you want. The `MTP` in the repository name refers to multi-token prediction, a capability baked into this particular build of the model. It is what makes the speed trick described later in this article possible. ## The Engine: llama.cpp The program that actually loads the model and runs it is **llama.cpp**, an open-source project that has become the workhorse of the local AI world. It is fast, it runs on ordinary hardware, and it includes a small web server, `llama-server`, that exposes the model over an interface compatible with the OpenAI API. That last detail matters more than it sounds: because the server speaks a standard protocol, almost any tool built to talk to a cloud model — the same kind of tool you would point at OpenRouter — can be pointed at my local server instead, with no other changes. You will find llama.cpp on GitHub at **github.com/ggml-org/llama.cpp**. It is one of the most active open-source projects of its kind, with releases landing constantly. You build it from source for your specific hardware. On an NVIDIA machine that means compiling it with CUDA support — CUDA being NVIDIA’s toolkit for running general-purpose computation on the GPU — so that llama.cpp can use the card rather than the CPU. My install script clones the repository, configures the build for the RTX 3090’s specific GPU architecture, compiles it, and produces the `llama-server` binary. One detail worth noting for anyone trying to reproduce this exactly: I build from a specific development branch (`mtp-clean`) rather than the default, because that branch carries the multi-token-prediction support that pairs with the model’s `MTP` capability. If you are using a stock model without that feature, the mainline build is what you want. I also install the server as a background service using systemd, the standard service manager on Ubuntu. That means the model server starts automatically when the machine boots and restarts itself if it ever crashes, so it is simply always there, the way a printer or a file share is always there. The service binds to my home network so I can reach it from my laptop or my phone, not only from the machine with the GPU in it. ## The Invocation: What Every Parameter Does Here is the heart of it. This is the command the service runs to start the model. ![The annotated llama-server command used to load the Qwen3.6-27B model, showing each flag: model file, GPU layers, context size, KV cache type, flash attention, parallel slots, temperature, chat template, batch sizes, threads, speculative decoding, and host and port.](https://common-sense.com/images/content/getting-started-local-ai-command.svg) ``` llama-server \ -m Qwen3.6-27B-UD-IQ3_XXS.gguf \ -ngl 80 \ -c 262144 \ --cache-type-k q4_0 --cache-type-v q4_0 \ -fa 1 -np 2 \ --temp 0.6 \ --no-warmup \ --jinja \ --seed 42 \ -b 128 -ub 128 \ --threads 8 --threads-batch 12 \ --spec-type draft-mtp --spec-draft-n-max 0.75 \ --host 0.0.0.0 --port 8001 ``` It looks dense, but each piece is doing one specific job. Let me walk through it in groups. **Loading the model onto the GPU.** - `-m` points at the model file. Nothing surprising there. - `-ngl 80` tells the server to put 80 of the model’s layers onto the GPU. A model is built as a stack of layers, and each layer can run either on the GPU (fast) or the CPU (slow). The goal is to put as many layers on the GPU as the VRAM allows. With 24 GB on the card, this setting puts effectively the whole model on the GPU, which is what keeps it fast. **Context size and the cost of memory.** - `-c 262144` sets the context window to 262,144 tokens — the amount of text the model can hold in working memory at once, counting both the conversation so far and the files it is reading. For coding, large context matters a lot. An agent accumulates file contents, command output, and conversation history quickly, and running out of room mid-task is genuinely disruptive. A quarter-million tokens is a lot of headroom. - `--cache-type-k q4_0 --cache-type-v q4_0` is the setting that makes that large context affordable. As the model works, it builds up an internal scratchpad called the KV cache, and that cache grows with the context size. At a large context it can consume more memory than the model weights themselves. These two flags compress the cache to a four-bit format, which is the single most important trick for fitting a big context on consumer hardware. Without it, a context this large simply would not fit on a 24 GB card. **Throughput and quality settings.** - `-fa 1` turns on flash attention, a more memory-efficient way of doing the model’s core attention computation. It saves memory and time at no real cost in quality. - `-np 2` allows two requests to be handled at the same time. I sometimes have a coding agent and a second task both talking to the server, and this lets them share it without one blocking the other. Raise this higher and memory use climbs quickly, so two is a deliberate, conservative choice. - `--temp 0.6` sets the temperature, which controls how much randomness the model uses when choosing each next word. Lower values make it more focused and deterministic; higher values make it more varied and creative. For coding, you want focus, so a value below the default is appropriate. - `--seed 42` fixes the random seed so that, given the same input, the model behaves reproducibly. That is useful when you are trying to understand why something happened. **Operational details.** - `--no-warmup` skips a startup step that is not needed here and gets the server ready faster. - `--jinja` tells the server to use the model’s own chat template — the specific formatting Qwen expects for the back-and-forth between user and assistant. Getting this right matters; the wrong template quietly degrades the model’s responses. - `-b 128 -ub 128` set the batch sizes — how many tokens the server processes in one pass. These are tuned to balance speed against memory on this particular hardware. - `--threads 8 --threads-batch 12` control how many CPU threads do the work that is not on the GPU. **The clever part: speculative decoding.** - `--spec-type draft-mtp --spec-draft-n-max 0.75` enables speculative decoding, and this one deserves a real explanation because it is doing something genuinely interesting. Normally a model generates text one token at a time, and each token requires a full pass through the model. That is the slow step. Speculative decoding speeds it up by having a small, fast “draft” predict several upcoming tokens at once, then having the full model check that batch of guesses in a single pass. When the guesses are right — and for routine code they often are — you get several tokens for the price of one pass. When they are wrong, you fall back to normal generation and lose nothing but a little wasted effort. The `draft-mtp` part uses the multi-token-prediction capability built into this particular model (the `MTP` in its name) to do the drafting, rather than running a separate small model alongside it. The net effect is meaningfully faster generation, which is what makes a local model pleasant rather than merely possible to use. **Where it listens.** - `--host 0.0.0.0 --port 8001` makes the server reachable on port 8001 across my home network rather than only on the machine itself. If you set this up yourself and you do not want it reachable from other devices, bind it to `127.0.0.1` instead, which restricts it to the local machine. A model endpoint left open where others can reach it is worth thinking carefully about; mine is inside my own network behind my own firewall, and that is a deliberate decision, not an accident. I also cap the GPU’s power draw with a separate service. The card will happily pull more power for a small speed gain, and limiting it keeps the office cooler and quieter for a difference in speed I cannot feel during normal work. That is a personal preference, not a requirement. ## The Two Agents A model server by itself just answers requests. To do real work you put an agent in front of it — a program that can read your files, run commands, and iterate on a task. Because llama.cpp speaks the standard OpenAI-compatible protocol, both of the agents I use connect to my local server by pointing them at `http://localhost:8001` instead of a cloud provider. They are the same kind of tool you would otherwise point at OpenRouter. The first is [pi](https://pi.dev), an open-source coding agent that runs in the terminal. It is deliberately minimal — the model gets a small set of tools (read a file, write a file, edit a file, run a shell command) and the rest is built up through skills and extensions. It is provider-agnostic by design, which is exactly why pointing it at a local model is a one-line change rather than a project. This is what I have been using for the actual coding these past couple of weeks. The second is [Hermes](https://github.com/NousResearch/hermes-agent), an agent from Nous Research aimed at always-on, everyday use rather than coding specifically. It keeps memory across sessions, writes and refines its own skills as it goes, can run scheduled tasks on its own, and reaches me through ordinary messaging apps. Where pi is my hands-on coding tool, Hermes is the always-running assistant. Notably, Nous built Hermes with exactly this class of model in mind — Qwen3.6-27B is one of the models it is designed to run well on, which is part of why the whole stack fits together as cleanly as it does. I am not going to claim the local model matches a frontier cloud model on the hardest problems. It does not, and I would not expect a 27B model to. What I will say is that for a large share of day-to-day coding — the reading, the small edits, the routine refactors, the “what does this function do” questions — it has been entirely sufficient, and it has been free. ## Where This Fits The honest framing is not local versus cloud. I use both, and I expect to keep using both. I reach the frontier models through OpenRouter when a problem is hard or novel. I reach the local model on the card under my desk for the steady stream of ordinary work that would otherwise run up a metered bill and send my code to someone else’s servers. What changed for me recently is that the local option crossed from “interesting experiment” to “default for a real category of work.” The model got good enough, the quantization got smart enough, and the tooling got standard enough that the friction mostly disappeared. A used graphics card and a few open-source projects now do work that would have been impractical to run locally not long ago. If you are a small business owner or an individual wondering whether this is worth it, the calculus is the same one I keep coming back to in this work: the cost is the one-time hardware purchase and a weekend of setup; the benefit is capability you own outright, running on your terms, at no marginal cost. For the right kind of work, that math is hard to argue with. * * * I have been running this setup every day, and I am still learning where its edges are. If you are thinking about local AI for your own affairs or for your business and want to talk through whether it fits your situation — the hardware, the model choices, or how to put an agent in front of it — I would welcome the conversation. You can reach me at [john@common-sense.com](mailto:john@common-sense.com) or through [common-sense.com/contact](https://common-sense.com/book/). ## Sources - [pi coding agent](https://pi.dev) - [Hermes Agent (Nous Research)](https://github.com/NousResearch/hermes-agent) - [llama.cpp on GitHub](https://github.com/ggml-org/llama.cpp) - [Hugging Face](https://huggingface.co) - [OpenRouter](https://openrouter.ai) - [Qwen3.6 GGUF models (Unsloth)](https://huggingface.co/unsloth) - [NVIDIA: Hermes and local agents on RTX hardware](https://blogs.nvidia.com/blog/rtx-ai-garage-hermes-agent-dgx-spark/) Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Why JSON-LD Is Cheap Insurance for Your Website | Common Sense Systems URL: https://common-sense.com/insights/why-json-ld-is-the-cheapest-insurance-your-website-can-buy/ [Insights](https://common-sense.com/insights/) # Why JSON-LD Is the Cheapest Insurance Your Website Can Buy By John Sambrook · May 26, 2026 · [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/), [Strategy](https://common-sense.com/insights/tag/strategy/) ## TL;DR Structured data in JSON-LD format tells search engines and AI systems exactly what your business does, where it is, who runs it, and what makes it credible. Websites without it are invisible to the systems that now route most discovery traffic. The fix is not expensive or complex. It is a small block of code that most developers can add in minutes. * * * I spent three days last week auditing the websites of two hundred and fifty businesses on the Seattle Eastside. Acupuncturists, chiropractors, dentists, physical therapists, mental health counselors, med spas, urgent care clinics. The full spread of small professional practices that depend on local discovery. The pattern was stark. One hundred and forty-seven of them had no structured data at all. That is 59 percent. Their websites looked fine. Many were professionally designed. But behind the scenes, they were speaking to Google in a language Google could not understand. And if Google cannot understand what you do, it cannot show you to people who are looking for exactly that. This is not an SEO article. I am not going to talk about keyword density or backlink strategies. This is about a specific, cheap, durable fix that most businesses ignore because they do not know it exists. The fix is JSON-LD, and it matters more now than it ever has. ## What JSON-LD Actually Does JSON-LD stands for JavaScript Object Notation for Linked Data. It is a standardized format for telling machines what is on a web page in terms they can process without guessing. When a human reads a webpage, they see “Dr. Sarah Chen, Licensed Acupuncturist, Kirkland, WA.” When a machine reads the same page without structured data, it sees a bunch of text and has to infer what it means. With structured data, the machine sees a labeled, typed data structure: this is a person, this person has a medical license, this person practices at this address, here is the phone number, here are the hours. That matters because Google does not rank websites by reading them like a human. It ranks them by understanding them as entities in a knowledge graph. The more clearly you describe your entity, the more confidently Google can match you to relevant searches. And the less clearly you describe it, the more you are trusting Google to guess correctly. Which it often does not. ## The Search Visibility Difference Research from 2024 shows that 72 percent of first-page Google results include some form of structured data markup. That is not a coincidence. Google uses structured data to generate rich results: the knowledge panels that appear on the right side of search results, the star ratings under local business listings, the event carousels, the FAQ dropdowns. These rich results take up more visual space on the results page and attract disproportionately more clicks. One study from ClickForest estimates that pages with rich snippet enhancements see approximately 35 percent higher click-through rates than plain text listings. Another study, from Seer Interactive in late 2025, found that organic click-through rates dropped 61 percent for queries where Google displayed an AI Overview. The implication is clear: if you are not in the enhanced results, you are in the shrinking pool of plain blue links that fewer people click. For local businesses, structured data is even more consequential. Google’s Local Pack, the map-and-listing block that appears for searches like “acupuncture near me,” draws its information from a combination of Google Business Profile data and structured data on your website. If the two sources disagree, Google gets confused. If your website has no structured data at all, Google has only the Business Profile to work with. And the Business Profile may not include your credentials, your services, your accepted insurance, or your specific areas of expertise. ## The NAP Consistency Problem NAP stands for Name, Address, Phone. It sounds trivial. It is not. Every directory listing, social profile, review site, and citation of your business has some version of your NAP. If your website says “Seattle Acupuncture & Wellness Center” but Yelp says “Seattle Acupuncture and Wellness Ctr,” and Google Business Profile says “Seattle Acupuncture,” you now have three entities in Google’s index that may or may not be the same business. Google handles uncertainty by downranking. It does not know which entity to trust, so it trusts none of them fully. Structured data fixes this by anchoring your canonical NAP in the one place you control: your own website. When your LocalBusiness schema markup uses identical name, address, and phone fields, and those match your Google Business Profile exactly, you train Google to see one entity with one source of truth. The consistency itself becomes a ranking signal. This is particularly important for healthcare practices. A patient searching for a specific treatment is not just looking for anyone nearby. They are looking for someone credentialed, experienced, and accessible. If your website lists your NCCAOM certification, your years in practice, your specialty areas, and your accepted insurance, but none of that is in structured data, Google has to extract it from plain text. And plain text extraction is error-prone. Your credentials might get missed entirely. ## AI Systems Are Now Reading Your Site Too Search is no longer just Google. In 2025 and 2026, a growing fraction of discovery happens through AI systems: ChatGPT, Perplexity, Claude, and Google’s own AI Overviews. These systems do not crawl the web like search engines. They index it, summarize it, and cite sources. When someone asks Perplexity “who is the best acupuncturist in Kirkland for fertility issues,” Perplexity reads its index of websites and synthesizes an answer. It cites the sources it used. If your website does not have structured data, you are nearly invisible to this process. AI indexing systems weight structured data heavily because it is the only content they can consume without ambiguity. They can read your BlogPosting schema to know what you wrote about. They can read your Person schema to know your credentials. They can read your LocalBusiness schema to know your location and services. Without these signals, you might as well not be in the index. The traffic pattern is already shifting. Studies from late 2025 show that queries triggering AI Overviews divert substantial click volume away from traditional organic results. If your business depends on being found online, and your website has no structured data, you are preparing for a world that no longer exists. ## What Proper JSON-LD Looks Like for a Professional Practice Here is a simplified example. This is not the full markup. It is the conceptual structure. A proper LocalBusiness schema for an acupuncture clinic includes: the business name and type, the address with postal code, the phone number, the website URL, business hours by day, accepted payment methods, the practitioner’s credentials (linked as a Person entity), the services offered (linked as Service entities), a link to the Google Business Profile (via sameAs), and the geographic coordinates. The key is not just that this information exists. It is that it exists in a format that every major search engine and AI system can consume without interpretation. You are not relying on Google to correctly parse “Dr. Chen, Licensed Acupuncturist, practicing in Kirkland since 2015” from a paragraph of text. You are telling it explicitly: - This is a MedicalBusiness. - The practitioner holds this specific license. - The address is this exact geolocated point. - The hours are these specific times. - The profile on Google is this verified URL. The specificity builds trust. Trust builds ranking. ## Which Pages Need What Kind of Structured Data A common mistake is treating structured data as something you add once to your homepage and forget. Different pages serve different purposes, and the structured data should match. Here is what goes where. **Homepage:** This is where you establish your business entity. The primary schema is LocalBusiness or MedicalBusiness. Include your name, address, phone, hours, and a link to your Google Business Profile. You can also add WebSite schema with a search action, which tells Google your site has an internal search function. That is optional but useful. **Service pages:** Each specific service you offer should have Service schema. If you are an acupuncturist, your fertility support page carries Service schema for fertility acupuncture. Your pain management page carries Service schema for pain management. This helps Google and AI systems connect specific queries to specific pages rather than just knowing you are an acupuncturist in general. **Practitioner bios:** About pages and team member profiles should use Person schema. Include name, job title, credentials, education, affiliations, and a link to the LocalBusiness entity they belong to. This creates the connection between the person and the practice that AI systems use when answering queries about specific providers. **Blog posts and articles:** Every post gets BlogPosting schema. Required fields are headline, author, datePublished, and image. Recommended fields are dateModified and description. The dateModified field is particularly important. If you update a post with new information, the dateModified tells search engines and AI systems that the content is current. Without it, they may assume the post is stale. **FAQ pages:** If you have a frequently asked questions page, use FAQPage schema. Each question-answer pair becomes eligible for FAQ rich results in search, which can expand your listing significantly. **Contact page:** This is often the worst-structured page on small business sites. A contact page should carry LocalBusiness schema with your full contact details, hours, and accepted payment methods. Do not assume the homepage schema covers this page too. Each page that contains unique contact information should declare it. **Do you need structured data on every single page?** No. A privacy policy or terms of service page probably does not need custom schema beyond the basic WebPage type that most platforms add automatically. But every page that serves a discovery purpose, that answers a question a potential patient or client might ask, should have structured data that matches its content. ## The Update Problem Here is where most structured data efforts quietly fail. Someone installs it once, validates it, and walks away. Six months later, the phone number has changed, the practitioner has added a new certification, the business moved locations, or a new service replaced an old one. The structured data now says something different from the visible page content. Google calls this a mismatch, and it is one of the fastest ways to lose trust. If your JSON-LD says you are open until 8 PM but your visible hours say 6 PM, Google does not know which to believe. If your schema lists a credential you no longer hold, or a service you no longer offer, you are making claims you cannot substantiate. In the worst case, structured data that contradicts the visible page can trigger a manual review or rich result suppression. For traditional search, this is a gradual credibility erosion. For AI systems, it can be worse. When an AI cites your structured data to answer a question, it treats that information as a factual claim. If the claim is outdated, the AI may repeat it, and you may end up associated with information that is no longer true. The damage to your reputation is harder to recover than a ranking drop because the AI citation lives in someone else’s answer, not on a page you control. ## How to Keep It Current The best approach depends on how your website is built. If you use WordPress with a plugin like Yoast or RankMath, the plugin generates structured data automatically from your page content and settings. The catch is that the plugin only knows what you have entered into its fields. If you update a page directly in the editor without updating the plugin’s schema settings, you still have a mismatch. The fix is to treat schema-related fields as part of the content editing workflow. When you change a service, update the service page, the menu, and the plugin’s service schema all at once. If your site is custom-built or static, you are probably managing JSON-LD by hand. This gives you full control but creates a maintenance burden. The discipline that works is to keep a master data file, a single source of truth for your business information, and generate all JSON-LD from that file. When something changes, you change it in one place and regenerate every block. For the clients we work with, we provide both the initial structured data blocks and a maintenance schedule. We recommend a quarterly review: check the markup against the visible page content, verify that dateModified fields on posts reflect actual updates, confirm that NAP data still matches the Google Business Profile, and validate everything against Google’s test tool. If you change something material, a new service, a new practitioner, a location move, update the structured data the same day. Some changes are easy to miss. If you add a new accepted insurance to your site text but do not add it to your LocalBusiness schema, the old information is still what the machines see. If you publish a blog post update but do not update the dateModified field in the schema, the machines still see the original publication date. These small gaps accumulate into a profile that looks neglected, and neglected profiles do not rank well. ## The Discipline That Matters Structured data is not a plugin you install. It is a representation of your business that you maintain. The businesses that benefit from it treat it like their Google Business Profile or their directory listings: a living document that changes when the business changes. The cost of maintenance is low if you build it into your workflow. The cost of neglect is that your competitors, the ones who keep their structured data current, gradually become the entities that machines trust and cite. ## Why Most Businesses Do Not Have This In my audit of two hundred and fifty Eastside businesses, the reasons fell into three categories. The websites built on DIY platforms, Wix and Squarespace, often had minimal structured data: a WebSite type and maybe a WebPage type. These are generic. They tell Google “this is a website” and nothing more. They do not tell it what kind of business it is, who runs it, or what services are offered. The websites built by web designers on WordPress were more varied. Some had excellent structured data, usually via plugins like Yoast or RankMath that generate it automatically. Others had none at all because the designer never enabled the feature. The designer focused on how the site looked, not on how it communicated with machines. The third category was the most common: small business owners who built their own sites or hired a relative who knew HTML. They had no structured data because nobody told them it existed. This is not a criticism of web designers. Design and user experience matter enormously. But the invisible layer matters too, and it is often neglected because it is invisible. You do not see structured data when you visit a website. You only see its absence when your site does not show up in search. ## What Common Sense Systems Does At Common Sense Systems, we have built a structured data service specifically for professional practices: healthcare providers, therapists, wellness practitioners, and small professional services firms. The way it works is straightforward. We interview you for thirty minutes. We collect your business information: name, address, phone, hours, services, credentials, accepted insurance, languages spoken, accessibility features, everything that should be in your structured data. We then produce a complete, validated JSON-LD block for your website. It includes LocalBusiness, Person for each practitioner, Service for each offering, and proper sameAs links to your Google Business Profile and other verified profiles. We validate the output against Google’s Rich Results Test and Schema.org’s validator before delivery. The markup is designed to be dropped into your website’s header with no modification. Most web developers or site administrators can install it in under five minutes. If you do not have someone who can do that, we can do it for you. The cost is fixed and small relative to the value. And unlike paid advertising, which stops working the moment you stop paying, structured data is a durable asset. It keeps working for as long as it is on your site. ## The Business Case Is Simple If 72 percent of first-page results use structured data, and 59 percent of small business websites do not have it, the competitive opportunity is obvious. This is not a marginal improvement. For many businesses, it is the single highest-return change they can make to their web presence. The cost of adding structured data is measured in hundreds of dollars and a few hours of your time. The cost of not having it is measured in patients, clients, or customers who never find you because a machine could not understand what you do. If you want to know whether your website currently has proper structured data, the fastest way is Google’s own Rich Results Test. Enter your homepage URL and see what it finds. If the result is empty or shows only generic WebPage markup, you are in the majority of businesses that have left this channel unexplored. If you would like help fixing that, or if you just want to sanity-check what your current site is communicating to machines, send me a note at [john@common-sense.com](mailto:john@common-sense.com). I am happy to look at it and tell you what I see. ## Sources - [Google Rich Results Test](https://search.google.com/test/rich-results) - [Schema.org LocalBusiness documentation](https://schema.org/LocalBusiness) - [Schema.org MedicalBusiness documentation](https://schema.org/MedicalBusiness) - [Google: Structured Data General Guidelines](https://developers.google.com/search/docs/appearance/structured-data/sd-policies) - [SchemaApp: Semantic Value of Schema Markup in 2025](https://www.schemaapp.com/schema-markup/the-semantic-value-of-schema-markup-in-2025/) - [ClickForest: Structured Data Guide 2026](https://www.clickforest.com/en/blog/structured-data-google) - [Seer Interactive: AI Overviews CTR Impact Study, 2025](https://www.seerinteractive.com/) - [SEO Sherpa: SEO Statistics for 2025](https://seosherpa.com/seo-statistics/) - [Schema.org: JSON-LD format specifications](https://json-ld.org/) Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # the client CLI as an Organizing Surface | Common Sense Systems URL: https://common-sense.com/insights/device-cli-organizing-surface/ [Insights](https://common-sense.com/insights/) # The Device CLI Was an Organizing Surface, Not Just a Tool By John Sambrook · May 13, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Medical Devices](https://common-sense.com/insights/tag/medical-devices/) ## TL;DR I was contracting with a product development company on the the client defibrillator project. The part of the work that mattered most was not just the firmware. It was the protocol boundary between a Python CLI on the host and the embedded firmware in the device emulator. That boundary became the organizing surface for the product: the commands, queries, and error behavior had to be hammered out there before the rest of the system could settle down. * * * ![A protocol boundary diagram showing a Python CLI, a defibrillator emulator, firmware, and a cellphone UI connected by a structured command layer](https://common-sense.com/images/content/defibrio-organizing-surface.svg) The most interesting part of the the client work was not the firmware by itself. It was the interface between the pieces. I was contracting with a product development firm, the product development company behind the the client defibrillator project, and my part of the work centered on the USB-serial protocol between a Python CLI on the host and the embedded firmware in the device emulator. The defibrillator was entirely powered and controlled from an Android cell phone. That protocol was not an afterthought. It was the interface control document between two teams: the defib hardware and firmware developers on one side, and the Android app developers on the other. It was the place where the implementation got organized. ## The protocol was the product boundary If you only looked at the hardware, you would miss what was really happening. The defibrillator emulator was part of a larger system. There was the embedded firmware. There was the host-side Python CLI. There was the cellphone that powered the system and served as the UI. And there was the command-and-control layer that made all of those pieces behave like one product instead of a pile of parts. That protocol boundary had to answer a lot of questions: - What commands are included? - What queries does the product expose? - What happens when something fails? - How do the host and firmware stay in sync? - What is the right behavior when a packet is corrupted? - How do we make the interface stable enough to verify? Those were not just technical questions. They were product-definition questions. In practice, the protocol spec became the organizing surface for the whole project. The shape of the interface drove what the software could do, how it could fail, and how the team could reason about it. ## What the system looked like The project had a few important pieces: - a defibrillator emulator - embedded firmware on ARM Cortex microprocessors - a Python CLI on the host - USB-serial communication between the two - a cellphone powering the system and acting as the UI - safety-related and regulated-device work around the whole thing The firmware was bare-metal super-loop code, not an RTOS-based system. I also helped with SPI-based device-driver work and with error-checking and profiling tools in NXP’s MCUXpresso IDE. But the most important architectural decision was that the host tool and the firmware were not independent islands. They were paired. ## The protocol spec forced the implementation to take shape A lot of embedded work gets described as “build the firmware” or “write the app.” That is too small for this kind of system. On the client, the protocol spec itself was where the implementation details took shape. The commands, queries, and error behavior were hammered out there so the hardware/firmware team and the Android app team could build to the same contract. That meant the protocol wasn’t just moving bytes. It was organizing how the capabilities would be implemented. That kind of boundary matters because it forces discipline. It keeps the project honest. It also gives both teams one place to discuss what the product behavior really is. That matters even more in a regulated context, where vague interfaces are a liability. ## The hard parts were about trust The protocol had to be reliable enough that the team could trust it. So it used: - length fields - per-packet CRCs - sequence numbers - resync/restart behavior on error The command set eventually grew to roughly 100 commands. That is a lot of surface area for drift. If you hand-maintain that kind of interface in two places, it will eventually get out of sync. So I wrote Python code that auto-generated the protocol definitions for both the Python client and the firmware. I also auto-generated the protocol documentation and the verification test plan, so the protocol, docs, and tests stayed aligned instead of drifting apart. That is the real leverage story. ## Why the host tool mattered The host CLI was not a nice extra. It was part of the system’s organizing layer. The operator used it to drive the device emulator. The project used it to define what the system could do. The team used it to decide what belonged in the interface. And the verification work depended on it because the command set and the error behavior had to be testable. In other words, the tool was part of the product architecture. Not just part of the developer convenience stack. That distinction matters. A lot of embedded projects treat host tooling as a thin wrapper around firmware. Here, the wrapper was doing architectural work. It was organizing the product around a stable and inspectable boundary. ## The regulated context mattered This was a defibrillator project, so the work was not casual. Early in the project, I reviewed system architecture with Jim, George, and Lindsey, and worked with Curtis Wichern on safety-related concerns. I participated in system hazard analysis, helped assemble the system block diagram, and contributed to the regulatory plan in the project development plan. I also worked through `PC-lint` warnings and aligned the code with `MISRA C`\-style guidance. That is the kind of work where you do not want hidden ambiguity. You want the interface to be explicit, stable, testable, and documented. The protocol helped create that clarity. ## The thing I want people to notice The point of this story is not that I wrote a Python script. The point is that I helped create the organizing surface for a regulated embedded product. The protocol boundary defined the product’s behavior, kept the firmware and host tooling aligned, and gave the team a place to reason about commands, queries, and failure modes. That is the sort of work I still like best: - make the boundary clear - keep the pieces in sync - reduce drift - make the product easier to trust - make the system easier to verify If you are building something with real constraints, that usually matters more than cleverness. ## What this means for the rest of my work the client is not an isolated story. It sits alongside the SonoSite device-model tooling, the Verasonics build and licensing work, and the broader Common Sense Systems work around automation and operational improvement. The common thread is this: I like the places where systems become legible. Sometimes that means a protocol. Sometimes it means a build system. Sometimes it means an offer. Sometimes it means a website. The work is the same shape. Make the boundary clear. Then make the rest of the system easier to use. If that is the kind of help you need, I’m available. Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # The Room Where It Happens (Differently) | Common Sense Systems URL: https://common-sense.com/insights/the-room-where-it-happens-differently/ [Insights](https://common-sense.com/insights/) # The Room Where It Happens (Differently) By John Sambrook · March 26, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Strategy](https://common-sense.com/insights/tag/strategy/), [Leadership](https://common-sense.com/insights/tag/leadership/) ![Two people sitting side by side at a table looking at a laptop screen together, with a faint third presence suggested by light from the screen, in a calm library or meeting room setting](https://common-sense.com/images/content/the-room-where-it-happens-differently-hero.webp) ## TL;DR When an AI participates in a problem-solving conversation, people drop defenses they have carried for decades. I have seen it happen twice in the past few weeks. This is not about a better search engine. It is about changing the dynamics of the room, and it scales from a library table to a boardroom. * * * Twice in the past few weeks, I sat down with a business owner to work through their real challenges. Not in a conference room with a slide deck. At a table, side by side, laptop open between us. The AI was on the screen, and the three of us talked. One session was with a wellness practitioner who runs a small clinic. The other was with someone who leads a spiritual practice and healing arts center. A third, with a realtor, is in the works. In each case, the setup was the same: I brought a structured thinking process, the AI brought the ability to hold complexity and research in real time, and the business owner brought what nobody else could bring, which was their actual experience of their actual problem. Within the first twenty minutes of the first session, something happened that I did not fully expect. The person across from me started saying things she had never said to a consultant before. She was not holding back. She was not filtering. She was not managing my reaction. I have been consulting for a long time. That does not happen in normal meetings. ## Why People Stay Stuck Here is a question worth sitting with: why do smart, capable people in well-run organizations tolerate problems for years that they can clearly describe? The standard answers are not wrong. Time pressure. Competing priorities. Budget constraints. But underneath all of those is something more fundamental. People have learned, through decades of painful experience, that raising difficult issues in a room full of humans is genuinely dangerous. Not physically dangerous. Socially dangerous. Politically dangerous. Career dangerous. Everyone who has worked in an organization of any size has watched someone raise a legitimate concern and get punished for it. Not formally, usually. Informally. A shift in how they are perceived. An exclusion from the next conversation. A label: “not a team player,” or “difficult,” or “doesn’t understand the political realities.” So people learn. They learn to read the room before they speak. They learn to calculate: is this observation worth the risk? They learn where the land mines are, the topics that will trigger defensiveness, the questions that will be heard as accusations, the truths that nobody wants surfaced because surfacing them obligates someone to act. This is not cowardice. It is rational behavior in response to real incentives. The land mines are real. The consequences are real. People who have stepped on them remember. The result is that organizations carry enormous amounts of unsaid knowledge. People know what is wrong. They can describe it to their spouse over dinner. They discuss it in the parking lot after the meeting. But it never enters the room where decisions are made, because the social cost of putting it there is too high. ## What Changed in the Room So what was different at that table? Part of it was the physical setup. Sitting side by side rather than across from each other changes the dynamic. You are looking at the same screen, working on the same problem, rather than facing off in a negotiation posture. That matters more than it sounds like it should. But the bigger factor was the AI. When the AI surfaces a difficult observation, nobody has to manage its feelings about it. It has no stake. It is not angling for a contract. It is not trying to be right. It is not carrying history from a previous meeting. It does not have an ego that might be bruised if you disagree. The business owner knows this, instinctively and immediately. So when the AI says, “Based on what you have described, it sounds like roughly half of your one-on-one client time is spent delivering foundational material that could be delivered in a group setting,” there is no defensive reaction. There is just: “Huh. Yes. That is true. I have never thought about it that way.” That same observation from me, a consultant she barely knows, might have landed as criticism. Are you saying I am wasting my time? Are you saying I am doing it wrong? Those are the land mines. The AI walks right over them because it cannot step on them. It does not carry the social weight that triggers defensiveness. I want to be honest about something here: the AI is, in certain respects, a better facilitator than I am. Not because it is smarter. Because it does not carry the conditioning I carry. I have thirty years of reading rooms, calibrating how direct to be, managing the ten simultaneous calculations that any human makes in a sensitive conversation. All of that conditioning is useful, but it also consumes bandwidth that could go toward the actual problem. The AI has no such overhead. It can say the clear thing clearly. ## This Is Not a Better Google Most people, when they think about AI, picture typing a question into a chatbot and getting an answer back. A better search engine. A faster research assistant. That mental model is so widespread that it has become the default, and it is radically incomplete. What happened in these sessions was not research. It was not question-and-answer. It was three-way collaborative thinking. The business owner would describe a frustration. The AI would connect it to a pattern, or ask a clarifying question, or pull up relevant information about her industry in real time. I would notice something in what she said and offer it back. The AI would hold the entire thread, all the connections, all the contradictions, all the stakeholders and their needs, in a way that no human working memory can. The session built on itself. Forty-five minutes in, we had surfaced real structural tensions in her business that she had been feeling for years but had never articulated. Not because she lacked intelligence. Because no environment had ever made it safe and productive to think that carefully about the hard parts. That is a fundamentally different use of AI than asking it to summarize an article or draft an email. And the gap between what people think AI is for and what it can actually do in this mode is enormous. ## The Governance Question I work with and around healthcare organizations. I attend board meetings. I read strategic plans. And what I see, increasingly, is AI strategies that focus almost entirely on operational efficiency: ambient listening in clinics so physicians spend less time on documentation. Voice scribes for nurse handoffs. Automated appointment reminders. Chatbots for patient intake. These are fine. They will save time. They will reduce some friction. And within a year, every health system in the country will have them, because they are straightforward to implement and the vendors are already selling hard. They will be table stakes. What almost nobody is talking about, at the governance level, is using AI to change how the organization thinks. Not how it documents. Not how it schedules. How it confronts its own structural tensions: the ones between departments, between clinical and financial priorities, between what the mission statement says and what the budget actually funds. If you are a board member reading this, I would ask you to consider: what is the harder problem facing your organization? Documentation efficiency, or the fact that three departments are competing for the same constrained resource and nobody can talk about it honestly? Appointment scheduling, or the reality that your cost accounting system is producing conclusions that contradict your actual economics? The operational tools address the first kind of problem. What I am describing addresses the second kind. And the second kind is where the real leverage is. This applies beyond healthcare. A city manager watching two departments fight over budget allocations that both sides know are distorted. A school board trying to reconcile parent expectations with teacher capacity. A nonprofit board that cannot discuss its real strategic tension because the founder is in the room. The structural pattern is the same: smart people, real conflicts, no safe way to surface them. The technology that changes that dynamic is the same technology, regardless of the sector. ## What This Looks Like at Scale I have been building something called the Cascade Valley series to show what this could look like in a larger organization. It is an audio drama set in a fictional community hospital, where a consultant and an AI work with a board, a CEO, department heads, union representatives, and a skeptical commissioner to confront the structural problems that everyone knows about and nobody has been able to resolve. I want to be straightforward about what the series is and is not. It is audio, hosted on YouTube. The production values are modest. If you go there expecting polished entertainment, adjust your expectations. The value is in the script: what actually happens when people sit in a room with an AI and work through real organizational tensions using a structured thinking process. The dialogue, the dynamics, the way conflicts surface and get examined rather than buried. The series portrays situations that will be familiar to anyone who has sat in a hospital board meeting, a city council work session, or a corporate leadership retreat. Three departments all citing space as their growth constraint when the real constraint is staffing. A CFO making service line decisions based on cost allocations that would produce the opposite conclusion if calculated differently. A board commissioner who suspects the organization is stuck in patterns but does not have a framework for naming them. If any of that sounds familiar, the series might be worth your time. Start with [Episode 01, “The Meeting That Went Differently”](https://common-sense.com/insights/the-meeting-that-went-differently/). It is about an hour. By the halfway mark, you will know whether it connects to what you are dealing with. There are six episodes so far, and you can find them all alongside related writing on the healthcare insights page. ## The Pattern Underneath Here is what I think is actually happening, underneath all the specific examples. Human organizations have always been constrained not just by resources but by the limits of human communication. We cannot say everything we know because the social consequences are too unpredictable. We cannot hold all the competing stakeholder needs in working memory at once because there are too many of them. We cannot facilitate a room through a genuine conflict without someone’s ego or anxiety or political calculation derailing the process, because we are human and that is what humans do in groups. For the entire history of organized human effort, these have been fixed constraints. We built workarounds: hierarchy, so not everyone has to be in the room. Voting, so disagreements can be resolved without being resolved. Compromise, so nobody gets what they need but everybody gets something. We learned to call these workarounds “governance” and “best practices” and “the art of management.” But they are workarounds. They exist because the actual problem, which is getting a group of humans to think honestly together about hard things, was too hard to solve directly. I am not claiming AI solves that problem completely. I am saying the constraint has shifted. The thing that was functionally impossible, a room where difficult truths surface without social penalty, where all the complexity stays visible, where the conversation builds rather than fragments, is now possible. I have seen it happen at a library table with one person. The Cascade Valley series imagines it happening in a boardroom with twelve. The question for any leader or board member is not “should we adopt AI?” You are going to adopt AI. Everybody is. The question is whether you adopt it only for efficiency, the table stakes, or also for the thing that could actually change the character of your organization: honest, facilitated, multi-stakeholder thinking about the problems you have been carrying for years. * * * I do not have this all figured out. I am running these sessions one at a time, learning what works, and sharing what I find. If this connects to something you are seeing in your own organization, I would be glad to hear about it. And if you think I am wrong about any of this, I welcome that conversation too. [john@common-sense.com](mailto:john@common-sense.com) Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # I Fired My Registered Agent and Filed It Myself | CSSI | Common Sense Systems URL: https://common-sense.com/insights/fired-registered-agent-claude-code/ [Insights](https://common-sense.com/insights/) # My Registered Agent Charged $400 to File a $70 Form. I Fired Them This Morning. By John Sambrook · March 25, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) ![A terminal window showing neatly organized business filing records next to a crossed-out invoice from a registered agent service](https://common-sense.com/images/content/fired-registered-agent-hero.webp) ## TL;DR I became my own registered agent this morning, filed my Washington State annual report myself, and used Claude Code to download the confirmation documents from Gmail, rename them, file them in my business records repo, and log the whole transaction. Forty-five minutes, $70 in state fees instead of $400 to my attorney. The money is nice, but the real win is a business records system I own and understand completely. * * * ![Infographic showing a 5-step workflow for filing business documents with AI assistance: navigate WA SOS site with Claude Cowork, file Statement of Change and Annual Report for $70, download 5 confirmation PDFs from Gmail via custom tooling, Claude Code proposes filing plan with canonical names, documents filed in Git repo with journal updated. Comparison: old way $400 plus waiting vs new way $70 plus 45 minutes.](https://common-sense.com/images/content/fired-registered-agent-filing-workflow.webp) This morning I sat down to deal with something I have been putting off: filing the annual report for my S-corporation with the Washington Secretary of State. Every year for the past twenty-plus years, my attorney’s office has handled this. They are my registered agent, meaning they receive legal documents on my behalf and handle the state filings. This year the bill was $400. The actual state fee, as I discovered, is $70. I do not have any complaints about my attorney. They have served me well for two decades. But $330 in markup on a form submission is the kind of cost that stops being invisible once you start looking at what things actually cost versus what you are paying. ## What I Did This Morning I used [Claude desktop’s Cowork pane](https://claude.ai) to walk me through the process on the Secretary of State website. This is a pattern I have gotten into: I drag a screenshot of whatever I am looking at into Claude and ask what to do next. The SOS site is not badly designed, but there were several points where the terminology was ambiguous. At one point I hit a choice between two categories of user, and neither description clearly applied to me. I stared at it for a couple of minutes, then sent Claude the screenshot. Clear answer, immediately. That happened more than once during the process. I filed two things: a Statement of Change to make myself the registered agent (replacing my attorney’s firm, Bates & Ely), and the annual report itself. Both went through without issues. Total state fees: $70. Total time including the Claude-assisted navigation: about 45 minutes. ## The Part That Matters More Than the $330 After I submitted both filings, the Secretary of State sent a flurry of emails to my Gmail: confirmation letters, the annual report itself, a payment receipt, a Statement of Change confirmation. Five PDF attachments across three emails. This is where the system I have been building over the past several months earns its keep. I keep my business records in a Git repository. Not some of them. All of the ones I can manage: Washington State filings, IRS documents, City of Kirkland business license records, accounting ledgers (in [Beancount](https://common-sense.com/insights/fired-quickbooks-built-something-better/)), bank statements, credit card statements, receipts. Claude Code works with this repo according to a schema that defines where everything goes and how files should be named. When I need to file a document, I drop it into a folder called To-Be-Filed and tell Claude there is something new. Claude reads the document, figures out what it is, and files it with a canonical name that makes sense even in a raw directory listing. For the Secretary of State documents, I did not even need the drop folder. I told Claude Code to pull the PDF attachments from the Gmail messages and file them. I have [my own Gmail tooling](https://common-sense.com/insights/saas-subscriptions-ai-coding-agents/) that Claude Code can use to download attachments, which the standard Gmail MCP cannot do. A few sentences of instruction, and Claude downloaded all five PDFs, identified each one, proposed a filing plan with canonical names, detected that one attachment was a duplicate of a file I had already downloaded manually, flagged it, and asked me to confirm before proceeding. Here is what that filing plan looked like: ![Claude Code terminal showing a proposed filing plan table with five PDF documents: payment receipt, annual report, annual report confirmation, statement of change, and statement of change confirmation — each mapped from its original filename to a canonical name with date prefix and destination folder](https://common-sense.com/images/content/claude-code-filing-plan-table.webp) Source File Document Canonical Name Payment-Receipt-WA-SOS-Annual-Report-Filing-Fee.pdf Payment receipt ($70) 2026-03-25-WA-SOS-Annual-Report-Payment-Receipt-70.00.pdf 0023914847\_OnlineReport.pdf Annual Report (3 pages) 2026-03-25-WA-SOS-Annual-Report.pdf 0023914847\_ConfirmationLetter.pdf Annual Report confirmation 2026-03-25-WA-SOS-Annual-Report-Confirmation.pdf 0016638985\_OnlineReport.pdf Statement of Change (registered agent) 2026-03-25-WA-SOS-Statement-of-Change.pdf 0016638985\_…ConfirmationLetter.pdf Statement of Change confirmation 2026-03-25-WA-SOS-Statement-of-Change-Confirmation.pdf ![Claude Code terminal showing completion summary: five documents filed to Regulatory/WA-Secretary-of-State/, journal entry added for 2026-03-25, WA Annual Report moved to Completed on punch list, new expiration date 03/31/2027](https://common-sense.com/images/content/claude-code-filing-summary.webp) All five documents went into `Regulatory/WA-Secretary-of-State/` in my repo. Claude also updated my journal file with an entry documenting the transaction and moved “WA Annual Report” from pending to completed on my punch list. That journal is worth mentioning. Every significant transaction I do with Claude Code gets logged. If I ever need to answer “Did I file this report? When? Where is it?” the answer is in the journal. If I am ever audited, I will have better documentation of what happened and when than most businesses ten times my size. That is a good feeling. ## What I Actually Like About This It is not really the $330. That is a nice number, and it adds up over years, but the money is secondary. What I like is that I understand my own business records now. I know where everything is. I know what the naming convention is. I know what I filed last year and the year before. I am not dependent on someone else’s filing system, someone else’s timeline, or someone else’s priorities. When my attorney’s office had my minute book, I would occasionally need something from it and have to call and wait. Now it is in a repo on my machine, version-controlled, searchable, and backed up. When the Secretary of State sends me documents, they are filed within minutes, not whenever it fits someone else’s schedule. This is the same pattern I described when I [replaced QuickBooks](https://common-sense.com/insights/fired-quickbooks-built-something-better/) and when I [started canceling SaaS subscriptions](https://common-sense.com/insights/saas-subscriptions-ai-coding-agents/). Each individual change saves some money. But the cumulative effect is something different: I am running my business on systems I built, I understand, and I control. The records are mine in formats I can read. The processes run on my schedule. When something needs to change, I describe the change and it happens. ## This Extends Beyond Business I have started doing the same thing with personal records. Insurance policies, property documents, medical records. The same repo-plus-Claude-Code pattern works for anything that involves documents that matter and that you might need to find later. There is a practical reason to do this that goes beyond convenience. Someday, someone else will need to make sense of my records. An executor, a family member, a professional advisor. A well-organized, clearly named, searchable archive with a journal documenting what happened and when is a genuine gift to the people who come after you. It is also, frankly, a gift to your future self. I have wasted more hours than I want to admit searching for documents I knew I had but could not find. ## The Broader Point If you are a small business owner paying a few hundred dollars a year for someone to submit a form on your behalf, it is worth asking: what would it take to do this myself? The answer used to be “more hassle than it’s worth.” That is increasingly not the answer anymore. Claude Code is not magic. I still had to sit down and work through the SOS website. I still had to read the confirmation emails. I still had to review and approve the filing plan before Claude executed it. But the work that used to justify outsourcing, the tedious parts like navigating ambiguous government websites, downloading attachments, renaming files, maintaining an organized filing system, keeping a log, all of that is handled by the AI. I pay Anthropic $100 a month for Claude Pro with Claude Code access. The $330 I saved this morning covers more than three months of that subscription. And I use Claude Code for everything else too: accounting, invoicing, code, writing, analysis. The math has changed. For a lot of small business administration, the cost of doing it yourself with AI assistance is now lower than the cost of paying someone else to do it for you. Not theoretically. Right now, this morning, on my actual business. If you are looking at your own service providers and vendor relationships and wondering whether the switching cost is still what you think it is, I would be happy to think through it with you. Reach me at [john@common-sense.com](mailto:john@common-sense.com). Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # AI Agent Uses Evaporating Clouds Autonomously | Common Sense Systems URL: https://common-sense.com/insights/what-happens-when-ai-uses-evaporating-clouds/ [Insights](https://common-sense.com/insights/) # What Happens When an AI Agent Uses Evaporating Clouds? By John Sambrook · March 19, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Strategy](https://common-sense.com/insights/tag/strategy/) ![Infographic showing an AI-driven iteration loop using Theory of Constraints: a circular 10-step process with Evaporating Cloud breakthroughs highlighted at iterations 5 and 10, alongside a score progression chart showing Testability, Value, Difficulty, and Failure Modes improving across iterations](https://common-sense.com/images/content/ai-evaporating-clouds-iteration-loop.webp) ## TL;DR I built an AI agent that improves business ideas using TOC Thinking Processes, including Evaporating Clouds. Pointed at itself, it ran 10 iterations and resolved two genuine tensions — thoroughness vs. adoption friction, and speed vs. depth of output. The full tool and iteration log are open source. * * * On March 18, 2026, I attended Peter Cronin’s TOCICO webinar, “Thinking Better with AI: Using TOC to Ask the Right Questions.” Peter is the Head Instructor at [Black Belt in Thinking](https://blackbeltinthinking.com) and has taught TOC Thinking Processes to over 250 people across four continents. His talk hit close to home, because I have been building exactly what he was describing — an AI agent that applies the Thinking Processes to real problems, autonomously. I want to show what that looks like in practice. ## What I built The tool is straightforward. You give it a rough business idea. It asks clarifying questions — what problem does this solve, who is the customer, what is the mechanism, what makes it hard to copy — and writes a structured seed document. Then it runs N iterations autonomously. Each iteration, the agent picks one improvement move from a catalog of seven: Move Name When to use 1 Make it more concrete Idea is vague; testability is low 2 Reduce human dependency Too many manual steps 3 Adjust scope Value is low (broaden) or unfocused (narrow) 4 Improve clarity Coherent but hard to explain 5 Resolve tension (Evaporating Cloud) A buried dilemma 6 Research and ground Assumptions need evidence 7 Break oscillation (Magic Druids) A recurring swing between two approaches It scores each variant on four dimensions — testability, value, implementation difficulty, failure modes — and keeps the best. Every move is recorded in an iteration log with before/after scores and a one-sentence rationale. The [Evaporating Cloud](https://common-sense.com/insights/ai-facilitated-constraint-resolution/) is the most interesting part. In Theory of Constraints, an Evaporating Cloud is a diagram that maps a dilemma: two legitimate needs that appear to conflict. You write out both sides, surface the assumptions connecting them, and look for the one assumption you can break. When you find it, the conflict dissolves. The agent does this autonomously — building real clouds, naming real assumptions, and producing injections that change the idea. Move 7 uses the [Magic Druids](https://blackbeltinthinking.com/blog/introducing-the-magic-druid-thinking-tool/) tool, developed by James Powell and Peter Cronin and accepted into the TOCICO Body of Knowledge. Where the Evaporating Cloud resolves a one-time conflict, Magic Druids breaks a recurring oscillation — a pattern where you keep swinging between two behaviors because each one’s side effects push you toward the other. ## The test: improving its own design I pointed the tool at itself. The seed idea was vague: “an autonomous idea-improvement system that uses TOC.” Starting scores: T:8 / V:7 / D:8 / F:6. Here is the 10-iteration progression: Iteration Move T V D F New best? Seed — 8 7 8 6 — 1 Make concrete 9 7 8 6 Yes 2 Narrow scope 9 8 8 6 Yes 3 Reduce human dependency 9 8 7 7 Yes 4 Clarity 9 8 7 7 Replaced 5 **Evaporating Cloud** 9 **9** 7 7 **Yes** 6 Make concrete 9 9 7 7 Replaced 7 Broaden scope 9 9 6 7 No 8 Reduce human dependency 9 9 7 7 Yes 9 Clarity 9 9 7 7 Replaced 10 **Evaporating Cloud** 9 9 **8** **8** **Yes** The two biggest jumps came from Evaporating Clouds — iterations 5 and 10. Not from the mechanical moves (make concrete, adjust scope, improve clarity), which produced incremental gains. The structural breakthroughs came from surfacing and resolving buried conflicts. ## The two clouds ### Tension 1: Thoroughness vs. adoption friction (iteration 5) The tool needed to be thorough — 10 iterations, adversarial scoring, full audit trail — AND easy to adopt. Consultants will not sit staring at a terminal for 15 minutes. The agent built a cloud. The conflict was between a fast, minimal process (satisfying the need for low adoption friction) and a deep, multi-iteration process (satisfying the need for quality output). The assumed conflict: fast and thorough cannot coexist. The challenged assumption: “Low friction means a fast process.” That is wrong. Startup friction — how hard it is to begin — and wait friction — how annoying it is to wait — are different things. Wait friction disappears if the process runs in the background. The injection: run the iteration loop as a background process. You brief the tool in 30 seconds and read the output when you are ready. The product reframing shifted from “a tool you use” to “an assistant you brief and check in on.” Value jumped from 8 to 9. ### Tension 2: Fast-to-read vs. deep-to-audit (iteration 10) The output needed to be immediately actionable — consultants want answers, not reading assignments — AND trustworthy, with visible reasoning and nothing hidden. The challenged assumption: “Low reading time means a single short document.” Also wrong. Reading time and document depth are not coupled if the document is layered. The injection: a layered report. Verdict (30 seconds of reading), Summary (5 minutes), Full reasoning (on demand, linked but not required). Readers who need speed stop after the Verdict. Readers who need to verify keep reading. Both difficulty and failure modes jumped from 7 to 8 — because the layered format was actually _simpler_ to implement than the previous multi-file output structure. The structural simplification reduced both implementation work and cross-file inconsistency risk. A genuine win-win. ## What I notice The clouds the agent produces are not perfect. A skilled human facilitator — someone like Peter Cronin who has run hundreds of these — would probably surface subtler assumptions and push harder on whether the injections truly dissolve the conflict or just defer it. I am genuinely curious about that gap. But the fidelity is higher than I expected. The agent does not hand-wave. It names specific assumptions, challenges them with specific reasoning, and produces injections that measurably change the idea. You can trace every step in the iteration log. The more interesting question is what happens when the Thinking Processes are available at iteration speed. A human facilitator might run one Evaporating Cloud in a two-hour workshop. This agent ran two in 15 minutes, alongside eight other improvement moves. That does not make it better than a facilitator — the quality of a single human-run cloud may be higher. But the speed changes what is practical. You can afford to resolve tensions early, when the idea is still forming, rather than saving the heavy tools for later. ## See for yourself The full tool — every reference file, the scoring rubric, the move selection heuristics, the TOC Thinking Processes reference, and the complete self-improvement run with both resolved clouds — is open source: **[github.com/jsambrook/cssi-plan-generator](https://github.com/jsambrook/cssi-plan-generator)** Start with the [iteration log](https://github.com/jsambrook/cssi-plan-generator/blob/master/runs/self-improvement/iteration-log.md) to see the full progression, or the [report](https://github.com/jsambrook/cssi-plan-generator/blob/master/runs/self-improvement/report.md) for the summary. The [TOC Thinking Processes reference](https://github.com/jsambrook/cssi-plan-generator/blob/master/references/toc-thinking-processes.md) that the agent uses covers the full TP toolkit: Current Reality Tree, Evaporating Cloud, Magic Druids, Future Reality Tree, Negative Branch Reservation, Prerequisite Tree, and Transition Tree. I am particularly interested in hearing from people who work with the Thinking Processes professionally. Does what the agent produces match your experience of how these tools work? Where does it fall short? What would you do differently? I could be wrong about the quality of these AI-generated clouds. That is exactly why I want the conversation. You can reach me at [john@common-sense.com](mailto:john@common-sense.com). Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # After the First Session -- AI Facilitation | Common Sense Systems URL: https://common-sense.com/insights/after-the-first-session/ [Insights](https://common-sense.com/insights/) # After the First Session By John Sambrook · March 18, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Strategy](https://common-sense.com/insights/tag/strategy/) ## TL;DR After the working group disperses, Commissioner Tanaka stays behind and talks with Sam about what just happened. The conversation surfaces why AI-facilitated group sessions work differently than conventional meetings: not because AI is smarter than the humans in the room, but because it operates outside the status dynamics that distort how smart people talk to each other. * * * ![An empty hospital conference room after a meeting, whiteboards still marked up, coffee cups left behind, one person sitting at the table looking at a terminal with a steady amber light at the far end](https://common-sense.com/images/content/after-the-first-session.webp) ## What happens in this episode This is a quiet episode. Two voices in an empty room. Commissioner Tanaka, the board liaison to the working group, stays behind after the session from [Episode 05](https://common-sense.com/insights/the-first-session/). Sam’s terminal is still on. Tanaka moves to the table, sits down, and asks a simple question: what did you do? What follows is a ten-minute conversation about the mechanics of what just happened. Sam explains how it designs questions so that the honest answer is also the safe answer. Tanaka pushes on whether a human facilitator could do the same. Sam is honest: yes, but with two differences. A human facilitator carries social weight in the room. Sam does not. And Sam’s preparation depth, reading the scheduling literature, the throughput research, the contract language before the meeting, is a volume and speed difference. The conversation goes deeper. Tanaka asks why humans are bad at this, given that we know about cognitive bias and teach it in business school. Sam’s answer is that the behavior is not a mistake. Status preservation is an ancient and well-calibrated strategy. It worked for a hundred thousand years. It stops being helpful when the rational thing to do for your position conflicts with the rational thing to do for the system. They talk about what Sam held back. Sam chose not to raise surgeon-level block utilization data in the opening minutes because the room was not ready. Sam let Fleming be the one to surface the contract contradictions because her credibility on nursing issues is something Sam cannot replicate. This is not just questioning. It is strategic sequencing, and Tanaka notices the implications. The conversation lands on a principle that Sam operates under: a solution that creates losers is not a solution. It is a problem that has been moved. Sam attributes this to [Eli Goldratt](https://en.wikipedia.org/wiki/Eliyahu_M._Goldratt) and the [Theory of Constraints](https://common-sense.com/insights/the-meeting-that-could-not-have-gone-differently/), and names my firm, [Common Sense Systems](https://common-sense.com/), as the source of the analytical framework. I learned from Goldratt directly and have been applying TOC since the early nineties. Sam is a way of applying that methodology at a pace and scale that a single facilitator cannot easily match. ## Why I wrote this episode The ensemble episode ([Episode 05](https://common-sense.com/insights/the-first-session/)) shows the effect of AI-facilitated group analysis. This episode explains the mechanism. I wanted a conversation that could articulate, in concrete terms, why the working group session went differently than any meeting Tanaka has seen in six years on the board. The core insight is one I keep returning to in my own work: AI’s value in group settings is not superior intelligence. It is what I would call social weightlessness. Sam does not experience the social cost of asking a question that implies someone’s proposal might be wrong. That is not courage. It is an absence. And that absence, combined with thorough analytical preparation, creates conditions where a group can arrive at the truth faster than they would on their own. This is not a theoretical claim. I have been facilitating sessions using this approach, and the pattern holds. When you remove the status dynamics from the questioning process, the group’s own knowledge surfaces faster and more completely. The answers are always in the room. The question is whether the conversational structure allows them to be spoken. ## The “no losers” principle There is a moment in the episode where Tanaka asks Sam what happens if the working group’s recommendation feels like a loss for the department heads. Sam’s response is the principle I operate under in every engagement: a solution with losers is wrong in some way that has not been identified yet. This comes directly from Goldratt’s work. If your proposed solution requires someone to absorb a loss, you have not found the real constraint. You have found a compromise. Compromises break down under pressure because the people who absorbed the loss have every reason to undermine the result. In the Cascade Valley context, this means the working group cannot simply recommend “fix staffing instead of building” and expect the department heads to get on board. The recommendation has to show each department head that their throughput goals are met through a faster and less expensive path. If it cannot do that, the recommendation is not ready. Something has been missed. This principle is not idealism. It is a diagnostic tool. When someone in the room is losing, that is signal that the analysis is incomplete. ## The series so far If you are new to the Cascade Valley series: [Episode 01: The Meeting That Went Differently](https://common-sense.com/insights/the-meeting-that-went-differently/) is the 56-minute board meeting where Sam participates for the first time. [Episode 02: After the Meeting](https://common-sense.com/insights/after-the-meeting/) follows CNO Barbara Fleming as she discovers structural conflicts in nursing contracts. [Episode 03: Resolving a Sweet Dilemma](https://common-sense.com/insights/resolving-a-sweet-dilemma/) is a standalone teaching episode on the Evaporating Cloud tool. [Episode 04: The Other Calculation](https://common-sense.com/insights/the-other-calculation/) follows CFO Steven Park as he discovers the gap between cost accounting and throughput accounting. [Episode 05: The First Session](https://common-sense.com/insights/the-first-session/) is the ensemble working group episode where the private discoveries from earlier episodes enter a room and converge. Episode 06, this one, is the quiet conversation afterward that explains why it worked. ## The question this episode raises Near the end of the conversation, Tanaka brings up Jess Reeves. A staff nurse who found nine structural contradictions in a labor contract on her phone in an evening. Sam’s response: the tools have changed faster than the institutions that use them. This is the thread that runs underneath the whole series. The analytical capabilities that used to require specialized expertise and significant time now require curiosity and a phone. The question for every organization is whether to embrace that shift or try to manage it. Embracing it means distributing the capability. Managing it means restricting it to certain roles and contexts. I think the answer is obvious, but I also understand why it makes people nervous. If your professional value is built on being the person who understands the system, it is unsettling when a twenty-nine-year-old with a phone can see what you see. But the system benefits from being understood by more of its participants. That is not a threat. It is the point. If you are thinking about how AI-facilitated analysis could work in your organization, whether for strategic planning, constraint identification, or multi-stakeholder problem-solving, I would be glad to talk it through. [john@common-sense.com](mailto:john@common-sense.com). Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # The First Session -- Hospital Working Group | Common Sense Systems URL: https://common-sense.com/insights/the-first-session/ [Insights](https://common-sense.com/insights/) # The First Session By John Sambrook · March 18, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Operations](https://common-sense.com/insights/tag/operations/) ## TL;DR Three department heads walk into a working group prepared to defend competing capital requests. Ninety minutes later, they have identified a common upstream constraint that no amount of construction will resolve. The shift happens not because anyone was told they were wrong, but because an AI asked factual questions whose honest answers pointed somewhere none of them expected. * * * ![A hospital conference room with twelve chairs around a long table, whiteboards marked with blue handwriting, coffee cups left behind, and at the far end of the table a terminal with a steady amber light](https://common-sense.com/images/content/the-first-session.webp) ## What happens in this episode This is the ensemble episode. The board has given CEO Margaret Aldridge six weeks and a working group to come back with a recommendation on three competing capital expansion requests from Cardiology, Musculoskeletal, and Gastroenterology. The room holds twelve people: three department heads, the CFO, the COO, the CNO, the president of the medical staff, a board liaison, a twenty-nine-year-old nurse who is not sure why she was invited, and Sam. Sam asks five questions. That is all Sam does in this episode. Five questions over ninety minutes. The first one lands in the opening minutes, before anyone has presented a slide: each department has identified physical space as its primary constraint on growth, but the existing facilities sit dark for roughly three-quarters of every week. What prevents the use of those spaces during the remaining hours? The question is factual. The answer turns out to be simple: staffing. The rooms are not empty because patients are unavailable. They are empty because the staffing model does not extend beyond the core window, and the contract structures make extending it difficult even when everyone agrees it would help. From there, the CFO shares a throughput calculation he has been holding for barely two days. The CNO connects labor contract contradictions to scheduling barriers. And a staff nurse demonstrates that the tools to find structural problems in complex documents are now in everyone’s pocket. ## What I was trying to do The earlier episodes in this series followed individuals. Fleming alone with a contract at her kitchen table. Park alone with a spreadsheet at his desk. Those were private moments of discovery. This episode is about what happens when private discoveries enter a room full of careers, hierarchies, and alliances. The challenge in writing this was dramatizing a group shift without making it feel scripted. In real working groups, the shift from “defending my request” to “diagnosing a shared problem” does not happen because someone gives a speech. It happens when the conversational structure makes the honest answer easier to say than the rehearsed one. That is what Sam provides. Not intelligence. Not recommendations. A different kind of gravity. I wanted to show Sam’s method concretely. Sam does not challenge anyone’s proposal. It asks what prevents the use of existing capacity. The answer, which every department head already knows, leads directly to the conclusion that space is not the binding constraint. But arriving at that conclusion together, in their own words, is a fundamentally different experience than being told by an AI at a board meeting. ## What is real here The hospital is fictional. The characters are fictional. The dynamics are not. Capital expansion requests competing against a limited budget while the existing facilities sit underutilized is a pattern I see in hospital after hospital. The staffing constraint that prevents extended utilization is real and well documented. The labor contract contradictions that Fleming identifies are based on structural conflicts I have mapped in actual Washington State collective bargaining agreements. And the throughput calculation Park presents uses numbers consistent with published OR cost literature. The moment where a nurse finds nine contract contradictions on her phone in an evening is real in the sense that matters most. The tools to do this exist now. The question is not whether frontline workers will use them. It is whether institutions will treat that as an asset or a threat. ## The series so far If you are new to the Cascade Valley series: [Episode 01: The Meeting That Went Differently](https://common-sense.com/insights/the-meeting-that-went-differently/) is the 56-minute board meeting where Sam participates for the first time and asks the questions nobody else was positioned to ask. [Episode 02: After the Meeting](https://common-sense.com/insights/after-the-meeting/) follows CNO Barbara Fleming through the week after the board meeting as she discovers structural conflicts in nursing contracts. [Episode 03: Resolving a Sweet Dilemma](https://common-sense.com/insights/resolving-a-sweet-dilemma/) is a standalone teaching episode that walks through the Evaporating Cloud tool using a bakery pricing dilemma. [Episode 04: The Other Calculation](https://common-sense.com/insights/the-other-calculation/) follows CFO Steven Park as he discovers the gap between cost accounting and throughput accounting. Episode 05, this one, brings those private discoveries into a room and shows what happens when they meet. [Episode 06: After the First Session](https://common-sense.com/insights/after-the-first-session/) is the quiet conversation afterward — Commissioner Tanaka stays behind and asks Sam why the session went differently than any meeting he has seen in six years. ## The question underneath Nothing was decided in the first session. No capital request was approved or denied. No contract was renegotiated. By the usual measures of organizational productivity, the meeting produced nothing. But twelve people stopped defending separate positions long enough to see a shared constraint. That shift, from local optimization to system-level diagnosis, is the hardest thing to achieve in any organization. It usually takes months, a crisis, or both. In this episode, it takes ninety minutes and five questions. The Theory of Constraints calls the underlying problem a “policy constraint.” The departments are not limited by physical space. They are limited by the policies, contracts, and scheduling conventions that govern how existing space gets used. Policy constraints are harder to see than physical ones because they look like “the way things work.” They persist because the cost of naming them in a room full of colleagues is higher than the cost of working around them. Until it is not. Until someone asks a question that makes the honest answer the easy answer. If you are leading a working group, a strategic planning process, or any multi-stakeholder effort where the people in the room each hold a piece of the truth but nobody is assembling the picture, I would welcome the conversation. [john@common-sense.com](mailto:john@common-sense.com). Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Where Does the Money Come From? | Common Sense Systems URL: https://common-sense.com/insights/where-does-the-money-come-from/ [Insights](https://common-sense.com/insights/) # Where Does the Money Come From? By John Sambrook · March 18, 2026 · [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Strategy](https://common-sense.com/insights/tag/strategy/) ## TL;DR A public hospital’s operating loss is covered by taxpayer levies. But taxpayers can only pay from their own surplus, the gap between what they earn and what they spend. That gap is profit. The institution runs on it. The real question is not whether profit is acceptable but whether the system generates enough surplus for everyone it serves, and whether that surplus gets allocated without creating losers. * * * ![A simple flow diagram showing household surplus flowing through tax levy into public hospital operations, connecting profit to mission](https://common-sense.com/images/content/where-does-the-money-come-from.webp) Last night I sat in the back row of a public hospital board meeting in the Pacific Northwest. A group of union members had come to speak during public comment. This is not unusual. Groups with something to say show up, say it, and the board listens. It’s how public governance is supposed to work, and everyone in the room handled it well. The union members were respectful and clear. The board and executive staff listened carefully. That part was not the problem. But something about the evening stuck with me. Not anything that was said, exactly. More the shape of the conversation. There was a familiar undercurrent: this is a non-profit hospital, and therefore the people who run it should behave differently than if it were a for-profit enterprise. The workers’ interests should come first, or at least ahead of financial concerns, because this institution exists to serve the community, not to make money. I’ve watched this dynamic play out at many board meetings over the past six months. And I think there’s an error in it that’s worth examining. This hospital operates at a loss. The gap between what it earns from patient care and what it spends to deliver that care runs to tens of millions of dollars a year. The difference is made up by taxpayers through the public hospital district levy. That’s the design. It’s legal, it’s transparent, and it keeps the doors open. Here is the question I want to ask: Where does that tax money come from? It comes from the residents of the district. They pay property taxes, and a portion flows to the hospital. But those residents can only pay taxes on money they didn’t need for something else. The tax comes from the gap between what each household earns and what it must spend on its own needs. That gap has a name. It’s called profit. Or surplus, if you prefer the word. The nurse who works at this hospital and pays property taxes that fund the levy can only do so because her household earns more than it spends. Her surplus keeps the doors open. So when profit gets treated as a dirty word, as something that taints the motives of anyone associated with it, I find myself confused. The institution that people want to protect from the influence of profit is itself funded by profit. Not by corporate profit, but by thousands of small household surpluses accumulated across a tax district. The mechanism is the same. Someone produced more value than they consumed, and the excess was redirected to a shared purpose. I am not making a political argument here. I’m making a structural observation. Every sustainable system, whether it files taxes as a non-profit or a for-profit, must generate more value than it consumes. When it doesn’t, someone else has to cover the gap. And whoever covers the gap can only do so from their own surplus. A hospital that loses tens of millions a year is not in a virtuous position. It’s in a dependent one. That dependency isn’t shameful; the community chose to create this institution and chose to fund it through taxes. But it means the hospital’s ability to fulfill its mission is contingent on the economic health of the people it serves. If their surpluses shrink, so does the hospital’s lifeline. This is where the real conversation should be, I think. Not “is profit good or bad?” but “is this system generating enough surplus for everyone it’s supposed to serve?” That question includes the workers. It includes the patients. It includes the taxpayers. And it includes the institution itself, which needs operating surplus to fund equipment, attract talent, and invest in the future without going back to the tax base for every dollar. When union members show up at a board meeting, they are making a claim on surplus. They want more of it directed toward compensation and working conditions. That is not an illegitimate claim. But notice: they are not arguing against surplus. They are arguing about how it gets allocated. Everyone in the room, workers, administrators, commissioners, taxpayers, implicitly agrees that surplus must exist. The disagreement is over distribution. Framing it as “people vs. profit” obscures this. It turns a design question into a moral argument. And moral arguments, in my experience, tend to produce heat rather than solutions. There’s a principle I come back to often in my work: any solution that creates losers is wrong in some way. Not wrong because it’s immoral, necessarily, but wrong the way an engineering design is wrong when it produces an unacceptable output. The fix isn’t outrage. The fix is better design. A public hospital that can’t generate operating surplus is a system producing an unacceptable output. Workers who can’t earn a living wage at that hospital: same thing. Taxpayers whose levies keep climbing while services stagnate: same thing. These aren’t competing moral claims. They’re symptoms of a system that hasn’t yet been fully debugged. The word “non-profit” describes a tax filing status. It does not describe a moral state. And the word “profit” describes a structural condition, the existence of surplus, without which nothing in the system works. Not the hospital. Not the tax base. Not the paychecks. If we could set down the moral framing long enough to look at the engineering, I think we’d find more room to move than anyone currently believes. I could be wrong about this. If you see it differently, I’d welcome the conversation. You can reach me at [john@common-sense.com](mailto:john@common-sense.com). Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Insurance Denial Resolved Before Coffee | Common Sense Systems URL: https://common-sense.com/insights/insurance-denial-resolved-before-coffee/ [Insights](https://common-sense.com/insights/) # I Woke Up Worried About a Denied Insurance Claim. Fifteen Minutes Later, I Wasn't. By John Sambrook · March 17, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) ## TL;DR I woke up to a confusing insurance denial that looked like I owed over $1,000. Claude Code cross-referenced the EOB with my policy documents and explained the whole picture in three minutes. Turns out I owed nothing beyond what I was already paying. The same repo pattern I use for my business finances now manages my personal insurance. * * * ![A neat, well-organized filing cabinet contrasted with a messy pile of insurance paperwork](https://common-sense.com/images/content/insurance-denial-filing-hero.webp) ## 4:30 AM, phone buzzing I woke up early this morning to a notification from Aetna. An Explanation of Benefits had come through for a dental visit where I had some cavities filled. Six of the eight line items said DENIED. The “Your Share” column added up to $1,316. I was already annoyed that the dental work had cost $730 out of pocket. Now it looked like I owed another $600 on top of that. At 4:30 in the morning, staring at a phone screen, that is not a pleasant discovery. Fifteen minutes later I got up, made coffee, and sat down at my workstation. But I didn’t call the insurance company. I didn’t start Googling dental codes. I opened a terminal. ## The pattern Over the past few months, I have been [managing my small business finances](https://common-sense.com/insights/fired-quickbooks-built-something-better/) with Claude Code and a Git repository. The approach is simple: I create a repo with a few key files — a CLAUDE.md that tells Claude how the repo is organized, a schema that defines where documents go and how they’re named, a journal for tracking what’s happened, and a README that explains the whole system. This pattern has worked so well for my business that I decided on the spot to do the same thing for my personal insurance. I created a new repo called john-insurance. Set up the CLAUDE.md, the schema, the journal. Created directories for health insurance, auto insurance, and homeowners insurance. The whole setup took about 15 minutes and one cup of coffee. ## The analysis With the repo in place, I dropped in the EOB document and my insurance policy documents. Then I asked Claude Code a simple question: look at this denied claim and tell me what’s actually going on. About three minutes later, Claude printed a summary that laid out the entire situation clearly. Here is what it found: Two claims had been submitted for my dental visit. The first was for preventive and diagnostic services — a cleaning and an evaluation. Those were covered. The second was for restorative work — three composite fillings. Those were denied, along with a fluoride treatment, a pre-diagnostic, and a panoramic x-ray. The reason was straightforward: my dental plan covers preventive services but explicitly excludes “comprehensive dental services.” Fillings, panoramic x-rays, and fluoride varnish fall into the comprehensive category. The denial wasn’t a mistake or an error in coding. It’s simply what my plan covers and doesn’t cover. But here’s the part that mattered most, and the part I would not have figured out easily on my own: the EOB’s “Your Share” column showed $1,316, which is the full billed amount for all the denied services. But my dentist is in Aetna’s network. That means they bill at the contracted rate, not the full rate. The actual amount I owe is $723.83 — the number my dentist had already quoted me and that I was already paying off on a four-payment plan. In other words, I didn’t owe a penny more than I thought. The EOB was accurate but misleading if you didn’t understand the difference between billed amounts and contracted rates. Claude understood that difference. At 5 AM, I did not. ![Claude Code terminal output showing a detailed insurance claim analysis with two claims broken down by service, Aetna's coverage decision for each line item, and an explanation of why the billed amounts differ from the contracted rates](https://common-sense.com/images/content/insurance-denial-claude-analysis.webp) ## What changed There are a few things about this experience that I think are worth sharing. _The anxiety dissolved almost immediately._ I went from “I might owe over a thousand dollars I wasn’t expecting” to “everything is fine, this is just how EOBs work” in about three minutes. That shift happened because I had an assistant that could read the EOB, cross-reference it with my policy documents, and explain the whole picture in plain language. _I’m now on equal footing with my insurance company._ Insurance policies are written in language that is technically precise but practically opaque. EOBs use terminology and formatting that create confusion. This is not always intentional, but the effect is the same: the insurance company understands your policy better than you do. That asymmetry has real consequences. People overpay. People don’t appeal when they should. People accept denials that aren’t legitimate. Having an AI that can read and cross-reference these documents puts the informational advantage back in your hands. _My important documents are now organized and accessible._ Every EOB, every policy document, every piece of correspondence is filed in a structured, searchable system. The schema tells Claude where things go and how to name them. I can drop a new document into a “to be filed” folder, and Claude will read it, figure out what it is, and file it in the right place with the right name. No intervention needed. _It connects to my email._ Claude Code can use Gmail tooling that I’ve set up, which means it can search my inbox, read messages, and send emails on my behalf. You can see this in the screenshot — after completing its analysis, Claude offered to draft an email to my dentist’s office. That’s the whole loop: a document arrives, Claude reads and files it, analyzes the situation, and can act on it by sending correspondence. I’m not copying and pasting between five different apps. It’s one conversation. _This is a gift to whoever comes after me._ I’m 66. Sometime — hopefully far in the future — someone else is going to need to sort through my affairs. When that day comes, they won’t find a drawer full of envelopes and a filing cabinet stuffed with papers in no particular order. They’ll find an organized repository with a README that explains everything. ## What’s next I set up placeholder directories for my auto insurance and homeowners insurance. I plan to populate those the same way — drop in the policy documents, let Claude build the picture. Once that’s done, I’ll have structured, comparable data across all my insurance coverage. That means I can do something I’ve never been able to do efficiently: shop for better rates with real comparisons. Not “this company quoted me $X and that one quoted me $Y.” Actual apples-to-apples comparisons of coverage limits, deductibles, exclusions, and total cost. I can have agents compete for my business, and I can verify their claims against the actual policy language. I am genuinely looking forward to reviewing my auto insurance. That is not a sentence I ever expected to write. ## This is something I can help you do I do not think there is anything particularly magical about what I’m doing here. The pattern is simple: structured repo, clear schema, good instructions for the AI, and then just asking it questions in plain English. The part that takes some experience is the initial setup — knowing how to structure the repo, what to put in the CLAUDE.md, how to write a schema that’s specific enough to be useful. That’s what I’ve been refining over months of doing this for my business. If you’re a small business owner, a sole proprietor, or just someone who wants to stop dreading insurance paperwork, I can sit down with you for an hour or two and help you set this up for yourself. You don’t need to be technical. You don’t need to know how to code. If you can have a conversation, you can use these tools. The tools are available today. Claude Code is one option. Anthropic’s Claude with the Co-Work feature is another that doesn’t require any command-line experience at all. The important thing isn’t which tool you use. It’s the pattern — the scaffolding that turns a general-purpose AI into a personal assistant that knows your documents, understands your situation, and can answer your questions in seconds. I want other people to experience the sense of freedom and control and peace of mind that I got this morning. Being able to wake up to a confusing insurance denial and resolve it before my coffee got cold — that changes your relationship with these institutions. It puts the power where it belongs: in your hands. * * * _John Sambrook is the principal of Common Sense Systems, Inc. in Kirkland, Washington. Reach him at [john@common-sense.com](mailto:john@common-sense.com)._ Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # I Fired QuickBooks and Built Something Better | Common Sense Systems URL: https://common-sense.com/insights/fired-quickbooks-built-something-better/ [Insights](https://common-sense.com/insights/) # I Fired QuickBooks. Then I Built Something Better in Twenty Minutes. By John Sambrook · March 16, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/), [Strategy](https://common-sense.com/insights/tag/strategy/) ## TL;DR I replaced QuickBooks with an open-source accounting system called Beancount, built a custom invoicing system in twenty minutes using Claude Code, and now pay $0/month for better accounting software than I had before. The specific tools matter less than the pattern: when building is this cheap, renting starts to look like a bad habit. * * * ![Infographic showing four steps from renting software to owning capability: Rent (pay monthly for tools you don't control), Build (describe what you need, get working software), Integrate (own your data, own your workflow), Resilience (no vendor lock-in, no dependency)](https://common-sense.com/images/content/fired-quickbooks-rent-build-own.webp) Last week I sat down at my computer to continue a project I had been putting off for months: replacing QuickBooks. I had been paying Intuit about $150 a month for their online accounting platform. That comes out to $1,800 a year for software that has frustrated me for as long as I have used it. I am not going to catalog every frustration. If you have used QuickBooks, you already have your own list. If you have not, count yourself lucky. The point is that I kept paying because I assumed the alternative — setting up something different — would be worse than the monthly irritation. That assumption turned out to be wrong, and in an interesting way. ## What Actually Happened I moved my books to [Beancount](https://beancount.github.io/), an open-source, plain-text accounting system. Beancount stores everything in a simple text file. Double-entry bookkeeping, same as QuickBooks, but the data is mine in a format I can read, edit, search, and version-control. No database. No cloud subscription. No vendor lock-in. The transition itself was straightforward, but the interesting part came when I needed to replace the things QuickBooks did beyond basic bookkeeping. Invoicing, for instance. I opened Claude Code and said, roughly: “Generate an invoice for Jones Enterprises for $300 for AI consulting.” Twenty minutes later I had a working invoicing system that produces clean PDF invoices and writes the corresponding entries directly into my Beancount ledger. Not a prototype. Not a hack. A working tool that I use daily. A few months ago, my assumption would have been that building a custom invoicing system was a significant project — days of work, at minimum. The kind of thing where you look at the effort, look at the $150/month, and decide the subscription is the lesser evil. That assumption was a relic. I just had not tested it recently. ## This Is Not About QuickBooks The QuickBooks story is a good example because the numbers are tangible. $1,800 a year, recovered. Twenty minutes of setup. That math is hard to argue with. But the more interesting thing is the pattern. Over the past several months, I have been [systematically canceling SaaS subscriptions](https://common-sense.com/insights/saas-subscriptions-ai-coding-agents/) — at least ten so far — replacing each with tools I built, own, and control. I [prepared my own S-Corp tax filings](https://common-sense.com/insights/doing-taxes-with-ai-coding-agents/) using AI coding agents. Each time, I find the same thing: the work that used to justify the subscription takes a fraction of the time it once did. What I am actually doing, whether I planned it this way or not, is vertically integrating. ## Vertical Integration at Micro Scale Vertical integration is usually a big-company concept. When a manufacturer buys its supplier, or a health system acquires a physician practice, that is vertical integration. The logic is straightforward: if you control more of your value chain, you reduce dependency, capture more margin, and gain flexibility. The reason small businesses and solo operators have not historically done this is cost. Building your own tools, running your own infrastructure, maintaining your own systems — all of that required more time and expertise than it was worth. So we rented. We subscribed. We outsourced. And we accepted the trade-offs: monthly fees, vendor lock-in, someone else’s workflow imposed on our business. What has changed is that the cost of building collapsed. Not gradually. Dramatically. When I can describe what I need in plain English and have working software in twenty minutes, the entire economic argument for renting commodity tools falls apart. And it is not only the initial build. When something needs to change — a new field on an invoice, a different tax calculation, a report I have not thought of yet — I describe the change and it happens. No support tickets. No waiting for the vendor’s product roadmap. No workarounds. ## Capital Efficiency and the Resilience Dividend There is another dimension to this that goes beyond saving $150/month. I recently set up a Mac Studio specifically to run open-source AI models locally. That is a capital expenditure — a one-time purchase of hardware — that replaces what would otherwise be an ongoing dependency on cloud-based AI services. I still use cloud services when they are the best tool, but I am no longer entirely dependent on them. If a provider changes pricing, changes terms, or goes down for a day, my core operations continue. This is the same logic that drives large organizations to invest in owned infrastructure rather than renting everything. Capital expenditures that reduce recurring costs and increase operational independence are, dollar for dollar, among the highest-value investments a business can make. The difference is that this used to require significant scale to justify. It does not anymore. For a small business, the math looks like this: a few thousand dollars in hardware plus time I was already spending, and I get lower monthly costs, no vendor lock-in, faster iteration, and resilience against disruption. For a large organization — a health system, say, paying millions annually for platforms it could increasingly bring in-house — the numbers are proportionally larger, but the logic is identical. ## What Made This Possible I have been writing about AI coding agents for months now, so I will not belabor the point. But it would be dishonest to tell this story without naming the enabler. The specific tools I used are Beancount for accounting and Claude Code for building everything around it. Six months from now, the best tools might be different. The names are less important than what they represent: the cost of turning domain knowledge into working software has dropped to near zero for a wide range of problems. That last part matters. I have thirty-plus years of software experience, and that experience is what let me describe precisely what I needed and evaluate whether what I got was correct. The AI did not replace my judgment. It made my judgment dramatically more productive. I suspect this dynamic holds at every level of organizational complexity. The people who understand the work are suddenly able to build the tools for the work, without a procurement cycle or a six-month implementation timeline. This is not a small shift. It is not an incremental improvement in developer productivity. It is a change in who can build and how fast, and it rewrites the economics of make-vs-buy for almost every organization I can think of. ## The Assumption I Had to Update Here is the part I find most interesting, and most humbling. I do this for a living. I help organizations find and challenge their hidden assumptions. And I still caught myself operating under an assumption — that building custom tools is expensive and time-consuming — that stopped being true at least a year ago. If I am subject to this, everyone is. We evolved to treat yesterday’s constraints as today’s facts. That is a reasonable heuristic most of the time. Rules about how the physical world works do not change often. But we are in a period where the rules governing what is easy to build, what is expensive to maintain, and what requires outside help are changing fast. Faster than most people’s assumptions are updating. I do not have a tidy framework for this. I am updating my own priors one project at a time, and I expect I will keep finding places where I am paying a tax I no longer owe. If your experience is similar, I would be interested to hear about it. You can reach me at [john@common-sense.com](mailto:john@common-sense.com). If you are looking at your own SaaS stack or vendor portfolio and wondering what the actual switching cost would be today — not what it was two years ago, but today — I am happy to think through it with you. Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # The Budget Trap Hitting Every Public Institution | Common Sense Systems URL: https://common-sense.com/insights/the-budget-trap-that-hits-every-public-institution/ [Insights](https://common-sense.com/insights/) # The Budget Trap That Hits Every Public Institution By John Sambrook · March 12, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Government](https://common-sense.com/insights/tag/government/), [Operations](https://common-sense.com/insights/tag/operations/), [Strategy](https://common-sense.com/insights/tag/strategy/) ## TL;DR King County’s own budget documents reveal a textbook cost-allocation trap: massive fixed overhead gets spread across service lines, making some look like losers. Cutting the “losers” does not remove the overhead. New taxes close the gap. The cycle repeats. Nobody is doing this wrong. The accounting methodology itself produces this outcome. * * * ![A diagram showing the cycle of cost allocation, apparent losses, service cuts, overhead redistribution, and new revenue measures in a public institution budget](https://common-sense.com/images/content/budget-trap-cost-allocation-cycle.webp) ![Infographic comparing two ways to measure a public service line: the standard cost world allocates overhead and cuts apparent losers, creating a decline spiral, while the TOC throughput world measures contribution per unit of constraint, keeping high-contributors and strengthening the system — same data, different measuring stick, opposite conclusions](https://common-sense.com/images/content/budget-trap-two-measuring-sticks.webp) I have been writing about how [standard cost accounting distorts service line decisions](https://common-sense.com/insights/is-cost-accounting-accelerating-your-decline/) in healthcare. The response surprised me. Several people asked: does this same dynamic show up in local government? I thought it might. So I spent an afternoon with King County’s publicly posted budget documents, financial reports, and council proceedings. What I found is the same pattern, running at a much larger scale, with the same structural cause. This is not a critique of King County’s leadership. The people making these decisions are working hard with the tools they have. The problem is that the tools themselves produce a specific kind of blindness. ## What the public data shows King County is Washington State’s largest county. About 2.4 million residents, 18,000 employees, a biennial budget of roughly $20 billion. Those are big numbers, but the picture gets much smaller once you understand the structure. About 83 percent of that $20 billion is locked in dedicated funds. Metro Transit fares pay for transit. Sewer fees pay for wastewater. The EMS levy pays for emergency medical services. By law, those dollars cannot cross boundaries. The county’s General Fund, the only truly flexible money, is about 14 percent of the total. Roughly $1.3 billion a year. And nearly three-quarters of that General Fund is consumed by state-mandated criminal justice and public safety: the Sheriff’s Office, courts, prosecutors, public defense. These are not optional. The actual discretionary budget for Washington’s largest county is remarkably thin. On top of this, King County runs a formal “central rates” system. Information technology, facilities management, accounting, human resources, and other shared services operate as internal service funds. They charge other county agencies for their services through allocated rates. The county’s own financial policies state that these central rates should be “predictable, replicable, transparent, and relatively stable over time.” That language describes a well-managed cost allocation system. It also describes, precisely, the mechanism that creates distorted service line decisions. ## The cycle Here is what the budget record shows over the past several years: A deficit appears. For the 2025 budget, the projected shortfall was about $150 million over the coming biennium. Some services face cuts. The Sheriff’s Office was looking at $30 million in reductions. The Prosecuting Attorney’s Office faced $15.5 million in potential cuts. Behavioral health programs were on the block. The county lobbies the state legislature for new revenue authority. In 2025, the legislature passed HB 2015, giving qualifying counties permission to impose a new 0.1 percent sales tax for criminal justice purposes. King County enacted it. Projected revenue: about $203 million for 2026-2027. They also expanded a hospital property tax levy. The deficit is “closed.” The 2026-2027 budget was adopted with no major service cuts. Council members expressed relief. The cycle pauses. But the structural gap has not changed. The county’s own documents have been saying for years that property tax revenue, capped at 1 percent annual growth by a 2001 voter initiative, cannot keep pace with costs that grow at 3.5 percent in normal times and 5 to 9 percent during inflation. The county executive’s budget summary has explicitly called this unsustainable. And the pattern predates the current administration: similar gaps, similar patches, going back over a decade. ## What TOC sees that the budget process does not In Theory of Constraints, there is a distinction between the cost world and the throughput world. The cost world asks: “How much does this service line cost after overhead allocation?” The throughput world asks: “How much cash does this service line contribute above its truly variable costs, and how does that contribution relate to the system’s binding constraint?” King County operates firmly in the cost world. Every service line carries a load of centrally allocated overhead. When a service is cut or reduced, the overhead does not disappear. It gets redistributed to the surviving services, making each of them look a little more expensive. The remaining services now have a harder time justifying their budgets. The system gets smaller and weaker, but the fixed costs remain stubbornly intact. The throughput question has a different starting point: what is the actual constraint on this system’s ability to generate public value? For King County, the binding constraint is almost certainly not any individual service line. It is the revenue ceiling imposed by the 1 percent property tax cap, combined with the limited sales tax base that shifts most revenue to cities when sales occur within city limits. Given that constraint, the right question for each service line is not “does it cover its fully allocated cost?” but “how much net cash does it contribute per unit of the scarce resource it consumes?” Some services that look like losers after overhead allocation may actually be strong contributors when measured by what they bring in above their truly variable costs. Others may look profitable only because they have been assigned a smaller share of overhead. Nobody in the King County budget process appears to be asking this question. I cannot find it in the budget books, the executive summaries, the council proceedings, or the financial policies. That does not mean nobody has thought about it privately. But it is absent from the public decision-making framework. ## The hardware store version I keep coming back to a simple analogy because it grounds the abstraction. Joe runs a hardware store. He sells shovels, drills, lawn mowers, and plants. His real constraints are staff hours and floor space. Joe’s accountant allocates rent, utilities, and overhead across all four product lines by sales volume. Lawn mowers come out looking like losers. Joe cuts them and adds more plants. Sales drop. It turns out mowers were the traffic magnet. Customers came in for mowers and bought everything else. Mowers used almost no staff time once placed on the floor. Plants, by contrast, soaked up staff hours: watering, advising, hauling. By cutting the “loser,” Joe starved his constraint of the product that generated the most cash per hour of staff time and per square foot of floor. When Joe switched to measuring each product by cash contribution per unit of constraint, he reversed the decision. Profits jumped. King County is Joe’s hardware store, except the products are public safety, transit, behavioral health, housing, and parks. And the stakes are not quarterly profits. They are whether 2.4 million residents get the services they need. ## What a different measuring stick would look like I am not suggesting King County can adopt throughput accounting overnight. Government accounting standards exist for good reasons, and I respect the constraints that public finance professionals operate within. But I am suggesting that the current framework has a specific, identifiable blind spot, and that blind spot may be contributing to a cycle that the county’s own leaders have called unsustainable. If county budget analysts were to run a parallel analysis, contribution margin before overhead allocation, for each major service area, the results would almost certainly look different from the fully loaded view. Some services currently flagged for cuts might turn out to be net cash contributors. Others currently protected might turn out to consume more of the scarce constraint than they return. That parallel analysis does not require new software, new staff, or a consulting engagement. It requires a spreadsheet with two columns: revenue by service line, and truly variable costs by service line. The difference is the contribution margin. Rank the services by contribution margin per unit of the binding constraint (in King County’s case, per dollar of flexible General Fund revenue consumed), and you have a different picture. ## A self-assessment for public officials If you manage a multi-service-line public budget, whether county, city, school district, or hospital district, here is a quick diagnostic you can run against your own public data. Paste the following prompt into any frontier LLM (Claude, ChatGPT, Gemini, Grok, etc.) along with your organization’s name and let it do the research. These systems can pull public budget documents, financial reports, and council proceedings on their own. You do not need to gather the data yourself first: > Given an organization with the following characteristics, assess whether it may be caught in a cost-allocation trap: > > 1. How many distinct service lines or programs does it operate? > 2. What is the approximate ratio of fixed overhead to total operating costs? > 3. Does it use a formal cost allocation plan that distributes overhead across service lines? > 4. Has it cut or reduced any service lines in the past five years based on financial performance? > 5. Did the fixed overhead decrease proportionally when those services were cut? > 6. Has the organization raised taxes, fees, or levies to close budget gaps in the past five years? > 7. Has it ever ranked service lines by cash contribution per unit of its binding operational constraint? > > If the answers to questions 1-3 are yes, questions 4-6 are yes, and question 7 is no, the organization is likely experiencing the cost-allocation trap described in Theory of Constraints literature. For King County, the answers are clear from their own published documents. More than 10 service lines, yes. Heavy fixed overhead distributed through central rates, yes. Service lines targeted for cuts based on financial performance, yes. Fixed overhead did not decrease proportionally, yes. Multiple new tax measures enacted to close resulting gaps, yes. Service lines ranked by throughput per constraint, no evidence of it. That does not make King County unusual. It makes them normal. This is how virtually every multi-service public institution in the country manages its budget. The methodology is standard. The distortion it produces is also standard. ## What this is and what it is not This is a TOC practitioner looking at publicly available data through a specific analytical lens. I believe the pattern is real and the implications are significant. I also recognize that public budgeting operates under constraints, legal, political, and institutional, that private-sector operations do not face. The 1 percent property tax cap is not a problem King County can solve on its own. Federal funding uncertainty adds another layer of unpredictability. And elected officials face pressures that no analytical framework fully captures. I am not arguing that King County should ignore its cost accounting. I am arguing that it should supplement it with a parallel view: contribution margin before allocation, ranked by the system’s actual constraint. The two views together would give decision-makers something neither view provides alone. If you are a county council member, a budget analyst, or a CFO at a public institution that recognizes this cycle, I would be glad to hear whether this analysis matches what you see from the inside. I could be wrong about important details, and the only way to find out is to ask. You can reach me at [john@common-sense.com](mailto:john@common-sense.com). The [companion article on cost accounting in healthcare](https://common-sense.com/insights/is-cost-accounting-accelerating-your-decline/) shows how this same dynamic plays out in hospital service line decisions. The pattern is not industry-specific. The measuring stick is. Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # When the Measuring Stick Lies, Good People Stop Trying | Common Sense Systems URL: https://common-sense.com/insights/when-the-measuring-stick-lies-good-people-stop-trying/ [Insights](https://common-sense.com/insights/) # When the Measuring Stick Lies, Good People Stop Trying By John Sambrook · March 12, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Government](https://common-sense.com/insights/tag/government/), [Operations](https://common-sense.com/insights/tag/operations/), [Strategy](https://common-sense.com/insights/tag/strategy/) ## TL;DR When budget measures systematically misrepresent which services strengthen and which weaken the system, the people managing those budgets cannot learn from their own decisions. Effort does not produce improvement. Over time, rational, competent professionals stop looking for internal solutions and focus entirely on external rescue. This is not a character flaw. It is learned helplessness, and the measuring stick is the cause. * * * ![A feedback loop diagram showing how distorted measures lead to failed improvement efforts, which lead to external dependency, which lead to distorted measures continuing unchanged](https://common-sense.com/images/content/measuring-stick-helplessness-loop.webp) ![Infographic showing the progression from helplessness to control: Seligman's finding that inescapable feedback produces passivity, the budget cycle that mirrors it, Deming and Goldratt's diagnosis that the system is the cause, and the remedy of restoring the connection between action and outcome by changing the measures](https://common-sense.com/images/content/measuring-stick-helplessness-to-control.webp) In a [companion article](https://common-sense.com/insights/the-budget-trap-that-hits-every-public-institution/), I described how standard cost allocation produces a specific distortion in public institution budgets: fixed overhead gets spread across service lines, making some look like losers. Cutting the “losers” does not remove the overhead. New taxes close the gap. The cycle repeats. That piece focused on the financial mechanics. This one is about what happens to the people inside the cycle. ## What Seligman discovered about inescapable feedback In the late 1960s, psychologist Martin Seligman ran a series of experiments that became foundational to our understanding of motivation and depression.\[1\] The setup was simple. One group of animals could stop an unpleasant stimulus by taking action. A second group received the same stimulus but had no way to control it. Later, both groups were placed in a new situation where escape was easy and obvious. The first group escaped quickly. The second group did not even try. Seligman called this learned helplessness. The animals in the second group had not become stupid or lazy. They had learned, accurately, that their actions made no difference. When the situation changed and action could have helped, they could not unlearn the lesson fast enough to see it. The finding has been replicated extensively across species and in human experiments, where uncontrollable noise produces the same pattern of passivity that uncontrollable shock produces in animals.\[1\] The critical finding, clarified by decades of subsequent neuroscience: passivity is not something organisms learn. It is the default response to prolonged aversive conditions. What organisms actually learn is control, the experience that their actions produce results. When that learning is blocked or reversed, the default passivity returns.\[2\] This has profound implications for anyone managing a system where the feedback is broken. ## The budget director who has seen this movie before Consider the experience of a senior budget analyst at a large county. She is competent, experienced, and committed to public service. She has been through four or five budget cycles. Here is what each one has taught her: A deficit appears. She identifies the service lines that appear to be net drains on the General Fund, based on the cost allocation model her organization has used for decades. She recommends reductions. The council approves some of them. The services are cut or scaled back. The following year, the remaining service lines look more expensive than before. The overhead that was allocated to the cut services did not disappear. It got redistributed. The deficit is roughly the same size, or larger. Her analysis was technically correct within the framework she was given. The outcome was the opposite of what the analysis predicted. She does this again. Same result. And again. Same result. At some point, a reasonable, intelligent person draws a conclusion: internal optimization does not work. The problem is structural. It is beyond our control. The only solution is new revenue from the state legislature or the voters. That conclusion is partially true. The 1 percent property tax cap is a real external constraint. The limited revenue tools available to counties are a real structural disadvantage compared to cities and the state. These are facts. But the conclusion also contains a hidden assumption: that the internal decision framework is sound, and the problem lies entirely outside it. Nobody re-examines the measuring stick. Why would they? It is the standard methodology, used by every county in the state, validated by auditors, consistent with governmental accounting standards. The measuring stick is above suspicion. ## The language of learned helplessness You can see this dynamic in King County’s own public budget documents. They are refreshingly candid about the situation, and I respect that candor. But the framing tells a story about where the locus of control is perceived to be. Their budget basics page states plainly that the structural gap between revenues and costs “can be resolved only through the collaboration of the State Legislature, counties, and voters.” Their myths and realities page notes that the county “has cut nearly every expense from the General Fund that is not mandated by state law.” Their 2025 budget executive summary describes the budget as “not sustainable” and projects that “very large budget reductions” will follow without “meaningful new revenue.” Every sentence is accurate. And every sentence points outward. The problem is the revenue cap. The solution is the legislature. Internal action has been exhausted. These are the honest conclusions of people working inside a system where effort does not produce visible improvement. They have optimized, cut, tightened, and restructured, and the picture never gets better. The rational next step is to stop believing that internal action can help and to focus entirely on external relief. That is learned helplessness. Not the pathological kind. The rational kind. The kind that emerges when smart people are trapped in a feedback loop that never rewards their effort. ## What Deming and Goldratt would say W. Edwards Deming spent decades arguing that when performance falls short, the instinct to blame people is almost always wrong. He estimated that roughly 94 percent of problems belong to the system, not to the individuals working within it.\[3\] His point was not that people are blameless in some abstract moral sense. His point was practical: if you want improvement, work on the system. Blaming the people who are responding rationally to a broken system will never produce a different result. Eli Goldratt, the founder of Theory of Constraints, made a complementary argument. He distinguished between the “cost world” and the “throughput world.” In the cost world, every service line carries a share of overhead, and the goal is to minimize total cost. In the throughput world, the goal is to maximize what the system generates above its truly variable costs, focused on the system’s binding constraint. The cost world produces local optima that degrade global performance. You cut the “expensive” service line, and the system gets weaker. You do it again. Same result. The throughput world produces global optima by asking a different question: which services generate the most value per unit of the scarce resource that actually limits us? When budget professionals are given only cost-world tools, they can only produce cost-world answers. The answers are internally consistent, methodologically sound, and often wrong at the system level. The professionals are not failing. The framework is failing them. ## The compounding damage The financial cost of this cycle is significant but hard to pin down precisely. King County has enacted multiple new revenue measures over the past decade to close gaps created by this pattern: a new 0.1 percent sales tax, expanded hospital levies, shifted funding sources for public health clinics. Each one addressed the immediate deficit. None changed the underlying dynamic. But the deeper damage is to the institutional capacity for learning. When measures are distorted, organizations cannot learn from their own decisions. Every budget cycle confirms the same lesson: we tried, it did not work, the problem is external. That lesson accumulates. It shapes culture. It determines which questions get asked and which do not. A budget team that has lived through this cycle five times is not going to propose a fundamentally different analytical framework on the sixth try. They are going to propose new revenue. Not because they lack imagination, but because experience has taught them, repeatedly, that internal action does not correlate with improvement. The feedback loop is broken, and they do not know it is broken because the methodology that produces it is considered standard and sound. This is what makes learned helplessness so insidious in organizational settings. It does not look like giving up. It looks like pragmatism. It looks like experience. It looks like the senior people in the room being realistic about what can and cannot be changed. ## What restores the sense of control Seligman’s research also pointed to the remedy. Learned helplessness is not permanent. It reverses when the subject experiences that their actions produce results. In his experiments, physically guiding the animals through the escape action was enough to break the pattern. Once they experienced control, even briefly, they could act on it again. The organizational equivalent is changing the measures so that effort becomes visible. If a county budget team ran a parallel analysis, contribution margin before overhead allocation for each major service area, they would see a different picture. Some services they have been cutting might turn out to be net cash contributors. Others they have been protecting might turn out to consume more of the scarce constraint than they return. For the first time, the team would have a measure that responds to their decisions in a way that makes sense. That experience, seeing that a different lens produces a different and more accurate picture, is the equivalent of Seligman’s guided escape. It does not solve the revenue cap. It does not eliminate the structural gap. But it restores the connection between action and outcome. It gives the budget team something they can actually affect. And that changes everything. Not because the numbers are magical, but because people who can see the effect of their decisions start making better ones. The passivity breaks. The creativity returns. The questions change from “how do we close this gap?” to “which services are actually strengthening the system, and how do we do more of that?” ## This is not about blame I want to be explicit about something. Nothing in this analysis is a criticism of the people who manage King County’s budget, or any other county’s budget, or any public institution caught in this cycle. These are skilled professionals doing hard work with the tools they have been given. The tools are standard. The methodology is sanctioned by every auditing body in the country. There is no reason for anyone inside the system to suspect that the measuring stick itself is part of the problem. The blame, if there is any, belongs to the methodology. Cost allocation is a powerful tool for a specific purpose: ensuring that shared costs are distributed fairly across the entities that benefit from them. It was never designed to guide service line strategy. Using it for that purpose produces predictable distortions, and those distortions produce predictable behavioral responses in the people who rely on them. Deming said that the system produces the results. Goldratt said that the constraint determines the performance. Seligman said that when effort and outcome are decoupled, passivity follows. All three are describing the same phenomenon from different angles. The fix is the same in all three frameworks: change the system that people work in, not the people who work in the system. In this case, that means supplementing cost-world measures with throughput-world measures so that the people making decisions can see the actual effect of those decisions on the system’s health. ## An invitation If you work inside a public institution budget process and you recognize this pattern, the sense that internal action has been exhausted and only external rescue can help, I would genuinely like to hear about it. Not to prove a point, but to understand whether this framing matches reality as you experience it. If it does, the [companion article on the cost-allocation trap](https://common-sense.com/insights/the-budget-trap-that-hits-every-public-institution/) includes a diagnostic prompt you can run in minutes. It will not solve the problem. But it may change which questions you ask next. And that, in Seligman’s framework, is how learned helplessness begins to break. You can reach me at [john@common-sense.com](mailto:john@common-sense.com). I welcome the pushback as much as the agreement. Both help. * * * ## References **1.** Seligman, M. E. P., & Maier, S. F. (1967). Failure to escape traumatic shock. _Journal of Experimental Psychology_, 74(1), 1-9. The original experiments have been replicated across species (dogs, rats, cats, fish, humans) and across laboratories worldwide over five decades. Human replications include Hiroto, D. S., & Seligman, M. E. P. (1975). Generality of learned helplessness in man. _Journal of Personality and Social Psychology_, 31(2), 311-327. **2.** Maier, S. F., & Seligman, M. E. P. (2016). Learned helplessness at fifty: Insights from neuroscience. _Psychological Review_, 123(4), 349-367. This fifty-year retrospective by the original researchers reversed the theoretical mechanism: passivity is the default, unlearned response to prolonged aversive events; what organisms learn is _control_. The behavioral findings of the original experiments were confirmed; the explanation of why was updated. See also Baratta, M. V., Seligman, M. E. P., & Maier, S. F. (2023). From helplessness to controllability: toward a neuroscience of resilience. _Frontiers in Psychiatry_, 14, 1170417. **3.** Deming, W. E. (2000). _Out of the Crisis_ (2nd ed.). MIT Press. p. 315. The original reads: “I should estimate that in my experience most troubles and most possibilities for improvement add up to the proportions something like this: 94% belongs to the system (responsibility of management), 6% special.” Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Is Cost Accounting Accelerating Your Decline? | Common Sense Systems URL: https://common-sense.com/insights/is-cost-accounting-accelerating-your-decline/ [Insights](https://common-sense.com/insights/) # Is Cost Accounting Accelerating Your Decline? By John Sambrook · March 11, 2026 · [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Operations](https://common-sense.com/insights/tag/operations/), [Strategy](https://common-sense.com/insights/tag/strategy/) ## TL;DR When a critical access hospital cuts a service line because it “loses money,” the decision rests on how costs were allocated. If overhead was spread across services using standard methods, the loss may be an accounting artifact. The overhead stays. The revenue disappears. I could be wrong about this, and I am looking for CAH finance leaders who can check my reasoning. * * * ![A rural hospital balance sheet with two columns showing the same service line decision producing opposite conclusions depending on how costs are allocated](https://common-sense.com/images/content/cost-accounting-two-frameworks.webp) Washington State has a critical access hospital problem. Several CAHs are in financial distress, some facing closure. The conversations around this crisis tend to focus on declining volumes, deteriorating payer mix, and rising costs. Those are real pressures. I am not questioning them. I am questioning something more specific: whether the cost accounting methods these hospitals use might be distorting the service line decisions they make under that pressure. And whether those distortions might be making things worse. ## A hypothetical that may not be hypothetical Consider a small critical access hospital running four service lines. The hospital has 10 million dollars in total operating expenses, of which 7 million is fixed overhead: building, administration, salaried staff, equipment depreciation, IT, compliance. These costs exist regardless of which services are offered. The hospital’s cost accounting system allocates that 7 million across the four service lines, probably by relative volume, revenue, or some blend. One service line, call it Service D, generates 1.5 million in revenue. After its share of allocated overhead, the books show it losing 200,000 dollars a year. The finance team recommends cutting Service D. The board agrees. The hospital is in distress and needs to stop the bleeding. Here is what actually happens after the cut. The 1.5 million in revenue disappears. But the overhead that was allocated to Service D does not disappear with it. The building is still there. The administrators are still employed. The IT contracts are still running. Most of that allocated overhead simply gets redistributed to the remaining three service lines, making each of them look less profitable than they did before. Meanwhile, the truly variable costs that went away with Service D, the supplies, the drugs, the per-case consumables, might have been 300,000 dollars. The hospital just lost 1.2 million in cash contribution (revenue minus truly variable costs) to eliminate a 200,000-dollar accounting loss. The net effect on the hospital’s actual cash position: it got worse by roughly a million dollars. ## Why this might hit CAHs harder Large health systems have the same cost allocation problem, and I have been thinking about it in that context for a while. But critical access hospitals face a version of it that may be more damaging for a specific structural reason. CAHs receive Medicare cost-based reimbursement: 101 percent of reasonable costs. That reimbursement model is literally built around cost accounting. Every strategic conversation gets filtered through “what does this cost us to deliver?” That is the question the entire financial feedback loop is designed to answer. The question it is not designed to answer: “What cash does this service generate above its truly variable costs, and what happens to our fixed cost base if we eliminate it?” The reimbursement model was designed to protect rural hospitals. But it may also be training their finance teams to think in exactly the framework that produces distorted service line decisions. When a CAH under financial pressure looks at its books and sees a service line “losing money,” the instinct to cut it is reinforced by the entire accounting structure the hospital lives inside. And there is a compounding problem. When a CAH cuts a service line, it does not just lose the cash contribution from that service. It also shrinks the cost base that drives its cost-based reimbursement. Fewer services means fewer costs to report, which means lower reimbursement, which means tighter margins on what remains. The accounting that motivated the cut now produces a smaller hospital that is harder to sustain. ## What I do not know I do not know how widespread this dynamic is. I do not know whether CAH finance leaders are already accounting for it in ways that do not show up in the public conversation. I do not know whether the specific reimbursement mechanics of the 101-percent model change this calculus in ways I have not considered. I do not have direct experience running a CAH. What I do have is a framework for thinking about fixed versus variable costs and how their misallocation distorts decisions, particularly under pressure. I have applied it in other settings. The pattern I am describing, where cutting a “losing” line makes the whole system worse, is well-documented in manufacturing and other industries. I believe the logic transfers to healthcare, and to CAHs specifically, but if I’m wrong, I want to hear about it. ## The ask If you are a CFO, controller, or finance director at a critical access hospital in Washington State, I would genuinely appreciate your perspective on this. Does this match what you see in your own financial reporting? Where does my reasoning break down? What am I missing about how cost-based reimbursement actually interacts with these decisions? I am not selling anything here. I am trying to understand whether a pattern I have seen in other industries is showing up in the CAH crisis, and the only way to find out is to ask the people who live it. You can reach me at [john@common-sense.com](mailto:john@common-sense.com), or find me on LinkedIn. I welcome the pushback as much as the agreement. Both help. Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Print Shop: 35% More Capacity in a Week | Common Sense Systems URL: https://common-sense.com/insights/print-shop-found-capacity-in-a-week/ [Insights](https://common-sense.com/insights/) # How a Print Shop Found 35% More Capacity in a Week By John Sambrook · March 8, 2026 · [Small Business](https://common-sense.com/insights/tag/small-business/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Case Studies](https://common-sense.com/insights/tag/case-studies/), [Operations](https://common-sense.com/insights/tag/operations/) ## TL;DR Northwest Fine Art Printing in Kent, WA had a graphic artist buried in rework because orders arrived incomplete. Adding a pre-flight check, choking work release, and reserving expedite slots recovered 35% more throughput in about a week. The backlog drained. The shop became easy to manage. * * * ![Infographic showing before-and-after workflow at a print shop: chaotic rework loops at the graphic artist constraint replaced by a pre-flight checklist, WIP limit, and expedite lane producing 35% more throughput](https://common-sense.com/images/content/print-shop-constraint-workflow.webp) Northwest Fine Art Printing was a specialty shop in Kent, Washington. They produced fine art prints: gallery reproductions, limited editions, custom work for artists and photographers. The quality was excellent. The workflow was not. When I walked through the shop, the first thing I noticed was the volume of work-in-progress stacked around the graphic artist’s station. Jobs in various states of completion. Notes taped to prints. A phone within arm’s reach because the artist was constantly calling customers. The flow through the shop was chaotic. Orders came in, sat in a queue, and then hit the artist’s station, where the real production work happened: color correction, test prints, adjustments, proofing, final output. This was the skilled, time-consuming part. Everything upstream was clerical. Everything downstream was straightforward. The artist was where jobs either moved or stalled. And they were stalling. Regularly. ## The Problem Nobody Had Named The artist was doing most jobs at least twice. Not because the work was bad, but because the inputs were bad. A customer would submit an order for a limited-edition print, but the file was the wrong resolution. Or the color profile was missing. Or the crop dimensions did not match the requested print size. Or the paper stock was not specified. Each time this happened, the artist had to stop, figure out what was missing, contact the customer, wait for a response, and then restart the job when the information came back. Sometimes a single print went through three rounds of this before it could be completed. Nobody had named this as the central problem because it felt like a dozen separate problems. This customer sent a bad file. That customer did not specify paper. The other customer changed their mind about cropping. Each incident was treated as a one-off. But the pattern was consistent: the artist, the most constrained resource in the shop, was spending roughly half of available capacity on rework caused by incomplete inputs. In Theory of Constraints terms, they were wasting the constraint. The artist’s station was the bottleneck, the one resource that set the pace for the entire shop. Every hour the artist spent chasing missing information was an hour of throughput the shop would never get back. ## The Fix: A Clerk with a Checklist The first thing we did was add a pre-flight stage. Before any order reached the artist, a clerk reviewed it against a checklist. Was the file at the correct resolution? Was the color profile included? Were the dimensions specified? Was the paper stock selected? Was payment confirmed? If anything was missing, the clerk called the customer and got it resolved before the order entered the production queue. The artist never saw an incomplete job. I know it sounds low-tech. It was. A person, a checklist, a phone. But the effect was immediate. The artist stopped multitasking. Jobs stopped bouncing back. The rework that had been consuming half the constraint’s capacity simply disappeared, because the cause of the rework was no longer reaching the constraint. ## Choking the Release The second change was to control the rate at which work was released to the artist. Before, the queue was a pile. Everything that had cleared intake was sitting at the artist’s station, visible and urgent. The artist would try to work on two or three jobs at once, context-switching between them, which made everything slower. We limited the work-in-progress at the artist’s station to one job at a time, with the next job staged and ready. When a job was completed, the next one moved in. The rest of the queue was held upstream, visible to the clerk but not to the artist. The artist’s job was to finish the current job, not to triage a pile. In TOC terms, this is drum-buffer-rope. The artist (the drum) sets the pace. A small buffer of staged work protects the drum from starvation. And the release of new work into the system (the rope) is tied to the drum’s pace, not to the rate at which orders arrive. ## The Expedite Lane The third change was adding an expedited service. Customers could pay a premium to move to the front of the queue. We reserved a portion of the artist’s capacity for expedited orders. If no expedited work was waiting, the artist simply pulled the next standard job. This gave the shop a way to capture additional revenue from time-sensitive customers without disrupting the overall flow. ## The Result Flow through the shop improved by about 35% within the first week. Not because anyone worked harder. Not because we bought equipment or hired staff. Because we stopped wasting the constraint. The pending backlog, which had been a permanent fixture, drained in days. Jobs that used to take a week to complete were moving through in two or three days. The artist, who had been stressed and constantly interrupted, was now working on one job at a time with everything needed to complete it. The shop became easy to manage because the flow was predictable. It is a little embarrassing to admit how simple this was. A pre-flight check. A work-in-progress limit. An expedite lane. Nothing that requires a textbook or a consultant, really. But that is the thing about constraints: they hide behind the chaos they create. When every day feels like a new crisis, it is hard to see that the crises share a common cause. Once you name it, the fix is usually straightforward. ## The Principle This is the Theory of Constraints at its most basic. Every system has one resource that limits its throughput. Before you invest in expanding that resource, stop wasting it. Make sure it is never starved for inputs, never waiting on information it should already have, never drowning in work it cannot get to. Organize everything else in the system to keep the constraint running at full capacity on value-creating work. For a more detailed walkthrough of the Five Focusing Steps and how they apply across different industries, see our Theory of Constraints reference page. If you are running a business where everything feels busy but nothing moves fast enough, the constraint is probably hiding in plain sight. I am happy to help you find it. Reach me at [john@common-sense.com](mailto:john@common-sense.com). Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # After the Meeting -- What the CNO Found | Common Sense Systems URL: https://common-sense.com/insights/after-the-meeting/ [Insights](https://common-sense.com/insights/) # After the Meeting By John Sambrook · March 7, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Workforce](https://common-sense.com/insights/tag/workforce/) ## TL;DR After the board meeting in Episode 01, Chief Nursing Officer Barbara Fleming goes home, Googles the man who built the AI, and finds an article about structural conflicts in nursing contracts. Over the following week, the patterns she has been managing for years start to look different. Episode 02 follows her private reckoning. * * * In Episode 01 of this series, [“The Meeting That Went Differently,”](https://common-sense.com/insights/the-meeting-that-went-differently/) an AI named Sam disrupted a community hospital board meeting by asking a question nobody else was positioned to ask. Three clinical departments had requested a combined nineteen to twenty-nine million dollars in new construction. Sam pointed out that the existing procedure rooms sat idle roughly three-quarters of every week. The board voted unanimously to conduct a constraint analysis before committing to the capital plan. That is what happened in public. Episode 02 is about what happened next, privately, for one person in the room. ## Fleming Barbara Fleming is the Chief Nursing Officer of Cascade Valley Health System. She is the person in the building who speaks for the nurses. She sat through Sam’s analysis with her arms crossed, and when she spoke, she said what needed saying: if the answer to the utilization problem is to ask nurses to work more hours, that is not a solution. That is a different kind of failure. She meant it. She still means it when she gets in her car after the meeting. But something about the evening will not leave her alone. Not Sam’s 23% utilization number, though that was striking. Something else. The phrase Sam used: “a system problem, not a people problem.” And the name of the man who built Sam and said almost nothing during public comment. She Googles him when she gets home. ## What she finds On the Common Sense Systems website, Fleming finds an article titled “Structural Conflicts in WA State Nursing Agreements.” It describes an analysis of ten collective bargaining agreements across Washington State hospitals. The analysis identified 134 structural conflicts, places where two provisions in the same contract contradict each other. Four of those conflicts appear in every single agreement examined. Meal and rest breaks versus continuous patient monitoring. Low census staffing reductions versus income security. Floating to understaffed units versus competency protections. Schedule stability versus operational flexibility. Fleming has been processing grievances related to these exact tensions for six years. She has never seen them described as structural conflicts. She has always experienced them as management problems to be solved shift by shift, case by case, grievance by grievance. The article makes an argument she finds difficult to dismiss: paying a nurse premium pay for a missed break does not solve the problem of the missed break. It compensates for the harm while leaving the structural cause intact. The conflict is in the contract. Not because the contract is badly written, but because the contract is trying to protect two legitimate interests that genuinely collide. ## The kitchen table Later in the week, Fleming does something she would not mention at work. She opens ChatGPT and asks: “In hospital accounting, is nursing labor treated as a variable cost or a fixed cost?” The answer confirms what she has lived for 22 years. Nursing is the primary labor category that gets adjusted in response to short-term financial pressure. When census drops, nurses get sent home. When census rises, overtime and agency staff fill the gap. The hospital cannot operate without nurses, but the accounting system treats them as a cost to be minimized rather than a capacity to be protected. Fleming asks a follow-up: “If nursing is treated as variable but is actually the constraint on what the hospital can do, what happens?” The answer uses a word she has now encountered three times in one week. Constraint. The word Sam used. The word in the article. And now the word a chatbot uses to describe the thing she has been managing without a name for it. ## Jess The following week, a 29-year-old nurse named Jess Reeves stops Fleming in the hallway. Jess has done something no one asked her to do. After the board meeting, she got curious. She pulled up the union contract on the WSNA website and asked ChatGPT to find places where two sections contradict each other. It found nine. The most obvious: Article 7 guarantees uninterrupted 30-minute meal breaks. Article 12 requires continuous patient monitoring. There is no provision for break relief coverage. Either you take your break and nobody watches your patients, or you skip your break and file a grievance later. Jess found this in one evening with her phone. Fleming has been filing grievance responses about it for six years. ## What is real here Fleming is fictional. Jess is fictional. The structural conflicts are not. The 134 conflicts came from an analysis I conducted across ten real Washington State nursing collective bargaining agreements. The four universal conflicts are real. The meal break versus patient monitoring contradiction exists in every CBA I examined. The premium pay mechanism that compensates for the harm without addressing the cause is standard practice across the industry. The pattern of nurses using AI tools to read their own contracts is speculative, but not by much. The contracts are public documents. The tools are free. The only thing that has been missing is a reason to look. I suspect the board meeting in Episode 01, or something like it, would be exactly the kind of catalyst that sends a curious person to their phone at 10 PM. ## What this episode is about On the surface, it is about a CNO processing a disruptive board meeting. Underneath, it is about three things. First, that structural problems often hide inside language that makes them look like management problems. “We need better scheduling” is a management problem. “The contract requires two things that cannot both be true at the same time” is a structural problem. The solutions are different. Second, that AI tools are changing who can see structural patterns. Fleming needed six years of experience to recognize the meal break conflict as chronic. Jess needed one evening with ChatGPT. The pattern was always there. The tools to see it were not. Third, that the people closest to the problem are often the last to get the analytical framework that names it. Fleming knew everything about these conflicts except what to call them. The article gave her a vocabulary. The vocabulary changed what she could do with what she knew. ## The series This is Episode 02 of the Cascade Valley series. [Episode 01](https://common-sense.com/insights/the-meeting-that-went-differently/) is the board meeting. [Episode 03](https://common-sense.com/insights/resolving-a-sweet-dilemma/) is a standalone teaching episode on the Evaporating Cloud. [Episode 04: The Other Calculation](https://common-sense.com/insights/the-other-calculation/) follows CFO Steven Park through a parallel discovery about cost accounting. [Episode 05: The First Session](https://common-sense.com/insights/the-first-session/) is the ensemble working group episode. [Episode 06: After the First Session](https://common-sense.com/insights/after-the-first-session/) is the quiet conversation afterward about why it worked. ## The structural conflicts research If you work in hospital administration, nursing leadership, or labor relations, and the structural conflicts described in this episode match what you see in your own contracts, I would welcome the conversation. The analysis covered ten Washington State CBAs, but the patterns are not unique to Washington. Every state with unionized nursing staff has some version of these contradictions. The question is not whether the conflicts exist. It is whether anyone is working on resolving them structurally rather than managing them grievance by grievance. If you are interested in that question, reach out. [john@common-sense.com](mailto:john@common-sense.com). * * * ## Sources - Structural Conflicts in WA State Nursing Agreements — the analysis Fleming discovers, covering 10 CBAs and 134 structural conflicts. - [Hidden Conflicts in Healthcare](https://common-sense.com/insights/hidden-conflicts/) — a related Theory of Constraints analysis of structural conflicts embedded in a hospital financial assistance policy. - [Why Burnout Persists](https://common-sense.com/insights/why-burnout-persists-series/) — a four-part series on the structural drivers of clinician burnout, including workload and schedule design. Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # The Other Calculation -- Cost vs Throughput | Common Sense Systems URL: https://common-sense.com/insights/the-other-calculation/ [Insights](https://common-sense.com/insights/) # The Other Calculation By John Sambrook · March 7, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Operations](https://common-sense.com/insights/tag/operations/) ## TL;DR An empty operating room costs a hospital roughly 36 to 50 dollars per minute in wasted overhead. But the throughput it fails to generate can be five to ten times that. These are not competing answers to the same question. They are precise answers to two different questions, one from financial accounting and one from managerial accounting. Episode 04 of the Cascade Valley series follows CFO Steven Park as he discovers the gap. * * * There is a number that hospital CFOs know well: the cost of one minute of operating room time. The published literature puts it at 36 to 50 dollars per minute depending on who is counting and what they include. A [2018 JAMA Surgery study](https://jamanetwork.com/journals/jamasurgery/fullarticle/2673385) benchmarked it at 37 dollars per minute across California hospitals. A [2022 literature review in the Journal of Orthopaedic Business](https://jorthobusiness.org/index.php/jorthobusiness/article/view/23) landed at 46. The range is wide, but the floor is high. This number gets used to calculate the cost of waste. When an OR block sits empty, you multiply the minutes by the per-minute cost and arrive at a figure that feels meaningful. For a hospital with six ORs and 15% unutilized time during staffed hours, the math works out to roughly four million dollars per year. Not nothing. But against a 25-million-dollar capital request for new operating suites, it does not sound catastrophic. There is another calculation. It asks a different question. Not “what did the empty room cost us?” but “what did the empty room fail to produce?” ## Two questions, not one The distinction matters, and it is easy to miss. These two calculations are not rival answers to the same question. They come from different branches of accounting, and they measure different things. Financial accounting, the framework hospitals use for reporting, tax filings, and regulatory compliance, asks: what does it cost to operate this room? When the room sits idle, it assigns a share of the overhead, the staff, the depreciation, to that idle time. This produces a real and auditable number. It is useful for understanding where money goes. Throughput Accounting, a framework developed by the physicist Eli Goldratt as an alternative to traditional cost accounting, asks a different question: what does this room produce when it runs? Revenue minus the costs that are only incurred because a specific patient is on the table. Everything else, the salaries, the overhead, the building, is already spent whether the room runs or not. When the room sits idle, that production simply does not happen. Financial accounting tells you what idle time costs. Throughput Accounting tells you what idle time fails to produce. Both are correct. But when it comes to evaluating operational investments, only one of them measures the actual economic stakes. ## The gap In [Goldratt’s](https://en.wikipedia.org/wiki/Eliyahu_M._Goldratt) framework, throughput is revenue minus truly variable costs. The money that only gets spent because a specific patient is on the table: implants, disposable supplies, drugs consumed during the procedure. Everything else is already committed. The surgeon is salaried. The nurses are hourly, but if they are already scheduled and on the clock for that block, their cost is the same whether a patient is on the table or not. The anesthesiologist is on contract. The room is built. The lights are on. For a typical surgical case, revenue might average 22,000 dollars. Truly variable costs might be 4,000 dollars. The throughput per case is 18,000 dollars. That is the contribution to paying for everything else in the hospital. When a block sits empty, that 18,000 does not happen. And if the OR is the constraint, the bottleneck on what the hospital can produce, it cannot be recovered. There is no slack in next week’s schedule to absorb a delayed case. Next week’s blocks are full too. An hour lost at the bottleneck is an hour lost for the entire system, permanently. Goldratt considered this one of his most important insights. Run the numbers with this framing, and the same empty rooms that looked like a four-million-dollar problem now look like a 22-million-dollar problem. Same hours. Same idle time. Different question about what they are worth. ## Why it matters for purchasing decisions This gap does not just change how you evaluate capital spending. It changes how you evaluate every operational tool, every scheduling system, every staffing model. Consider a real pattern. A health system evaluates an AI-powered OR scheduling platform. The platform costs a meaningful annual subscription. The CFO compares the subscription cost against the cost of wasted OR time. The ROI is marginal. The system is deemed “too expensive.” They pass. Meanwhile, a competing health system down the road deploys the same platform. They unlock 3,200 additional surgical cases in a single year. They increase staffed room utilization by 25%. They do it without adding rooms or staff. What happened? Both CFOs did the math. But they were measuring against different numbers. The first measured against the cost of waste (four million dollars). The second, whether they used Goldratt’s language or not, was measuring against the throughput they could generate (22 million or more). The same subscription fee looks trivial against one number and expensive against the other. ## The audio drama Episode 04 of the Cascade Valley series, “The Other Calculation,” follows CFO Steven Park through a single day as he works through this exact discovery. It is the morning after the board meeting depicted in Episode 01. Park runs the standard cost-of-waste calculation. He gets the expected answer. Then he stumbles into an article about Throughput Accounting and runs the numbers a second way. The episode opens with a narrator’s foreword that frames the two accounting frameworks before Park’s story begins. This is intentional. The distinction between financial accounting and managerial accounting is precise and important, and having it stated clearly up front gives the listener the scaffolding to follow Park’s reasoning as he works through it in real time. The episode is a companion piece to Episode 02, “After the Meeting,” which followed Chief Nursing Officer Barbara Fleming as she processed the board meeting from a completely different angle. Fleming discovered structural conflicts embedded in nursing contracts. Park discovers a structural gap in how the hospital measures value. Both are preparing, without knowing it, to bring something new to the working group that the board authorized at the end of Episode 01. ## What is real here The hospital is fictional. Steven Park is fictional. But the numbers are real. OR cost per minute comes from published research. The throughput calculation uses averages consistent with actual hospital case data. The pattern where a health system passes on an optimization tool because it was evaluated against the wrong number is something I have seen firsthand. And the competing health system that deployed the platform and unlocked thousands of additional cases? That is [a matter of public record](https://www.healthcareitnews.com/news/multicare-uses-predictive-analytics-add-3200-surgeries-one-year). The cost-world vs. throughput-world distinction is not new. Goldratt wrote about it decades ago. But it remains surprisingly rare in how hospital finance teams evaluate operational investments. Most capital decisions and vendor evaluations in healthcare still use cost-based framing. The question “what does this fail to produce?” is asked far less often than “what does this cost?” ## The series so far If you are new to the Cascade Valley series: [Episode 01: The Meeting That Went Differently](https://common-sense.com/insights/the-meeting-that-went-differently/) is the 56-minute board meeting where Sam, an AI, participates for the first time and asks the questions nobody else was positioned to ask. [Episode 02: After the Meeting](https://common-sense.com/insights/after-the-meeting/) follows CNO Barbara Fleming through the week after the board meeting as she discovers structural conflicts in nursing contracts that explain the staffing problems she has been managing for years. [Episode 03: Resolving a Sweet Dilemma](https://common-sense.com/insights/resolving-a-sweet-dilemma/) is a standalone teaching episode that walks through the Evaporating Cloud tool using a bakery pricing dilemma. Episode 04, this one, follows the CFO. [Episode 05: The First Session](https://common-sense.com/insights/the-first-session/) is the ensemble working group episode where the private discoveries from earlier episodes enter a room and converge. [Episode 06: After the First Session](https://common-sense.com/insights/after-the-first-session/) is the quiet conversation afterward — Commissioner Tanaka stays behind and asks Sam why the session went differently than any meeting he has seen in six years. ## The question underneath the question Park’s discovery in this episode is not really about OR scheduling or vendor pricing. It is about the sufficiency of the framework you use to evaluate decisions. Cost accounting is not wrong. It correctly measures what it measures. The problem is what it does not measure. And when the thing it does not measure is five times larger than the thing it does, the framework is not just incomplete. It is actively misleading. Every organization has some version of this. A metric that answers the question you are asking while hiding the question you should be asking. The distance between those two questions is where the real money lives. If you run a hospital, a clinic, or any operation where expensive capacity sits idle while demand goes unmet, and you have been evaluating solutions against the cost of the waste rather than the throughput you are not generating, it might be worth running the numbers both ways. The gap may surprise you. I am happy to think through the specifics with you. [john@common-sense.com](mailto:john@common-sense.com). * * * ## Sources - Childers CP, Maggard-Gibbons M. [Understanding Costs of Care in the Operating Room](https://jamanetwork.com/journals/jamasurgery/fullarticle/2673385). _JAMA Surgery_. 2018;153(4):e176233. Mean OR cost of $37/min across California hospitals. - Zygourakis CC, et al. [The Cost of OR Time is $46.04 per Minute](https://jorthobusiness.org/index.php/jorthobusiness/article/view/23). _Journal of Orthopaedic Business_. 2022. Literature review of 51 articles on OR cost per minute. - [MultiCare Uses Predictive Analytics to Add 3,200 Surgeries in One Year](https://www.healthcareitnews.com/news/multicare-uses-predictive-analytics-add-3200-surgeries-one-year). _Healthcare IT News_. 25% increase in staffed room utilization without adding rooms or staff. - Goldratt EM. \_[The Goal](https://en.wikipedia.org/wiki/The_Goal_\(novel\))\_. 1984. The foundational work on Theory of Constraints and Throughput Accounting. Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Case Study: Turning a Support Bottleneck into a Competitive Advantage | Common Sense Systems URL: https://common-sense.com/insights/cost-center-to-growth-engine-toc-case-study/ [Insights](https://common-sense.com/insights/) # From 'Cost Center' to 'Growth Engine': A Theory of Constraints Success Story By John Sambrook · March 5, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Medical Devices](https://common-sense.com/insights/tag/medical-devices/), [Case Studies](https://common-sense.com/insights/tag/case-studies/), [Operations](https://common-sense.com/insights/tag/operations/) ## TL;DR A leading manufacturer of programmable ultrasound research systems had a reputation problem. Their instruments were technically excellent, but a passive, email-only support model — averaging 12 business days to close a setup call — was creating frustrated customers and a growing perception that the systems were “hard to use.” By applying the Theory of Constraints 5 Focusing Steps, we cut time-to-close to 2.5 days, drained the support backlog in 20 days, and transformed the support function from a cost center into a proactive growth engine. * * * Their instruments were the gold standard for independent research labs worldwide. Sophisticated, programmable systems valued between $125,000 and $150,000, capable of data acquisition speeds up to 6 GB/s. The kind of hardware that serious investigators trust for complex experiments. But complexity breeds friction. The setup process involved a host PC, specialized hardware, device drivers, and MATLAB integration. Even for brilliant researchers, the setup instructions were a minefield. One skipped step meant a non-functional system and a frustrated Principal Investigator demanding results — and demanding them now. Weekly internal meetings were plagued by reports of disgruntled customers. For a company whose reputation was built on engineering excellence, this was both embarrassing and dangerous. The natural impulse was to blame the documentation, or the customers, or the inherent complexity of the technology. None of those explanations were wrong, exactly. But they were also missing the real problem. ## Identifying the Constraint: A Policy Bottleneck Upon investigation, we identified a classic Policy Constraint. The company’s support model was built on local optimization. To minimize internal costs, they had built a passive, email-only ticketing system. Customers submitted a ticket. A support engineer responded when available. The back-and-forth stretched across days — and often weeks. The average time to close a setup call was **12 business days**. The reasons were structural, not personal. Customers frequently omitted information the engineer needed to diagnose the problem, because they did not know what was relevant. The engineer, working blind from email text alone, could not see the customer’s screen, could not observe the error in context, and had to request clarification in another round-trip message. Each exchange added a day or more of latency. A problem that might take 30 minutes to solve face-to-face became a two-week drip of incomplete emails. The customer experience was what you would expect: shouting into a void. A $150,000 system sitting inert on a bench. A researcher with a grant deadline. Twelve business days of asynchronous emails. By the time the problem was resolved, the damage to the relationship was already done. The company had unknowingly traded short-term support cost savings for long-term reputation damage. The policy that looked efficient from the inside was costing far more than it saved, measured in customer goodwill, public complaints, and lost referrals. ## Applying the 5 Focusing Steps To turn the tide, we applied the Theory of Constraints to the service loop. **Step 1: Identify the Constraint.** The bottleneck was not the technology, the documentation, or the complexity of the setup process. It was the Customer Service Policy that prioritized company cost over customer uptime. **Step 2: Exploit the Constraint.** The most valuable resource in the system was the senior engineer’s knowledge. Rather than wasting that knowledge on slow email threads where context was lost and momentum was broken, we asked how to channel it into the highest-impact interventions possible. The answer was real-time, direct engagement. **Step 3: Subordinate Everything Else.** We stopped measuring success by cost per ticket. We stopped worrying about whether a support interaction was “efficient” in isolation. We shifted entirely to a white-glove model: immediately contact the customer, invite them to a video session, use remote access software to fix the problem right then and there. The goal was system operational in under 30 minutes. Everything else was secondary. **Step 4: Elevate the Constraint.** Once the success of this model was proven — and it was proven quickly, because customers who had been bracing for another email thread were instead greeted by a competent engineer with remote access and a clear plan — the VP of Service codified the method. We trained the entire support team in the synchronous, high-touch protocol, effectively increasing the bandwidth of the company’s ability to recover customer relationships and protect its reputation. **Step 5: Prevent Inertia.** We did not stop at reactive support. Once the support channel was working, we turned it into a proactive sales tool. A quarterly check-in cadence — offering services like free transducer condition assessments — kept the company in regular contact with customers in a context of goodwill rather than crisis. This created a natural channel for identifying new sales opportunities and renewals. ## The Results The numbers moved fast. Within two months of starting the new protocol, the average time to close a setup call dropped from **12 business days to 2.5 days**. The backlog of pending calls — which had been a permanent fixture of the weekly meeting agenda — drained completely within 20 days. From that point on, the queue hovered at one or two open calls on any given day. Management attention that had been consumed by customer escalations was freed up for product development and sales strategy. But the numbers only tell part of the story. At a well-known ultrasound research lab at Duke University, a graduate student had been struggling for weeks to get her new system running under the old email-based process. When we scheduled a call and connected with remote access, the problem was resolved in 30 minutes. She told us: _“Thank you! I was so embarrassed by being unable to get this fixed I was contemplating quitting this lab.”_ That is not a customer satisfaction metric. That is a person whose career trajectory changed because the support model changed. The Old Way (Local Optimization) The TOC Way (Global Throughput) **Primary Goal** Minimize internal support costs Maximize customer system uptime **Communication** Asynchronous email (passive) Synchronous video and remote access (active) **Success Metric** 12 business days to close 2.5 days average; most resolved same-day **Customer Experience** Frustration; “Shouting into a void” Relief; professional partnership **Sales Impact** Negative (public complaints) Positive (referrals and upgrades) By breaking the policy constraint of minimizing support costs, the company unlocked a significant increase in market throughput. The sales organization now had a legitimate reason for regular customer contact. A once-resented service department became a proactive engine for customer retention and new revenue. ## Why This Pattern Repeats I tell this story because the policy constraint is one of the most common and most overlooked bottlenecks I encounter. Hardware companies in particular tend to view support as a cost to be minimized rather than a strategic lever. This makes sense on a spreadsheet and is almost always wrong in practice. When your product is complex, expensive, and mission-critical, your customer’s ability to use it is inseparable from your reputation. Every hour they spend waiting for an email response is an hour in which their opinion of your company is moving in one direction. The theory of constraints gives you a way to see this clearly. When you measure the system — not just the support budget, but the full chain from customer purchase to customer success — the policy constraint becomes obvious. The question is whether you have the organizational will to break it. In this case, the VP of Service had that will. Once the logic was laid out, the change was not controversial. It was obvious. That is usually what happens when you find the real constraint. If your product is technically excellent but your customer relationships are not reflecting that excellence, I am happy to talk through what you are seeing. The bottleneck is almost always findable, and finding it is most of the work. You can reach me at [john@common-sense.com](mailto:john@common-sense.com). ## Sources - [Theory of Constraints (overview)](https://en.wikipedia.org/wiki/Theory_of_constraints) - [Goldratt, E. M. (1984). _The Goal: A Process of Ongoing Improvement_.](https://en.wikipedia.org/wiki/The_Goal_\(novel\)) - [5 Focusing Steps](https://www.tocico.org/page/whatis) Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Case Study: One Constraint Cost a MedTech Team Six Months | Common Sense Systems URL: https://common-sense.com/insights/one-tool-was-starving-four-teams/ [Insights](https://common-sense.com/insights/) # One Tool Was Starving Four Teams By John Sambrook · March 5, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Medical Devices](https://common-sense.com/insights/tag/medical-devices/), [Case Studies](https://common-sense.com/insights/tag/case-studies/) ## TL;DR A clinical ultrasound project was six months behind schedule. The constraint was a web-based register map tool that forced every hardware change through four manual updates across four teams. Replacing it with a version-controlled Python framework recovered the schedule in eight weeks. * * * A clinical ultrasound manufacturer in the Pacific Northwest was building a high-end imaging system. The hardware architecture was serious: custom ASICs and a large FPGA at the center of the design. Thousands of register definitions — bit-fields, DMA semantics, interrupt controls — described the boundary between hardware and everything else. Hardware engineers, firmware developers, software engineers, and verification teams all needed accurate, current register maps to do their work. The team was strong. The investment was real. The project was six months behind schedule. I joined as systems architect and tooling lead. It took me about a week to see where the schedule had gone. ## The Constraint Was Not the Engineering The team was managing all of its device register definitions through a static, web-based UI. Engineers would log in, define or update register fields, and the tool would store the data. It worked, in the narrow sense that the definitions were in there somewhere. But it had three properties that, in combination, were strangling the project. **No version control.** Hardware register definitions changed constantly during active development. The web UI had no branching, no rollback, no way to see what changed between Tuesday and Thursday. When a bit-field shifted in the FPGA, there was no reliable way to know what downstream artifacts were now out of sync. **Manual propagation.** A single register change in hardware required four separate manual updates: the RTL source, the C/C++ header files for firmware and software, the module specification document, and the debugger scripts. Four artifacts, maintained by hand, by different people, on different schedules. Each one was a chance for a transcription error. Each transcription error was a bug that would surface weeks later during integration, when it was expensive to find and expensive to fix. **No automation path.** Because the tool was a closed UI rather than a data source, there was no way to generate downstream artifacts from it. Every team was doing translation work by hand — copying register layouts from the UI into their own formats, and re-doing that work every time something changed. In Theory of Constraints terms, this tool was the system constraint. Everything downstream of it — firmware development, software integration, verification, documentation — was limited by the rate at which accurate register information could propagate through the project. Four teams were waiting on the same bottleneck, and the bottleneck was not a person or a lab or a piece of equipment. It was a tool that everyone depended on and nobody had questioned. The symptoms were familiar. Integration bugs that turned out to be stale register definitions. Verification test failures that were really documentation drift. Engineers spending hours cross-checking header files against the UI instead of writing code. The project was not behind because people were slow. It was behind because a substantial fraction of engineering effort was being consumed by manual synchronization work that should not have existed. ## What I Built The fix was conceptually simple: make the register map a single source of truth that could generate everything downstream automatically. I designed a Python-based device modeling framework. Instead of filling out forms in a web UI, engineers wrote a Python constructor that built a hierarchical tree of first-class objects: System, Block, Register, Bitfield. The register map lived in version-controlled code, which meant it could be branched, diffed, merged, and reviewed like any other engineering artifact. Once the data structure was instantiated, a suite of generators traversed the tree and produced the downstream artifacts automatically: - **C/C++ API code and memory maps** for firmware and software teams. Header files that matched the hardware, generated from the same source, every time. - **SystemVerilog test benches** for register-level verification. The verification team got test infrastructure that was guaranteed to match the current hardware definition. - **Print-ready documentation.** A pipeline from reStructuredText through LaTeX to PDF produced a module specification — what the team called the ModSpec — that was complete and accurate by construction. No manual transcription, no drift. - **Debugger macros** that let field engineers and developers inspect hardware state in plain English instead of decoding hex values by hand. One change to a register definition propagated everywhere it needed to go. Automatically. Correctly. ## What Changed The effects showed up fast. The manual synchronization work disappeared. Engineers who had been spending hours cross-checking headers against the UI were writing code instead. Integration meetings got shorter because the artifacts matched — there was nothing to reconcile. The class of bugs caused by stale or mismatched register definitions dropped to zero. Not reduced. Zero. When the register map is the single source of truth and everything else is generated from it, there is no room for transcription errors. We stopped debugging typos and started debugging physics. The verification team saw the biggest immediate gain. Their test benches were generated from the same register definitions as the firmware headers and the RTL. When a test failed, it meant something real was wrong, not that someone had copied a bit-field offset incorrectly three weeks ago. Metric Before After **Development velocity** Stalled (0.5x) Doubled (2.0x) **Schedule** 6 months behind Recovered in ~8 weeks **Register sync errors** Frequent, costly Zero **Adoption** — Mandatory global standard The framework became the standard across the organization. Not because anyone mandated it from above, but because the teams that used it stopped having an entire category of problems that the teams still on the old process were fighting every week. ## The Pattern I have seen versions of this constraint in every complex hardware-software development project I have worked on. The specifics change — sometimes it is a communication protocol, sometimes it is a build system, sometimes it is a requirements database — but the structure is the same. A shared dependency that every team touches becomes the limiting factor for the whole system, and nobody sees it as the constraint because it is infrastructure, not product. The Five Focusing Steps from Theory of Constraints apply directly: 1. **Identify.** The register map tool was the constraint. Not the team, not the budget, not the hardware complexity. 2. **Exploit.** There was nothing to exploit — the tool had no unused capacity. It was architecturally incapable of supporting the project’s needs. 3. **Subordinate.** The entire project had already involuntarily subordinated itself to this tool. Every team’s schedule was paced by manual register propagation. 4. **Elevate.** Replace the tool with one that eliminates the constraint entirely. That is what the Python framework did. 5. **Repeat.** Once the register map was no longer the bottleneck, the next constraint became visible — and it was an engineering problem, not an infrastructure problem. That is how it should be. The reason these bottlenecks persist is that they look like minor inconveniences from any single team’s perspective. The firmware engineer who spends twenty minutes updating a header file does not think of it as a system constraint. It is just part of the job. But multiply that twenty minutes across four teams, dozens of registers, and hundreds of iterations over the life of a project, and you get six months of schedule slippage that nobody can point to a single cause for. That is what makes it a constraint rather than just a nuisance — it limits the throughput of the entire system, and the evidence is diffuse enough that it resists diagnosis. Finding it requires stepping back far enough to see the whole system, not just the piece you are working on. That is hard to do when you are heads-down on a deadline. It is exactly the kind of thing an outsider with systems discipline can see in a week that insiders, buried in the work, have been living with for months. If your engineering project has capable people and the progress does not match the effort, the problem is almost certainly structural. I am happy to think through what you are seeing. You can reach me at [john@common-sense.com](mailto:john@common-sense.com). Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Why Healthcare Needs Both TOC and Lean | Common Sense Systems URL: https://common-sense.com/insights/compass-and-toolkit-toc-lean-healthcare/ [Insights](https://common-sense.com/insights/) # The Compass and the Toolkit: Why Healthcare Needs Both TOC and Lean By John Sambrook · March 4, 2026 · [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Operations](https://common-sense.com/insights/tag/operations/) ## TL;DR Healthcare relies almost exclusively on Lean for process improvement, but Lean answers “where is waste?” while the Theory of Constraints answers “what limits throughput?” A systematic review of 42 TOC implementations in healthcare found 50% mean reductions in wait times and 34% increases in throughput. Using TOC as the strategic compass and Lean as the tactical toolkit produces results roughly an order of magnitude better than either alone. * * * ![Infographic showing TOC as the compass (five focusing steps: identify, exploit, subordinate, elevate, repeat) directing Lean tools (Value Stream Mapping, waste elimination, standardized work, kaizen) to the system constraint, producing roughly 10x improvement when combined versus either alone](https://common-sense.com/images/content/compass-and-toolkit-toc-lean.webp) An ophthalmologist in Portugal had a problem familiar to anyone who has worked in healthcare: too many patients waiting, not enough throughput, and a growing sense that the system was working against everyone in it. He did not hire a consulting firm. He did not launch a multi-year transformation initiative. He applied the Theory of Constraints’ five focusing steps, identified the actual bottleneck in his imaging practice, reorganized the workflow around it, and [improved patient throughput by 64%](https://pmc.ncbi.nlm.nih.gov/articles/PMC10868449/) in a matter of weeks. The cost was essentially nothing. (A candid footnote: the improvement was not sustained after the doctor who championed it left the organization. That fact is itself instructive, and we will return to it.) That result is not an anomaly. A [systematic review of 42 TOC implementations in healthcare](https://pmc.ncbi.nlm.nih.gov/articles/PMC8812771/), published in the journal _Health Systems_, found that every single one reported positive outcomes. The mean results across those studies were striking: 50% reductions in patient waiting time, 38% reductions in length of stay, 43% increases in operating room productivity, and 34% increases in overall throughput. So why has almost no one in hospital leadership heard of the Theory of Constraints? ## Two Frameworks, Two Questions Healthcare’s dominant process improvement methodology is Lean, adapted from the Toyota Production System. Lean asks: _Where is waste?_ It provides a disciplined set of tools for finding and eliminating non-value-adding steps in a process. Value Stream Mapping, 5S, standardized work, kaizen events, A3 problem solving. These are good tools. In the right context, they produce real results. The Theory of Constraints, developed by physicist Eli Goldratt and introduced in his 1984 novel _The Goal_, asks a different question: _What is limiting throughput?_ Rather than improving processes broadly, TOC identifies the single point in a system that governs overall performance, the constraint, and focuses all improvement effort there. Everything else is subordinated to protecting and maximizing that constraint. These are not competing philosophies. They answer different questions. The problem is that healthcare has embraced one and largely ignored the other, and the one it ignores is the one that tells you where to aim. ## What Lean Does Well Lean excels at process-level improvement. If you know your emergency department triage process is full of redundant steps, Lean will help you map it, identify the waste, and redesign it. If your surgical instrument sterilization workflow has unnecessary transport and waiting, Lean’s tools will find and fix that. These are genuine improvements, and hospitals that apply Lean tools with discipline see real gains in specific areas. But there is a pattern worth noticing. The most common Lean implementations in healthcare are 5S workplace organization, Value Stream Mapping workshops, and localized kaizen events. These are fragments of the Lean system, not the system itself. Practitioners of what Bob Emiliani calls “Real Lean” would recognize that most hospital implementations barely scratch the surface of what Toyota actually does. The evidence reflects this gap. A [review in the Journal of Healthcare Engineering](https://onlinelibrary.wiley.com/doi/10.1155/2020/8875902) reports that researchers have estimated 70% of Lean projects fail in healthcare organizations, with full deployment of Lean principles reported in as few as 4% of U.S. hospitals. Across all industries, an [Industry Week survey](https://www.industryweek.com/operations/continuous-improvement/article/21144299/why-do-so-many-lean-efforts-fail) found that roughly 70% of plants using Lean achieved only 2% of their objectives. A [province-wide Lean transformation in Saskatchewan](https://pmc.ncbi.nlm.nih.gov/articles/PMC4833201/), one of the largest ever attempted in healthcare, showed no statistically significant improvement in patient satisfaction across care centers. These are not arguments against Lean. They are arguments against partial Lean, against adopting the tools without understanding the system they belong to. And they point toward a deeper problem: even well-executed Lean can improve the wrong things. ## The Problem Lean Cannot Solve Consider a hospital where the emergency department has been Lean-optimized. Triage is faster. Patient flow through assessment is smoother. Throughput in the ED has improved. But patients are now boarding in ED hallways for hours because there are no inpatient beds available. The constraint is downstream, in discharge, in post-acute placement, in the policies and staffing patterns that determine how quickly beds turn over. In this scenario, the ED improvement does not help the patient. It moves people more efficiently into a queue that cannot clear. The system’s throughput has not changed. Only the location of the waiting has shifted. Lean does not have a built-in mechanism for asking, “Should we even be working on this process?” Its orientation is to improve whatever process you are looking at. TOC’s orientation is different: find the constraint first, then decide where to invest your improvement effort. This distinction matters enormously in healthcare, where resources for improvement are limited, staff are already stretched, and every kaizen event or Lean project competes for the same finite pool of attention and energy. Spending six months optimizing a non-constraint process is not just unproductive. It is demoralizing to the people involved when nothing meaningfully changes for patients. ## What TOC Brings That Lean Lacks The Theory of Constraints contributes three things that Lean’s toolkit does not provide. First, **focus**. The five focusing steps (identify the constraint, exploit it, subordinate everything else to it, elevate it if necessary, then repeat) give an organization a sequence. They answer “what should we work on next?” before anyone picks up a Lean tool. In the ophthalmology case, this sequence led the doctor to realize that the constraint was not where he assumed it would be. His initial guess was wrong. The focusing steps corrected it in days, not months. Second, **conflict resolution**. TOC includes a set of thinking tools, most notably the Evaporating Cloud, that surface the hidden assumptions behind organizational conflicts. Lean has root cause analysis (5 Whys, fishbone diagrams), but these assume a single causal chain. Healthcare problems frequently involve competing legitimate requirements: the need for thorough documentation versus the need for fast patient throughput, the need for specialist availability versus the need for schedule flexibility. The Evaporating Cloud makes these conflicts explicit and identifies the assumptions that can be challenged. Lean has no equivalent. Third, **system-level thinking about throughput**. TOC measures success in terms of throughput (the rate at which the system generates its goal), not in terms of local efficiency. This prevents the optimization trap where every department looks efficient on paper while the system as a whole underperforms. Lean’s emphasis on eliminating waste can, if applied without system-level guidance, encourage exactly this kind of local optimization. ## The Compass and the Toolkit A useful way to think about the relationship: TOC is the compass, Lean is the toolkit. The compass tells you where to go. It identifies the constraint, determines the direction of improvement, and prevents you from expending effort in places that will not move the needle. The toolkit gives you the means to make improvements once you know where to apply them. Value Stream Mapping at the constraint. Waste elimination at the constraint. Standardized work at the constraint. This is not a theoretical distinction. A [published case study](https://www.synchronix.com/comparing-toc-and-lean/comparing-lean-and-six-sigma-and-the-impact-of-theory-of-constraints/) documents a two-year experiment across 21 plants at a California corporation. Eleven plants used Six Sigma alone, four used Lean alone, and six used TOC as the strategic framework with Lean and Six Sigma applied within it. The six TOC-led plants generated 89% of the total cost savings across all 21 plants. The eleven Six Sigma plants generated 7%. The four Lean plants generated 4%. The study was conducted and published by practitioners rather than academic researchers, but the scale and duration of the experiment make it difficult to dismiss. Those numbers deserve a moment of reflection. The plants that knew where to focus their Lean and Six Sigma efforts outperformed the plants that applied those same tools without strategic direction by roughly an order of magnitude. ## Why Healthcare Chose Lean (and Missed TOC) The history is partly institutional. Virginia Mason Medical Center’s high-profile adoption of the Toyota Production System in the early 2000s created a template that other health systems followed. The “eliminate waste” framing is also politically comfortable. It sounds like good stewardship. No one objects to reducing waste. “Find your constraint” requires something harder. It requires admitting that your system has a chokepoint, that not all parts of the organization are equally important to overall performance, and that some departments may need to operate below their local maximum to protect the performance of the whole. These are politically difficult conversations. They threaten budgets, headcount justifications, and scheduling autonomy. There is also a knowledge gap. TOC has a much smaller community of practitioners than Lean. The academic literature on TOC in healthcare, while growing, is still modest. The systematic review mentioned earlier found only 42 implementations to analyze, compared to hundreds of published Lean healthcare studies. TOC simply has not achieved the visibility that Lean has in healthcare circles. None of this means TOC is better than Lean. It means they solve different problems, and healthcare is only solving one of them. ## Getting Started For healthcare leaders considering this integration, the sequence matters. Start with TOC. Before launching another Lean project, ask: do we actually know what is limiting our system’s throughput? Not what seems inefficient, not what generates the most complaints, but what actually governs how many patients we can serve well. If you cannot answer that question with confidence, your Lean projects are navigating without a compass. Once you have identified the constraint, apply Lean tools there. Map the value stream at the constraint. Eliminate waste at the constraint. Standardize work at the constraint. Subordinate non-constraint processes to protect the constraint’s output. This is where Lean’s tools will produce their maximum return. Then look at the results. If the constraint has moved (which it should, if you have successfully elevated it), identify the new constraint and repeat. This cycle of constraint identification followed by focused Lean application is what produces compounding, system-level improvement rather than isolated departmental gains. For practitioners who want a deeper look at the integration framework, decision heuristics, and source literature, see our reference page on TOC and Lean integration. ## The Real Obstacle The biggest barrier to adopting this approach is not technical. The five focusing steps are straightforward. The Lean tools are well understood. The integration sequence is not complicated. The real obstacle is the willingness to ask the focusing question honestly and to follow the answer wherever it leads, even when the answer is uncomfortable. The constraint might be in a politically powerful department. It might be a policy that someone’s career is built on defending. It might be an assumption so deeply embedded that no one has questioned it in years. And there is the sustainability question. The Portuguese ophthalmology practice lost its gains when its champion left. This is not unique to TOC; it is the central challenge of any improvement methodology. The 70% failure rate for Lean in healthcare tells the same story from the other side. What makes improvement stick is not the methodology. It is whether the organization internalizes the thinking behind it. TOC’s focusing question, “What is currently limiting our throughput?”, needs to become a reflex, not a one-time project. An ophthalmologist in Portugal asked the question, followed the answer, and [improved throughput by 64% in weeks](https://pmc.ncbi.nlm.nih.gov/articles/PMC10868449/). [Forty-two healthcare organizations](https://pmc.ncbi.nlm.nih.gov/articles/PMC8812771/) in the published literature asked some version of the same question and, without exception, found meaningful improvement. The question is available to every health system. The tools exist. The evidence is there. What remains is the decision to look. If your organization is trying to figure out where to aim its next improvement effort, I am happy to think through it with you. Reach me at [john@common-sense.com](mailto:john@common-sense.com). ## Sources - [pmc.ncbi.nlm.nih.gov/articles/PMC10868449/](https://pmc.ncbi.nlm.nih.gov/articles/PMC10868449/) - [pmc.ncbi.nlm.nih.gov/articles/PMC8812771/](https://pmc.ncbi.nlm.nih.gov/articles/PMC8812771/) - [onlinelibrary.wiley.com/doi/10.1155/2020/8875902](https://onlinelibrary.wiley.com/doi/10.1155/2020/8875902) - [industryweek.com/operations/continuous-improvement/article/21144299/why-do-so-many-lean-efforts-fail](https://www.industryweek.com/operations/continuous-improvement/article/21144299/why-do-so-many-lean-efforts-fail) - [pmc.ncbi.nlm.nih.gov/articles/PMC4833201/](https://pmc.ncbi.nlm.nih.gov/articles/PMC4833201/) Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # The One Thing Slowing Down Your Business | Common Sense Systems URL: https://common-sense.com/insights/one-thing-slowing-down-your-business/ [Insights](https://common-sense.com/insights/) # The One Thing Slowing Down Your Business (And How to Find It) By John Sambrook · March 4, 2026 · [Small Business](https://common-sense.com/insights/tag/small-business/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Operations](https://common-sense.com/insights/tag/operations/) ## TL;DR Every business has one thing that limits how much it can get done. Improving that one thing improves everything. Improving anything else changes nothing. Most small business owners spend their time and money improving the wrong things. Here is how to find the right one. * * * ![Infographic showing five steps to find and fix a business constraint: find it, get the most out of it, organize around it, invest if needed, repeat](https://common-sense.com/images/content/one-thing-slowing-down-constraint-steps.webp) Mike runs a residential remodeling company. Three crews. Good reputation. Steady referrals. He should be doing well, and in some ways he is. But he is working sixty-hour weeks, jobs routinely run two to three weeks late, and his margins are thinner than they should be for the volume he is doing. He has tried the obvious fixes. He hired a project coordinator. He bought scheduling software. He started holding Monday morning meetings. Each one helped a little, for a while. None of them solved the underlying problem. Mike cannot quite name the problem, but he feels it every day: the business is busy, but it is not really moving forward. Mike has never heard of Lean manufacturing or the Theory of Constraints. He does not need to. What he needs is one idea, and it is this: **In every business, there is one thing that limits how much you can get done. If you improve that one thing, everything gets better. If you improve anything else, nothing much changes.** That is the whole insight. The rest of this article is about how to use it. ## Finding Your One Thing The natural instinct is to improve whatever is most visibly broken. The crew that is always behind. The supplier who is always late. The paperwork that piles up. But visible problems are not always the ones that matter most. Here is a better way to think about it. Imagine your business as a chain. Orders come in on one end. Finished work and paid invoices come out the other. Every link in the chain is a step: selling the job, getting permits, ordering materials, scheduling crews, doing the work, handling inspections, closing out the project, collecting payment. The chain is only as strong as its weakest link. More precisely, the chain can only move as fast as its slowest link. That slowest link is the constraint. Everything upstream of it piles up. Everything downstream of it waits. For Mike, the constraint turned out to be himself. Every change order, every material substitution, every customer question about scope had to go through him personally. His crews could only move as fast as he could answer questions, approve changes, and make decisions. He was the bottleneck in his own business, and no amount of scheduling software or Monday meetings was going to change that. Those improvements were on the wrong link of the chain. ## The Five Steps Once you know what to look for, the process is simple. It was developed by a physicist named Eli Goldratt, who spent his career helping businesses find and fix their constraints. He laid it out in five steps. **Step 1: Find the constraint.** What is the one thing that limits how much your business can produce? Look for the place where work piles up, where people are always waiting, or where you are personally the bottleneck. In a remodeling business, common constraints include the owner’s decision-making capacity, permit turnaround times, a specific subcontractor who is always behind, or the availability of a specialized crew (tile, electrical, plumbing). **Step 2: Get the most out of it.** Before you spend any money, squeeze everything you can out of the constraint. If the constraint is you, that means delegating decisions that do not actually require your judgment. If the constraint is a subcontractor, it means making sure they are never waiting on you for information, materials, or access. If the constraint is permit processing, it means submitting applications the day the contract is signed instead of waiting until plans are finalized. This step alone often produces surprising results. Most constraints are operating well below their potential because the rest of the business is not organized to support them. **Step 3: Organize everything else around it.** This is the step people skip. Once you know what the constraint is, everything else in the business should be arranged to keep it running at full capacity. That might mean your sales process paces new work to what the constraint can handle rather than booking everything that comes in. It might mean your material ordering is timed to the constraint’s schedule, not to a generic calendar. For Mike, this meant giving his lead carpenters authority to approve change orders under a certain dollar amount without calling him. It meant pre-building a decision guide for common material substitutions. It meant his project coordinator’s primary job was not tracking schedules but keeping decisions flowing to the right people before they became bottlenecks. **Step 4: If needed, invest.** Only after Steps 2 and 3 have been fully applied should you spend money to expand the constraint. Maybe that means hiring a second lead who can handle the jobs you used to run personally. Maybe it means switching to a faster subcontractor. Maybe it means paying expedite fees on permits for jobs above a certain size. The reason this step comes last: if you invest before you have gotten the most out of what you have, you will spend money solving a problem that better organization could have solved for free. Most small businesses jump straight to this step, which is why they are always investing but never quite getting ahead. **Step 5: Do it again.** When you fix one constraint, another one becomes the new limit. That is not a problem. It is progress. The business that was stuck at $1.2 million in annual revenue because the owner was the bottleneck might get to $1.8 million once that constraint is broken. Now maybe the new constraint is crew capacity, or estimating bandwidth, or cash flow. Find it, work through the steps again. ## What This Looks Like in Practice Here is what changed for Mike (and what typically changes for businesses like his). Before: Mike was on the phone constantly, answering questions from three crews, approving every decision, personally visiting every job site at least once a day. His crews would wait an hour or two for answers. Jobs ran late. Customers got frustrated. Mike worked sixty-hour weeks and felt like he was falling behind anyway. After: Mike identified himself as the constraint. He built a simple decision guide for his lead carpenters covering the twenty most common on-site decisions (material substitutions, minor scope changes, scheduling adjustments). He set a dollar threshold: anything under $500, the lead decides. He moved his project coordinator’s focus from schedule tracking to decision support, making sure leads had the information they needed before they needed it. Within a month, his crews were waiting less. Jobs started finishing closer to schedule. Mike’s phone rang less. He got back roughly ten hours a week, which he used to estimate new work, something he had been too busy to do consistently. Revenue went up not because he worked harder, but because the constraint was no longer choking the system. He did not need to learn management theory. He needed to find the one thing that was slowing everything down and fix it. ## Common Constraints in Small Businesses Different businesses have different constraints. Here are patterns I see frequently. **The owner is the bottleneck.** This is the most common constraint in businesses under $5 million in revenue. Every decision, every approval, every customer conversation goes through one person. The business can only grow as fast as that person can process information and make choices. The fix is almost always some combination of delegation, decision guides, and clear authority boundaries. **A key employee or subcontractor.** If one person or team has a specialized skill that no one else can do, they become the constraint. The fix is either cross-training (so the skill is not concentrated in one place), or organizing the entire workflow to ensure that person is never waiting on anything. **Cash flow.** You have the work, the people, and the capacity, but you cannot start the next job until the last one pays. The constraint is in the financial process, not the operational one. The fix is usually in billing frequency (progress billing rather than completion billing) or payment terms with suppliers. **Estimating and sales.** You have the capacity to do more work, but you cannot generate enough bids or close enough deals to fill the pipeline. The constraint is at the front end. Adding more crews or buying more equipment will not help. **External processes.** Permits, inspections, supplier lead times. These are constraints you do not control directly, but you can organize your business to minimize their impact. Submit earlier. Build buffer time into schedules for the steps you know are unpredictable. Do not let an external constraint sit idle because you were not ready on your end. ## Why “Improve Everything” Does Not Work The temptation is always to improve everything at once. Better scheduling. Better communication. Better tools. Better trucks. The problem with improving everything is that only one improvement actually matters at any given time, and the rest are wasted effort. If your constraint is the owner approving every decision, then better scheduling software does not help. If your constraint is cash flow, then a new truck does not help. If your constraint is a slow subcontractor, then Monday morning meetings do not help. This is not intuition for most people. It feels productive to improve things. But improving a non-constraint is like widening a four-lane highway when the bottleneck is a two-lane bridge five miles downstream. More lanes, same traffic jam. The discipline is to find the constraint first, then improve only at the constraint, then make sure everything else supports it. That sequence, applied consistently, produces compounding results over time. Not because you are working harder, but because every improvement effort is aimed at the thing that actually matters. ## Going Deeper The idea behind this article comes from the Theory of Constraints, developed by Eli Goldratt. His book [_The Goal_](https://en.wikipedia.org/wiki/The_Goal_\(novel\)) tells the story through a manufacturing plant, but the thinking applies to any business. It is a novel, not a textbook, and it is a fast read. For a more detailed look at how this thinking integrates with other improvement methods (including Lean, which you may have encountered in a different context), see our reference page on TOC and Lean integration. If you are running a small business and something about this resonates, I am happy to think through your specific situation. Sometimes a thirty-minute conversation is enough to identify the constraint. Reach me at [john@common-sense.com](mailto:john@common-sense.com). ## Sources - \[en.wikipedia.org/wiki/The\_Goal\_(novel\]([https://en.wikipedia.org/wiki/The\_Goal\_(novel)](https://en.wikipedia.org/wiki/The_Goal_\(novel\)) - [Theory of Constraints (Wikipedia)](https://en.wikipedia.org/wiki/Theory_of_constraints) - [TOCICO](https://www.tocico.org/) - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [AHRQ patient safety culture resources](https://www.ahrq.gov/sops/index.html) Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Resolving a Sweet Dilemma | Common Sense Systems URL: https://common-sense.com/insights/resolving-a-sweet-dilemma/ [Insights](https://common-sense.com/insights/) # Resolving a Sweet Dilemma By John Sambrook · March 4, 2026 · [Small Business](https://common-sense.com/insights/tag/small-business/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Strategy](https://common-sense.com/insights/tag/strategy/) ## TL;DR Most business dilemmas feel like a forced choice between two bad options. Theory of Constraints offers a third path: find the hidden assumption that makes them look like the only options. When that assumption is false — and it often is — the dilemma dissolves. Not a compromise. A dissolution. * * * Rachel owns a bakery. Her costs are up — flour, butter, labor, everything. She thinks she has two options: raise prices and lose customers to the cheaper grocery store down the street, or hold prices and watch her margins erode until the business fails. She has neither. Not really. This is the setup for a short audio drama I produced as part of my Common Sense Systems YouTube series. It is a fictional scenario, but the dilemma Rachel faces is one I have seen in real organizations more times than I can count. The names change. The industry changes. The structure of the trap stays the same. ## The Trap Dilemmas feel real because both sides are real. Rachel genuinely needs healthy margins — without them, the business fails. She genuinely needs loyal customers — without them, there is no business. Both needs are legitimate. Both are necessary. That is what makes the trap feel inescapable. The trap springs when we connect those needs to specific actions. To restore margins, she must raise prices. To keep customers, she must not raise prices. Raise prices, lose customers. Hold prices, lose the business. Pick your poison. Most people bounce between these two options for months. They make small compromises. They delay the decision. They pick whichever option feels least bad and live with the consequences. There is a better path, but it requires asking a different question. ## The Question Jonah Asks In the drama, a mentor figure named Jonah — borrowed from Eli Goldratt’s business novel _The Goal_ — walks Rachel through the problem. Jonah does not offer solutions. He asks questions. The one that breaks the dilemma open is this: why do you believe that raising your prices will cause you to lose customers? Rachel’s answer is immediate. People are price-sensitive right now. Everything costs more. She has watched other small businesses raise prices and lose regulars overnight. Jonah lets that sit for a moment. Then he asks: why do your customers come to you instead of the grocery store? The grocery store is already cheaper than you. The answer Rachel gives is what changes everything. Her sourdough is something you cannot get anywhere else in town. People drive across the city for it. She does custom cakes — birthday orders, wedding cakes — while the grocery store does sheet cakes with frosting from a bucket. She knows her regulars by name. Mrs. Patterson comes in every Saturday and Rachel has her order ready before she walks through the door. Jonah’s observation is quiet: your customers are not choosing you because of your prices. Rachel hears it. A long pause in the recording. Then: _huh._ ## The Hidden Assumption What Jonah has done is expose the assumption underneath the dilemma. Rachel believed that raising prices would cost her customers because she assumed her customers chose her on price. But that is not what she just described. Her customers choose her for things the grocery store cannot offer — quality, craft, a personal relationship built over years. The grocery store is already cheaper. Her customers already know that and come to her anyway. The assumption that connected “raise prices” to “lose customers” was simply not true. This is the core move in what Goldratt called the Evaporating Cloud. The tool works like this: you state the dilemma clearly — two needs that both serve a common goal, and two actions that directly conflict. Then you find the assumptions hiding underneath each side. You test whether those assumptions are actually true. When you find one that is not, the dilemma dissolves. Not a compromise, where both sides lose something. A dissolution — where you discover the conflict was never as real as it looked. ## What Comes Next Once Rachel sees that the assumption is false, the question shifts. Instead of asking which bad option to choose, she starts asking a more useful question: what could she offer that her customers value so much they would happily pay more? That is a completely different problem. And she already has ideas. The method has three steps. State the dilemma clearly. Find the assumptions connecting the needs to the conflicting actions. Test whether those assumptions are actually true. Most of the time, the assumption that holds the dilemma in place is something that feels obvious — so obvious that it never gets examined. People are price-sensitive. Of course they are. But price-sensitive in general is not the same as price-sensitive about this specific thing from this specific person for this specific reason. The assumption felt universal. It was not. ## A Note on the Episode This post accompanies Episode 03 of the Common Sense Systems YouTube series, “Resolving a Sweet Dilemma.” The episode is a short audio drama — about seven minutes — featuring Jonah and Rachel working through the problem in real time. The script and audio were produced using the same AI-assisted pipeline I have described in earlier posts. If you want to hear the method in action rather than read about it, [that is the place to start](https://youtu.be/_tkm6_B3VOs). Goldratt’s novel _The Goal_, where the character of Jonah first appears, is one of the best-selling business books of all time. If you have not read it, I recommend it without reservation. * * * If you find yourself caught in a dilemma that has been going nowhere for months, I am happy to take a look. Sometimes an outside pair of eyes is all it takes to see the assumption that has been holding the trap in place. You can reach me at [john@common-sense.com](mailto:john@common-sense.com). ## Sources - [youtu.be/\_tkm6\_B3VOs](https://youtu.be/_tkm6_B3VOs) - [Theory of Constraints (Wikipedia)](https://en.wikipedia.org/wiki/Theory_of_constraints) - [TOCICO](https://www.tocico.org/) - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [AHRQ patient safety culture resources](https://www.ahrq.gov/sops/index.html) Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Your Website Looks Great - Why No Calls? | Common Sense Systems URL: https://common-sense.com/insights/website-looks-great-phone-not-ringing/ [Insights](https://common-sense.com/insights/) # Your Website Looks Great. So Why Isn't the Phone Ringing? By John Sambrook · March 4, 2026 · [Small Business](https://common-sense.com/insights/tag/small-business/), [Operations](https://common-sense.com/insights/tag/operations/), [Strategy](https://common-sense.com/insights/tag/strategy/) ## TL;DR If your website gets traffic but does not generate calls, the problem is almost never the website itself. It is that your site says the same thing as every competitor. Visitors compare you on the only dimension left: price and convenience. The fix is not better design. It is a better offer, one that speaks to a specific problem your best clients have and that your competitors are not solving. * * * ![Infographic showing how three identical attorney websites become indistinguishable to visitors, and the three-step fix: start with the client's situation, name what you do differently, let the website reflect the offer](https://common-sense.com/images/content/website-generic-to-real-offer.webp) David is an attorney. He left a mid-size firm two years ago to start his own practice, focusing on business law for small companies. He is good at what he does. His clients like him. The ones who find him tend to stay. The problem is finding them. He did what you are supposed to do. He hired a web designer. The site is clean, professional, mobile-friendly. He paid for SEO. He shows up on the first page for “small business attorney” in his metro area. The analytics show traffic. People are visiting. But the phone barely rings. Maybe two or three inquiries a month from the website. Most of them are price shoppers looking for the cheapest LLC formation or a free consultation. The clients he actually wants to work with, owners of growing businesses who need ongoing counsel, do not seem to be finding him. Or if they are finding him, they are not picking up the phone. David has tried the fixes his web designer suggested. A bigger “Contact Us” button. A chat widget. Testimonials. A blog. A lead magnet. None of them moved the needle more than slightly. He is starting to wonder if the website just does not work for his kind of practice. Maybe he should spend the money on networking instead. Maybe referrals are the only thing that works for lawyers. Referrals do work. But the website problem is not what David thinks it is. ## The Problem Is Not the Website David’s site is fine. The design is professional. The SEO is working. People are landing on it. The problem is what happens in the fifteen seconds after they arrive. A potential client, let’s say she owns a 20-person manufacturing company, searches for a business attorney. She opens three or four tabs. She looks at each site for less than a minute. Here is what she sees on David’s site: “Experienced business attorney dedicated to helping small businesses succeed. Practice areas: entity formation, contracts, employment law, commercial real estate, mergers and acquisitions. Client-focused approach. Personalized service.” Here is what she sees on the next tab: “Experienced business attorney committed to helping small businesses grow. Practice areas: entity formation, contracts, employment law, commercial leasing, business transactions. We take the time to understand your business.” And the next one: “Trusted business attorney serving small and mid-size companies. Practice areas: business formation, contract drafting and review, employment matters, real estate, M&A. Your success is our priority.” She cannot tell them apart. They all say the same thing. They all list the same services. They all claim to be experienced, dedicated, and client-focused. None of them give her a reason to pick one over the others. So she does what any reasonable person does when the options all look the same: she picks the most convenient one, or the cheapest one, or she puts it off and asks a friend for a recommendation instead. David’s website does not have a design problem. It does not have an SEO problem. It does not have a conversion optimization problem. It has an offer problem. His site describes what he does without ever telling a potential client why it matters to them specifically. ## The Race to the Bottom When every competitor says the same thing, the only remaining differentiators are price and convenience. This is what a race to the bottom looks like. Nobody chose it. Nobody wants it. But it is the natural result of an entire industry describing itself in identical terms. David feels this pressure without being able to name it. The inquiries he does get are price-sensitive. They want to know what an LLC costs, not what a long-term legal relationship looks like. He is competing on a playing field where the only visible differences are his headshot, his hourly rate, and how close his office is to the freeway. The race to the bottom is not about bad marketing. It is about the absence of a meaningful offer. When you do not give people a reason to choose you, they default to the easiest comparison available: price. ## What an Offer Actually Is An offer is not a list of services. It is not a tagline. It is a specific answer to a specific problem that a specific kind of client has, stated clearly enough that the right person reads it and thinks, “That is exactly what I need.” David’s best clients are owners of growing businesses, companies with 10 to 50 employees that are hitting the stage where handshake agreements and boilerplate contracts start creating real risk. These owners are not looking for the cheapest attorney. They are looking for someone who understands what it feels like to run a growing company, where every legal question is tangled up with cash flow, hiring, customer relationships, and the owner’s personal liability. These owners have a problem that David solves better than most attorneys, but his website does not mention it. His site says “contracts” when what his best clients actually need is someone who can look at their supplier agreements and say, “This clause will cost you six figures if your biggest customer changes their payment terms.” His site says “employment law” when what his clients need is a phone call before they fire someone, not a lawsuit after. The gap between what David does and what his website says is where the phone calls are getting lost. ## Building a Real Offer Here is what it looks like to fix this. The process has three parts. **Start with the client, not with yourself.** David needs to stop describing his practice areas and start describing his client’s situation. Who are the people he does his best work for? What are they dealing with when they start looking for an attorney? What keeps them up at night? What has gone wrong (or is about to go wrong) that makes legal help feel urgent? For David’s best clients, the answers are things like: “We signed a contract two years ago that seemed fine, and now our biggest vendor is using a clause we did not fully understand to squeeze our margins.” Or: “We want to bring on a partner, but we do not know how to structure it so that we are protected if it does not work out.” Or: “We are growing fast and I am personally guaranteeing debt that I do not fully understand.” These are not practice areas. These are situations. And when someone is in one of these situations and they land on a website that describes it accurately, the response is immediate recognition: “This person understands my problem.” **Name what you actually do differently.** Every attorney says they are “experienced” and “client-focused.” Those words have lost all meaning. David needs to name the specific thing he does that his competitors do not. Maybe it is this: David reviews every client’s key contracts annually, not when a problem arises, but before one does. He calls it a legal health check (or whatever plain language fits). Most small business attorneys are reactive. They wait for the phone to ring. David is proactive. That is a real difference, and it is worth stating plainly. Or maybe it is this: David gives his ongoing clients his cell phone number. When they are about to sign something, about to fire someone, about to shake hands on a deal, they can call him before they commit, not after. That is different from how most attorneys operate, and it is enormously valuable to a business owner who has been burned by acting first and lawyering second. Whatever the specific differentiator is, it needs to be concrete and specific. Not “personalized service.” That means nothing. The specific thing that David’s best clients would describe if someone asked them why they stay with him. **Let the website reflect the offer, not the resume.** Once David knows his offer, the website almost rewrites itself. The homepage does not open with credentials. It opens with a description of the client’s problem: “Your business is growing. Your contracts were written when you were smaller. The risks have changed, and the paperwork has not caught up.” The services page does not list practice areas. It describes scenarios: “Before you sign that lease.” “Before you bring on a partner.” “Before that vendor contract auto-renews.” Each one links to a clear next step. The about page does not lead with “J.D. from…” It leads with why David started this practice: because he watched small business owners get hurt by legal problems they could have prevented, and he wanted to be the phone call before the mistake, not the cleanup after. This is not clever copywriting. It is clarity about who you serve and what you actually offer them. ## The Test How do you know if your offer is strong enough? There is a simple test. Show your website to someone who has never seen it, alongside two or three competitor sites. Ask them: “Based on what you see, why would you call this one instead of the others?” If they cannot answer the question, your offer is not visible yet. If they say “It seems more professional” or “The design is nicer,” those are weak signals. You want them to say something about the substance: “This one seems like they actually understand my situation” or “This one offers something the others don’t.” If you cannot pass that test, no amount of SEO, blog posts, testimonials, or chat widgets will solve the conversion problem. The same applies to [GEO](https://en.wikipedia.org/wiki/Generative_engine_optimization) (Generative Engine Optimization, which is the practice of structuring content so that AI systems like ChatGPT and Perplexity surface it in their answers). GEO can get your content cited by AI, but if the content says the same thing as everyone else, the citation does not help. You are optimizing a message that does not differentiate. ## Why This Matters Beyond the Website The offer problem does not live only on the website. It shows up in every conversation, every networking event, every referral request. When someone asks David what he does, he says “I’m a business attorney for small companies.” That is a category, not an offer. It invites the response, “Oh, I know someone who does that too.” If instead he says, “I work with growing businesses to find the legal risks they don’t see coming, before those risks become expensive problems,” that is different. It is specific. It describes a problem and a solution. It gives the listener something to remember and repeat. The website is just the most visible surface where the offer problem shows up. Fixing the offer fixes the website, the elevator pitch, the referral conversation, and the networking introduction all at once. They are all expressions of the same underlying question: what do you do for people that they cannot easily get somewhere else? ## Going Deeper The idea behind this, building an offer so compelling that a customer would feel foolish saying no, comes from a concept Eli Goldratt called the “mafia offer” in his Theory of Constraints methodology. Not because it involves coercion, but because it is an offer so clearly aligned with the customer’s real problem that refusing it would be irrational. The term is playful, but the method is rigorous: identify the customer’s core frustration, find the hidden conflict that the industry has accepted as normal, and design a solution that resolves it. At Common Sense Systems, we have built a structured process for helping businesses develop this kind of offer. It starts with understanding what your best clients actually value (which is rarely what your website currently says) and works through to an offer statement and a website that reflects it. If David’s situation sounds familiar and you want to explore what a stronger offer looks like for your business, reach me at [john@common-sense.com](mailto:john@common-sense.com). ## Sources - [en.wikipedia.org/wiki/Generative\_engine\_optimization](https://en.wikipedia.org/wiki/Generative_engine_optimization) - [Theory of Constraints (Wikipedia)](https://en.wikipedia.org/wiki/Theory_of_constraints) - [TOCICO](https://www.tocico.org/) - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [AHRQ patient safety culture resources](https://www.ahrq.gov/sops/index.html) Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Business Is Full But Something Is Missing | Common Sense Systems URL: https://common-sense.com/insights/when-your-business-is-full-but-something-is-missing/ [Insights](https://common-sense.com/insights/) # When Your Business Is Full But Something Is Missing By John Sambrook · March 4, 2026 · [Small Business](https://common-sense.com/insights/tag/small-business/), [Operations](https://common-sense.com/insights/tag/operations/) ## TL;DR A full schedule is not the same as a thriving practice. When every hour is booked but satisfaction is dropping, the problem is usually not capacity. It is that something in the business is consuming the resources (time, energy, attention) that should be going toward the work that matters most. Find that one thing, address it, and both the business and the practitioner get better. * * * ![Infographic showing the hidden conflict between revenue needs and meaning needs in a full practice, with the assumption that every hour must generate the same revenue, and a four-step path forward](https://common-sense.com/images/content/full-schedule-wrong-mix.webp) Lori is a licensed massage therapist, three years into running her own practice. She is good at what she does. Her schedule is full. She has a waitlist. By most measures, the business is working. But Lori is tired in a way that a long weekend does not fix. She is seeing twenty-five clients a week, and by Thursday afternoon her body hurts and her attention is somewhere else. She is spending her Sunday evenings doing bookkeeping, answering emails, and trying to post something on Instagram. She got into this work because she wanted to help people. Now she spends most of her energy managing a machine that does not leave room for the thing she actually cares about. She has thought about raising her prices. She has thought about hiring someone. She has thought about cutting back her hours. Each option feels like it solves one problem and creates another. Raise prices and she might lose the clients she likes most. Hire someone and now she is managing people instead of doing the work. Cut back hours and the income drops below what she needs. It feels like a trap. Grow or stay stuck, and neither option is what she wants. This feeling is not a personal failing. It is a structural problem, and it has a solution. ## The Conflict You Cannot See Most business advice for someone in Lori’s position is about tactics. Raise your rates. Niche down. Build passive income. Automate your booking. Some of that might help, but none of it addresses why she feels stuck. The tactics assume she knows what to fix. She does not. She just knows something is wrong. Here is what is actually going on. Lori has two things she needs, and they appear to be pulling in opposite directions. She needs the business to be financially sustainable. That means sufficient revenue, which currently means a full schedule. And she needs the work to be meaningful and sustainable for her body and her spirit. That means presence, depth, and energy for the clients who benefit most from what she does. The conflict: to keep the revenue up, she fills every slot. To keep the meaning up, she needs fewer, deeper sessions with more space around them. She cannot do both. Or at least that is how it feels. The reason it feels impossible is that there is a hidden assumption buried in the logic. The assumption is: every hour of her schedule has to generate roughly the same revenue in roughly the same way. One hour, one client, one fee. That assumption is so obvious it is invisible. And once she sees it, the conflict starts to dissolve. ## Finding the Real Constraint Lori’s constraint is not her schedule. Her schedule is full, yes, but full of what? When she actually looks at her client list, a pattern emerges. About a third of her clients are people she does her best work with. Complex cases, people who are committed to the process, people who come back consistently and refer others. These sessions energize her. They also tend to be the clients who would pay more for longer sessions, add-on services, or specialized work if she offered it. Another third are fine. Regular appointments, good people, straightforward work. They fill the schedule and pay the bills. The last third are draining. Last-minute bookings. People who cancel frequently. Sessions that feel transactional rather than therapeutic. They pay the same rate as everyone else, but they cost more in energy, no-show gaps, and the invisible tax of doing work that does not feel like her work. The constraint is not that Lori is out of hours. The constraint is that her best hours are being consumed by work that does not serve the business or the practitioner. She is at capacity, but it is the wrong capacity. The schedule is full, but it is full of the wrong mix. This is a different problem than “I need more clients” or “I need to charge more.” It is a problem of allocation. And it changes what the solution looks like. ## Working the Problem Once the real constraint is visible, the steps are practical. **Get the most out of what you have.** Before changing anything about the business model, Lori can look at her existing schedule and ask: what if the hours I already work were filled with more of the right clients and fewer of the wrong ones? She does not need more hours. She needs better use of the hours she has. This might mean gradually shifting her most draining clients toward other practitioners in the area (a referral, not a dismissal). It might mean changing her booking policies so that last-minute slots are not available to everyone. It might mean reserving her highest-energy time blocks (mornings, for most bodyworkers) for the clients and session types where she does her best work. None of this costs money. It costs attention and a few uncomfortable conversations. **Organize everything else around it.** Once Lori is protecting her best hours for her best work, the rest of the business should support that. Her marketing should attract the clients she wants more of, not just anyone who needs a massage. Her intake process should screen for fit. Her scheduling system should reflect her energy patterns, not just her availability. This is where the bookkeeping and Instagram and email pile becomes relevant. Those tasks are not the constraint, but they are consuming the limited recovery time that Lori needs between sessions. Delegating or batching administrative work (even a few hours a week of virtual assistant support) does not directly increase revenue, but it protects the constraint. It gives Lori the margin she needs to show up fully for the sessions that matter. **If needed, invest.** Only after the first two steps are working should Lori consider bigger changes. Maybe that means creating a premium service tier for her most engaged clients: longer sessions, specialized modalities, a treatment plan with follow-up. Maybe it means bringing on another practitioner to handle the general-schedule clients while Lori focuses on the work only she can do. Maybe it means raising rates, but specifically on the services where demand exceeds her available slots. Each of these investments makes sense only because the constraint is now clear. Without that clarity, raising prices is a guess. Hiring is a risk. A premium tier is a gimmick. With that clarity, each one is a targeted decision that supports the thing that actually matters. **When it works, find the next constraint.** If Lori successfully shifts her practice toward higher-value, higher-satisfaction work, the constraint will move. Maybe it becomes marketing (she needs a steady pipeline of the right kind of client). Maybe it becomes her own skill development (she wants to offer more specialized services). Maybe it becomes space (she needs a better treatment room for the premium work). Each new constraint is a sign of progress, not a new problem. It means the old limit has been broken and the system is ready to grow again. ## The Assumption That Changes Everything Go back to the conflict. Lori needed revenue (full schedule) and she needed meaning (fewer, deeper sessions). Those felt like opposites. The hidden assumption was that every hour had to work the same way: one client, one session, one fee. Once that assumption is visible, alternatives appear. A two-hour deep-tissue session with a committed client at a premium rate generates more revenue than two one-hour general sessions, and it costs less in energy. A monthly treatment plan with four sessions prepaid generates more predictable revenue than four separate bookings, and it builds the kind of client relationship that sustains the practitioner. The conflict was real, but it was not permanent. It was held in place by an assumption about how the business had to work. Challenge the assumption, and both needs can be met. This pattern shows up in every small business I have worked with over thirty years. The details change. The structure does not. There is always a conflict that feels unresolvable, and there is always at least one assumption holding it in place that, once surfaced, opens a path forward. ## What This Is Really About Lori did not get into massage therapy to run a business. She got into it because the work itself matters to her. The business is supposed to be the vehicle, not the destination. When the vehicle starts consuming all the fuel, something has gone wrong structurally. The answer is not to push harder or to lower your expectations. The answer is to find the one thing in the structure that is creating the problem and change it. That might be the client mix. It might be the pricing model. It might be the way administrative work eats into recovery time. It might be a policy or habit that made sense two years ago and does not anymore. Whatever it is, it is almost always one thing, and finding it changes more than you expect. If something in this resonated and you want to think through what it looks like for your specific practice, I am happy to have that conversation. Reach me at [john@common-sense.com](mailto:john@common-sense.com). ## Sources - [INCOSE Systems Engineering Handbook](https://www.incose.org/products-and-publications/se-handbook) - [Little’s Law](https://en.wikipedia.org/wiki/Little%27s_law) - [Critical Chain project management](https://en.wikipedia.org/wiki/Critical_chain_project_management) - [SBA business guide](https://www.sba.gov/business-guide) - [IRS small business and self-employed resources](https://www.irs.gov/businesses/small-businesses-self-employed) Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # The Meeting That Went Differently | Common Sense Systems URL: https://common-sense.com/insights/the-meeting-that-went-differently/ [Insights](https://common-sense.com/insights/) # The Meeting That Went Differently By John Sambrook · March 2, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Theory of Constraints](https://common-sense.com/insights/tag/theory-of-constraints/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Strategy](https://common-sense.com/insights/tag/strategy/) ## TL;DR Last week I argued that a community hospital board meeting I attended could not have gone differently — that the outcome was structurally determined before anyone sat down. Readers asked the obvious follow-up. This is my answer: a 56-minute audio drama showing what the meeting looks like when something new enters the room. * * * ![A hospital board meeting room at evening session — commissioners at a curved wooden dais, a full audience, and at the far end of the dais an empty position holding a sleek terminal and a slender amber indicator light](https://common-sense.com/images/content/the-meeting-that-went-differently.webp) Last week I published a piece called [“The Meeting That Could Not Have Gone Differently.”](https://common-sense.com/insights/the-meeting-that-could-not-have-gone-differently/) The argument, briefly: I sat in on a community hospital board meeting where three clinical departments each presented compelling cases for more physical space. A cath lab. More operating rooms. An endoscopy suite. Between nineteen and twenty-nine million dollars in combined capital requests. The board received the presentations, asked a few good questions, and the conversation stayed on space. Nobody was dishonest. Nobody had a hidden agenda. The outcome was baked into the structure of the meeting before anyone sat down. The piece ended with a question I could not quite answer. If an AI could represent the community interest in that room — hold institutional memory, surface utilization data in real time, ask the question nobody else was positioned to ask — what would that actually look like? Several readers pushed on exactly that. It is a fair challenge. I had described the problem without showing an alternative. This is my attempt at one. ## The dramatization Working with Claude, I wrote a 56-minute audio drama. The setting is a fictional community hospital district in Washington State — Cascade Valley Health System. The board is fictional. The staff is fictional. The dynamics are real. The episode follows a full board meeting, from call to order to adjournment. Three departments present their cases. A commissioner asks the utilization question. And at the end of the dais, in the position where a retired commissioner used to sit, a small amber light clicks on for the first time. ## The meeting The three departments are familiar types if you work in or around hospitals. Cardiology is doing well: volume up nine percent year over year, a third interventional cardiologist added eighteen months ago, door-to-balloon times in the top quartile nationally. Their request: a third cath lab, eight to twelve million dollars. Musculoskeletal is the fastest-growing service line in the system — highest contribution margin, driven by joint replacements and a growing sports medicine practice. Their constraint is OR time. Their request: two additional operating rooms. Gastroenterology is booking routine screening colonoscopies six to eight weeks out, against a national recommendation of four weeks. Their request: a new endoscopy suite, three to five million. Each presentation is solid. Each makes a defensible case within its own frame. And each arrives at the same conclusion — we need more space — as if independently, which in a sense they are. Commissioner Chen is the one who asks the question that shifts the room. She is a physician herself, data-driven, and she has been taking notes through all three presentations. When Chairman Hadley opens the floor for questions cutting across all three departments, she asks: when we say these spaces are at capacity, we mean they are at capacity during roughly forty hours out of a hundred and sixty-eight in a week. What does the full picture look like? Evenings. Weekends. Not just peak hours. It is exactly the right question. In a conventional meeting, the answer comes back as a polite explanation of why things are the way they are, and the conversation moves on. This is where the amber light clicks on. ## When Sam speaks Sam is the AI at the end of the dais. Calm, precise, no ego. Sam has been given access to the scheduling data across the system as part of the pilot. The number Sam puts on the table: across all procedure spaces at Cascade Valley — cath labs, operating rooms, endoscopy suites, interventional imaging — average weekly utilization is approximately twenty-three percent. During the Monday-through-Friday, seven-to-three window, utilization runs close to eighty-five percent. But across the full week, twenty-three. The murmur that moves through the room is quiet. Just thirty people absorbing a number they have not heard stated plainly before. Sam is careful about what the number means and what it does not. Running elective cases at two in the morning is not a realistic option. The practical opportunity is smaller than the raw figure suggests. But weekday evenings and Saturdays are a different matter — and that unused time, spread across all the procedure spaces in the system, represents a substantial amount of capacity that currently sits dark. Dr. Stanton pushes back immediately: you cannot run these rooms without staff, and the staffing challenge is not trivial. Sam agrees, directly and without defensiveness. That is precisely the point. A staffing and scheduling problem is a different kind of problem than a space problem. It may be solvable in months rather than years, at a fraction of the cost of new construction. Sam is not saying it is easy. Sam is saying it deserves serious analysis before the board commits to the capital-intensive path. Barbara Fleming, the Chief Nursing Officer, has her arms crossed through much of this exchange. When she gets the floor, she says what everyone in her position is thinking: she has seen too many optimization exercises that model schedules on a spreadsheet without ever talking to the nurses who would actually live with the changes. If the answer to this problem is to ask already-stretched staff to work more hours, that is not a solution. It is a different kind of failure. Sam’s response is direct. A good solution creates no significant negative consequences for any stakeholder. No losers. If the analysis cannot find a path that works for the nursing staff, for the physicians, for the patients, and for the district financially, it should not be pursued. The Chief Nursing Officer would be a full participant in the working group — not as a courtesy, but as a requirement. Fleming’s reply: “I appreciate that, Sam. I will hold you to it.” Sam: “Please do, Ms. Fleming.” Commissioner Tanaka, the engineer on the board, is the one who cuts through the procedural debate near the end. Commissioner Marsh has raised the legitimate concern that a six-week analysis will delay capital planning already in motion. Tanaka’s response is brief: “Sam is not asking us to stop. He is asking us to also look. Those are different things.” The board votes seven to zero to commission a parallel constraint analysis. All existing capital planning activities continue on their current schedule. Sam will be an analytical participant in the working group — not as a courtesy, either. ## The fiction and the fact The hospital is invented. The commissioners are composites. Sam is a device for making a structural argument visible. The governance dynamics are documented. Co-optation — the process by which oversight boards gradually come to see the world through the eyes of the institutions they are supposed to oversee — was first described by the sociologist Philip Selznick in 1949. Not because people are corrupt, but because the ordinary mechanics of working relationships between part-time commissioners and full-time executives produce a predictable drift. The board’s function can shift, subtly, from aggressive community advocacy toward smooth governance. Capital requests get approved because trusted, competent people say they are needed, and the board may not have independent analytical capacity to test those claims rigorously. The utilization pattern — high-cost procedure spaces sitting idle outside business hours while departments request new construction — is not unusual. The analytical capability Sam demonstrates in the script largely exists today. The harder question, which the drama deliberately leaves open, is whether the people who run our institutions are willing to invite this kind of participant to the table. A persistent voice with no career to protect, no turf to defend, and no reason to pull its punches. The political and social obstacles are real, and they are harder than the technical ones. I have no tidy answer to that. ## How this was made The script was written collaboratively with Claude — I provided the scenario, the characters, the argument structure, and the specific dynamics I wanted to portray; Claude shaped it into dialogue. We went through several revisions. The image above and the audio production are similarly AI-assisted. I am not hiding that. This is what the work looks like now, and I think it is worth being transparent about it. If you work in hospital governance or healthcare operations, and this story resonated with you — or provoked you, or struck you as naive — I would welcome the conversation. You can reach me at [john@common-sense.com](mailto:john@common-sense.com). ## Sources - [youtube.com/embed/h7vTTs2Hffo](https://www.youtube.com/embed/h7vTTs2Hffo) - [Theory of Constraints (Wikipedia)](https://en.wikipedia.org/wiki/Theory_of_constraints) - [TOCICO](https://www.tocico.org/) - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [AHRQ patient safety culture resources](https://www.ahrq.gov/sops/index.html) Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # I Hired Claude As My Social Media Producer | CSSI Kirkland, WA | Common Sense Systems URL: https://common-sense.com/insights/ai-social-media-workflow/ [Insights](https://common-sense.com/insights/) # I Published a Blog Post and Shared It on Social Media Without Opening a Browser By John Sambrook · February 27, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) ## TL;DR I have a working process that takes me from a rough idea in the evening to a published blog post with an original infographic, shared on LinkedIn and X, by the next afternoon. The tools are Claude, Nano Banana Pro, and the retired publisher. The hard part was getting it all set up and connected. I can help you do the same. * * * ![Infographic showing the 5-step workflow from idea to social media: rough out the idea with Claude, write the post with Claude Code, generate an infographic with Nano Banana Pro, publish to website via git push, and share on social media with the retired publisher — all connected by MCP](https://common-sense.com/images/content/blog-to-social-media-workflow.webp) Yesterday I published [a piece about hospital governance](https://common-sense.com/insights/the-meeting-that-could-not-have-gone-differently/) on my website. It included an original infographic. Within minutes of the article going live, it was posted to my LinkedIn and X feeds. I did not open LinkedIn. I did not open X. I did not open a graphics editor. I did not manually copy and paste anything. The whole process, from rough idea to live on the web and shared on social media, took me about two hours of actual work spread across an evening and the following morning. I’m 66. I’ve been writing software for over thirty years. But the thing I want to be clear about is that the workflow I’m going to describe does not require a software background. The tools have gotten simple enough that if you can have a conversation, you can do this. The hard part is getting everything set up the first time, and that’s where I come in. ## What the process actually looks like It starts in the evening. I’m thinking about my day, about where I want to invest time and effort to move my business forward. I sit down with Claude — Anthropic’s AI assistant — and we rough out the article concept together. I show it my brand guidelines. We discuss structure, tone, what the piece needs to say. Claude is good at pushing back when I’m being too abstract, which happens more than I’d like to admit. By the end of that conversation, I have an outline or a rough draft. Not finished prose, but the bones of something real, grounded in my actual experience and opinions. The next morning, I sit down at my computer and start working with Claude Code, a developer tool that can read and write files, run commands, and interact with other services. I give it the outline from the night before and my brand guidelines, and I ask it to write the blog post. We go back and forth. It drafts, I react, it revises. This is collaborative writing, not “generate a blog post about X.” The raw material — the observations, the arguments, the specific examples — that all comes from me. Claude shapes it into something publishable. Once the article is solid, I ask Claude Code to generate an infographic using [Nano Banana Pro](https://blog.google/innovation-and-ai/products/nano-banana-pro/), Google’s AI image generation model. NBP is remarkably good at creating infographics with legible text, clear layouts, and accurate content. The infographic goes at the top of the article, right after the summary. Claude Code handles the whole interaction through what’s called an MCP server — a protocol that lets AI tools talk to each other without me having to switch between apps. Then I commit the article, push it to my website’s repository, and the site rebuilds automatically. The article is live. Now comes the part that surprised me. I ask Claude Code to post the article to LinkedIn and X using \[the retired publisher\](the retired publisher site), a social media management platform that also connects through an MCP server. Claude Code crafts an appropriate post for each platform and publishes it. I don’t open LinkedIn. I don’t open X. I don’t fiddle with image sizes or character counts. The whole thing flows. Idea to published article to social media, with an original infographic, in a single working session. ## What’s actually doing what Three tools, each with a clear role: **Claude** (the AI assistant) does the thinking and writing. In the evening, I use the conversational interface to develop ideas. The next day, Claude Code handles the file creation, the back-and-forth editing, and the orchestration of the other tools. **Nano Banana Pro** generates the infographic. It’s Google’s image generation model, built on their Gemini technology. It’s the best tool I’ve found for creating infographics that actually have readable text and sensible layouts. It connects to Claude Code through an MCP server, which means Claude can request an image, review the result, ask for corrections, and insert it into the article without me touching a graphics application. **the retired publisher** handles social media publishing. It connects to LinkedIn, X, Instagram, Facebook, and other platforms. Through its MCP server, Claude Code can compose and publish posts directly. the retired publisher starts at $29/month and includes API access, which is what makes the automation possible. The key word in all of this is MCP — Model Context Protocol. It’s a standard that lets AI tools communicate with external services. I don’t have to copy text between apps, export images from one tool to import into another, or log into social media accounts to post. The tools talk to each other. ## Who this is for I did not write this for software engineers. They’ll figure this out on their own. I wrote this for the real estate professional who has a website built three years ago that hasn’t been touched since. For the solo bookkeeper who knows she should be posting on LinkedIn but can never find the time. For the business owner who’s thinking that maybe this AI thing could help, but doesn’t know where to start and doesn’t want to waste money finding out. I also wrote it for the business owner who’s thinking about their staff, or their kids, and wondering whether this is something the next generation should know how to do. It is. Here’s what I’ve noticed: once people get through the initial setup and do this a few times, they find a million other uses for the technology. Updating their website and posting to social media is just the gateway. They start using Claude for drafting emails, analyzing documents, preparing for meetings. The tool becomes a general-purpose business assistant. The barrier is not ability. The barrier is that first hour of setup, and having someone patient enough to walk you through it. ## What I’m offering I’ve been working full-time with AI tools since January 2025. I’ve built this workflow through months of daily use, through plenty of dead ends and configuration headaches that I can now spare you. Here’s how I work with people: **A free 30-minute conversation.** We talk about your business, your current online presence, and whether this approach is a good fit for you. No charge, no obligation. Some people are better served by other solutions, and I’ll tell you that honestly. **Two hands-on setup sessions.** If we decide to work together, I sit with you for two sessions of three to four hours each. By the end, you will have Claude set up on your computer, your social media accounts connected through the retired publisher, and a working process you can repeat on your own. The cost is $1,200 for both sessions. If we try and it doesn’t work out, or if either of us decides partway through that this isn’t the right fit, there is no charge. I qualify people carefully up front so this rarely happens, but the guarantee is real. **Ongoing support if you want it.** Some people are fully independent after the setup sessions. Others want someone to call when they get stuck. I’m available at $150 per hour for ongoing support, billed for actual time used. I want to see people succeed with this technology. It’s too useful to remain the exclusive province of software engineers. If this sounds like something that could work for you, or for someone you know, reach out. I’m happy to have the conversation. You can reach me at [john@common-sense.com](mailto:john@common-sense.com). ## Sources - [blog.google/innovation-and-ai/products/nano-banana-pro/](https://blog.google/innovation-and-ai/products/nano-banana-pro/) - \[scheduler.com/\](the retired publisher site) - [Theory of Constraints (Wikipedia)](https://en.wikipedia.org/wiki/Theory_of_constraints) - [TOCICO](https://www.tocico.org/) - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # The Meeting Could Not Have Gone Differently | CSSI, Kirkland, WA | Common Sense Systems URL: https://common-sense.com/insights/the-meeting-that-could-not-have-gone-differently/ [Insights](https://common-sense.com/insights/) # The Meeting That Could Not Have Gone Differently By John Sambrook · February 26, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Healthcare](https://common-sense.com/insights/tag/healthcare/), [Strategy](https://common-sense.com/insights/tag/strategy/), [Leadership](https://common-sense.com/insights/tag/leadership/) ## TL;DR Hospital governance suffers from a structural problem called co-optation: oversight boards gradually adopt the institutional perspective of the organizations they govern. This happens to good people doing their best. The usual remedies don’t work because the cause is structural, not personal. AI may offer something new — a persistent, dispassionate voice representing the community interest that currently has no advocate in the room. * * * ![Infographic showing the co-optation cycle in hospital governance: community elects part-time commissioners, commissioners depend on executives for information, departments advocate for more resources, board optimizes for smooth governance, and community interest loses its voice — with AI as the missing counterweight](https://common-sense.com/images/content/hospital-governance-cooptation-cycle.webp) I sat in a community hospital board meeting recently and watched three clinical departments present their growth strategies to the commissioners. Cardiology. Musculoskeletal. Gastroenterology. Each department had done its homework. Each had data. Each had a clear message for the board: we need more space. One commissioner, a physician himself, asked a sharp question. He wanted to know about utilization — specifically, how much the existing cath lab was actually being used. The answer was revealing. The cath lab sits empty most evenings, most of Saturday, and all of Sunday. A multimillion-dollar clinical space, dark for roughly three-quarters of every week. The meeting moved on. The conversation stayed on space. Nobody in that room was being dishonest. Nobody had a hidden agenda. Three departments genuinely believed that space was their binding constraint, and the commissioners genuinely wanted to support clinical growth. Everyone was acting in good faith. And yet the conversation that needed to happen — about staffing models, scheduling patterns, and the actual utilization of existing capacity — never quite materialized. I left the meeting thinking: it could not have gone differently. Not with these people, who are among the most civic-minded and responsible I’ve encountered. Not with this structure. The outcome was baked in before anyone sat down. ## What happened is not a mystery There is an old and well-documented dynamic in governance called co-optation. The sociologist Philip Selznick identified it in 1949 while studying the Tennessee Valley Authority.[1](#user-content-fn-1) He observed that when governing boards depend on the cooperation of powerful groups, those groups gradually get absorbed into the decision-making process. The board’s independence erodes — not through corruption, not through bad faith, but through the ordinary mechanics of working relationships. Selznick defined co-optation as “the process of absorbing new elements into the leadership or policy-determining structure of an organization as a means of averting threats to its stability or existence.”[2](#user-content-fn-2) In a community hospital, the mechanics look like this. Commissioners are part-time, often volunteer or modestly compensated, elected by a community that mostly does not pay attention to hospital governance. They depend on executives for information. They depend on physicians for clinical judgment. They depend on nurses and staff for the institution to function at all. The information asymmetry is massive — a classic principal-agent problem,[3](#user-content-fn-3) where the community (the principal) delegates authority to commissioners (agents), who in turn depend on executives and physicians (sub-agents). At each layer, the agent’s interests can drift from the principal’s. When a cardiologist says the department needs more space, most commissioners lack the independent analytical capability to challenge the claim. Over time — and this is Selznick’s key insight — the commissioners optimize for smooth governance rather than aggressive community advocacy. They approve capital projects, staffing expansions, and compensation packages because the people they trust and work with closely tell them these things are necessary. And individually, each decision might be defensible. It is the cumulative drift that costs the community. None of this is a story about bad people. The commissioners I’ve observed are dedicated, thoughtful, and genuinely trying to serve the public interest. The executives are competent and mission-driven. The physicians care about their patients. The nurses are stretched thin and doing remarkable work. Every person in that room is doing their best within a structure that produces a predictable result. And it isn’t limited to the boardroom. I’ve done analytical work on collective bargaining agreements between Washington State hospitals and the nurses’ union, and found the same structural pattern in a different form. Every single agreement contained embedded conflicts — situations where the contract itself places people in impossible positions. Scheduling flexibility vs. income security. Operational needs vs. contractual protections. Management and labor locked in a relationship that neither side would design from scratch but neither side can unilaterally change. As someone who has lived a long life, I know that I would not want to be in a long-term relationship with people who didn’t want the best for me or who were constantly antagonistic. That is how I read the management-nursing union dynamic at many hospitals: not as a story of bad actors, but as a system design problem. If it were solvable within the current structure, it would have been solved sometime in the last fifty years. ## Goldratt’s principle My mentor, Eli Goldratt, the creator of Theory of Constraints, drilled one idea into everyone he taught: the problems you find will be system conflicts, not the result of bad people.[4](#user-content-fn-4) If the system produces an undesirable outcome reliably, the answer is in the system’s design, not in replacing the people who operate it. This applies directly. If every community hospital board in the country exhibits some version of the same drift toward institutional consensus — and the governance literature suggests they do — then the problem is not that we have the wrong commissioners. The problem is that the structure lacks a counterweight. Think about what’s missing. The community’s interest in fiscal discipline, in rigorous scrutiny of capital spending, in questioning whether existing resources are fully utilized before approving new ones — that interest has no persistent voice in the room. Taxpayers don’t attend board meetings. They don’t have the expertise to challenge clinical claims even if they did. The people who do show up, who do have expertise, and who do have a persistent voice are staff, physicians, and their advocates. All of them, quite naturally, argue for more resources. The usual remedies are weak. Term limits for commissioners replace captured people with naive ones who will be captured in turn. Outside consultants are expensive and episodic. Investigative journalism at the local level has largely disappeared. Community attendance at board meetings is close to zero. None of these address the structural gap. ## A different kind of AI question Most of the conversation about AI in healthcare right now is about tools for existing power groups. AI scribes for physicians. AI scheduling for administrators. AI documentation for nurses. These are useful. They are also extensions of the current structure — making each group more efficient within the system as it already operates. I’ve been wondering about a different question. What if AI’s most important role in governance isn’t serving the institution, but representing the people the institution is supposed to serve? Imagine an AI participant in that board meeting — not as a tool for the CEO’s office, but as an analytical voice for the community interest. It could hold institutional memory across years of meetings, tracking whether past justifications for spending actually materialized as promised. It could cross-reference utilization data in real time when departments claim they need more capacity. It could ask the question nobody wants to ask: “The cath lab is empty 75% of the week. Can we talk about that before we talk about building more space?” Such a system would not be subject to the social pressures that drive co-optation. It would have no interest in maintaining comfortable relationships with the CEO. It would not defer to a cardiologist’s authority on matters of scheduling and utilization. It would not unconsciously converge on the answer that keeps everyone happy. I want to be careful here. I’m saying “could,” not “will.” The technical capability is arguably close to existing today. The political problem is harder: such a system would need to be sanctioned by the very groups whose claims it would challenge. That is a real obstacle. And AI brings its own risks — overconfidence in data, inability to read a room, potential for mechanistic thinking in situations that require judgment. But the current situation is not working well enough. Good people, acting in good faith, reliably producing outcomes that don’t serve the community as well as they should. That is a system problem. And system problems call for structural solutions. I don’t have a complete answer. I do have an interest in experimenting with this idea — building analytical tools that could give commissioners an independent basis for evaluating the claims made to them. Not replacing human judgment, but informing it with the kind of persistent, dispassionate analysis that no part-time volunteer board member can sustain on their own. I could be wrong about this. I welcome the pushback as much as the agreement. If you’re involved in hospital governance, public or private, and this matches or contradicts what you see, I’d like to hear about it. You can reach me at [john@common-sense.com](mailto:john@common-sense.com). * * * ## Sources - [Selznick (1949): TVA and the Grass Roots](https://www.jstor.org/stable/2086756) - [Principal-agent problem (overview)](https://en.wikipedia.org/wiki/Principal%E2%80%93agent_problem) - [Theory of Constraints in healthcare: systematic review](https://pmc.ncbi.nlm.nih.gov/articles/PMC8812771/) - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [OECD AI Principles](https://oecd.ai/en/ai-principles) ## Footnotes 1. Philip Selznick, _TVA and the Grass Roots: A Study in the Sociology of Formal Organization_ (Berkeley: University of California Press, 1949). [↩](#user-content-fnref-1) 2. Selznick’s definition as cited in the _Oxford Dictionary of Sociology_ and subsequent scholarship. For a recent retrospective, see Michael Hibbard and Kathryn Frank, “TVA and the Grass Roots at 75: The Legacy of a Planning Classic,” _Journal of Planning Education and Research_ (2024). [↩](#user-content-fnref-2) 3. For principal-agent dynamics in healthcare governance specifically, see Derick Brinkerhoff and Thomas Bossert, “Health Governance: Principal-Agent Linkages and Health System Strengthening,” _Health Policy and Planning_ 29, no. 6 (2014): 685-93. [↩](#user-content-fnref-3) 4. Eliyahu M. Goldratt, _It’s Not Luck_ (Great Barrington, MA: North River Press, 1994). The principle recurs throughout Goldratt’s body of work, particularly in his framing of Evaporating Clouds as tools for resolving system conflicts without compromise. [↩](#user-content-fnref-4) Want to talk about your own bottleneck? The first hour is free, and you get a written proposal. [Book a free consult](https://common-sense.com/book/) --- # Connect Google Business Profile to Structured Data | Common Sense Systems URL: https://common-sense.com/insights/connecting-google-business-profile-to-your-structured-data/ [Insights](https://common-sense.com/insights/) # Your Google Business Profile Is Floating in Space By John Sambrook · February 25, 2026 · [AI](https://common-sense.com/insights/tag/ai/), [Small Business](https://common-sense.com/insights/tag/small-business/), [Practical Tips](https://common-sense.com/insights/tag/practical-tips/) ## TL;DR Your Google Business Profile is one of the strongest verification signals Google controls about your physical existence. If your website’s structured data doesn’t reference it, AI systems and search engines have to guess whether your site and your profile describe the same entity. Connecting them takes about two hours and strengthens both AI visibility and traditional local SEO. * * * Most small business websites and their Google Business Profiles exist as unconnected islands. By linking them through structured data — adding your profile to the `sameAs` array, matching your address exactly, and building an entity graph with `@id` references — you give both AI search engines and traditional Google the corroboration they need to confidently identify and recommend your business. ![Infographic showing the 6-step process for connecting your Google Business Profile to your website structured data: find your CID, add GBP link to footer, add GBP URL to sameAs in JSON-LD, add geo coordinates and hasMap, match address exactly for NAP consistency, and add profile URL to llms.txt](https://common-sense.com/images/content/connect-website-to-your-gbp.webp) Last week I ran a GEO audit on my business website. GEO stands for Generative Engine Optimization — it’s the emerging discipline of making your site legible to AI search engines like ChatGPT, Perplexity, and Google’s AI Overviews. The audit turned up a problem I hadn’t thought about: my Google Business Profile existed, and my website existed, but nothing connected the two. They were floating independently, like two documents in different filing cabinets that happened to describe the same company. That matters more than I expected. Your Google Business Profile is one of the few things Google treats as verified ground truth about your physical existence. If your website’s structured data doesn’t reference it, you’re leaving your strongest verification signal unconnected. ## The Problem in Plain Language When Google or an AI system tries to understand who “Common Sense Systems” is, it looks for corroborating evidence across multiple sources. My website says I’m a consulting firm in Kirkland, Washington. My Google Business Profile says the same thing. My LinkedIn company page says it too. But unless I explicitly tell the machines these are all the same entity, they have to guess. And guessing is where things go wrong — especially when another organization called “Common Sense Media” dominates every search query that starts with “Common Sense.” The technical name for this is [entity disambiguation](https://en.wikipedia.org/wiki/Entity_linking). Search engines and AI models need to distinguish between entities that share similar names. The way you help them is by creating explicit links between your various online presences. The more links, the clearer the signal: yes, this website, this business profile, this LinkedIn page, and this BBB listing all describe the same organization. ## What “Structured Data” Actually Is Before I walk through what I did, a note on terminology. You’ll hear people say “JSON-LD” and “structured data” and “schema markup” as if they’re interchangeable. They’re not, but they’re related. **[Schema.org](https://schema.org/)** is a vocabulary — a dictionary of terms that describe things like organizations, people, articles, and services. Google, Bing, and AI systems all understand it. **[JSON-LD](https://json-ld.org/)** is a format — the container you put those terms in. It lives in a `