That Arrow Left the Bow.

Now you have to question the record.

By Bill Dunning · Part 4 of a five-part series

Not long ago I was handed a ticket on a client project. It was about tracing a phone call that wasn't handled correctly, but showed no error.

Our part of the system is adjacent to the call, not in it. It listens to what one system reports, and then it writes some of it onto a CRM's records afterward. It had no part in the problem. It had the answer anyway, because of a decision made months earlier.

When we built it, we didn't know which fields the systems would need. So the first version recorded everything: the whole record at every event, not just the fields we used, written to disk as it came in and tagged with where it came from.

The answer was in fields our code never reads or writes. One platform's record said somebody picked up almost immediately and talked for several minutes. The other platform's record of the same call said nobody had answered at all.

Two records of one phone call, and they disagreed about whether anybody picked up.

The record of what happened was taken at the moment, before anybody knew what the question would be, and it was still there when the question came. That's the whole trick: like I've said before, make it show its work at the moment it happens.

What the log didn't keep

The same investigation turned up a question we couldn't answer.

When one of our writes succeeded, it kept everything. When one failed, it left only a line in the server log.

I know exactly what would have answered that. I could write the change in an hour, and it would have told me why writes fail from now on. It can't tell me why they failed then, and there's no going back to add it.

It's a common thing – the intermittent failure. The bug that wouldn't reproduce, and the logging that wasn't there the one time it happened. So you add the logging and wait for it to happen again. Usually it does.

The third inference

It's been true for a long time. If the code runs, someone competent wrote it. If the business operates, someone knew how. If the recording exists, the event happened. All three measures have broken all at once. We're looking at the last one – the recording of what happened.

A recording is a record of a moment. It arrives after the moment is over. Whatever you do with it, you do after the fact. Video, audio, logs: it's all the same.

For a long time that didn't matter, because faking a convincing video or audio was harder than making a real one, for example. And the difficulty made it a small probability that it was fake. That difficulty is gone.¹

We assume that what we have in our hands is what it claims to be. What was never questioned is now very important. Before you can judge something, you have to know it's real. Skip that and you could easily be judging a lie.

And whether a recording is real is a question you can only ask after the arrow has left the bow.

Forensics

So we examine the recording. We look for the hallmarks of an AI-generated artifact: a strange line, a shadow in the wrong direction, a voice that doesn't breathe where a person would. That's detection. It catches things.

But look at the position it puts you in. It's the one I was in. The moment has passed, the note that would have answered the question wasn't kept, and all you can do is reason from what survived. That's forensics. At its best it gets you more than a hunch but less than evidence.

Where it runs out

Everything so far has run out of something. Time: the discipline takes longer, and most people don't control their own schedule. Standing: the person who asks pays for it, and the company collects. This one runs out of second chances.

Everything I know how to do about this, I learned on code, and all of it happens before the fail. Keep the whole record, before you know which part matters. Write it down as it comes in. Stamp it with where it came from. Each of those is a decision made in advance, by somebody who expected to have a question later and didn't know yet what it would be.

A log or a video or audio recording reaches you with every one of those decisions already made, by somebody else, at a moment that is now gone. Mostly they were made by nobody. What's done is done. You can't go back and add the logging. You can't wait for something to fail again, because it won't. The recording only happens once.

So you do what I did. You reason from what survived. You get more than a hunch and less than evidence. And you decide anyway.

Where this goes

Unlike when I was working with an AI tool that had the right answer the whole time and was only waiting to be asked, the common belief is that there are questions about recordings that nobody can answer, no matter who asks or how well, because the only time they could have been answered has already gone by.

There's a way around that. That's the last part.

---

¹ Adam Monago got to this before I did. In March he wrote that AI didn't make expertise cheap so much as the evidence of it, which is very close to the sentence this series started on.

A note on how this was written. As with parts 1 through 3: the ideas, the anecdotes, and every judgment call about what belongs on the page are mine; the production leverage is the machine's. The full note is at the end of part 1, and it still applies — with the added observation that the only reason I can tell you which parts were mine is that somebody wrote it down at the time.

Bill Dunning is the founder of 416 Inc (dba Indggo), where he leads development of Edge Mesh Protocol — verification infrastructure for real-time media. Part 5 is the last one, and it goes back to something that was in front of us the whole time. The canonical version of this series lives at forum.indggo.com.

---

The Hidden Blast Radius

When the company itself is the non-expert expert.

By Bill Dunning · Part 3 of a five-part series

A few weeks ago I sat down with a small company to talk about working together. Somewhere in the conversation the man across from me told me, with some pride, that he had built one of their core business applications himself. Built it with an AI tool over a few weeks. He is in senior leadership, not a developer.

The business now depends on it every day, but who was there to approve it, let alone notice that it was even there?

I asked how he decided to build it rather than buy it or hire for it, and his answer sounded like me. He could do it himself, and probably faster than he could hire a team.

He was right. That's the part I keep coming back to.

He also enjoyed it, and that came through in his face. Not the speed, it was the building. Somewhere in there was a man who liked the idea of building something, and who had found a tool that made it possible.

This is not a story about a man who had no business writing software. The application works. He liked doing it. Probably learned a few things too.

Here's what's different when you sit in an organization that's more than just you. When he decided, an organization acquired a dependency.

Nobody reviews personal work

A company is an institution before anything else. Standards, approvals, compliance, separation of duties, a purchasing process, a security review, somebody whose signature is required before things happen. Most of that machinery exists for one purpose — to protect the company. When the company acquires something, the acquisition goes through a process.

When a person inside the company makes something, it doesn't. Nobody reviews your memo. Nobody signs off on the training guide you wrote for your new assistant, or the spreadsheet you built to keep the schedule straight. There is no review of personal work product and there never has been.

That was not an oversight. It was correct. If your spreadsheet is wrong, you fix your spreadsheet. The blast radius of a mistake in something you made for yourself was always small enough that reviewing it would have cost more than it saved.

A modern company will tell you it has this covered — shadow IT policy, SaaS discovery, SSO governance, somebody who watches for unsanctioned tools. All of it is real, and all of it fires on an acquisition event. Something gets bought, connected, licensed, requested. No event, no trigger. The policy is not weak. It is simply never called.

Part 1 of this series spent a while in 1987, when the LaserWriter and PageMaker put the tools of a profession in the hands of anyone with a Macintosh, and everyone with a Macintosh instantly concluded they were a great designer. The output was terrible but it was honest. The amateur's newsletter looked amateur, and the worst thing that happened was an ugly newsletter.

A few years after that I was a supervisor in city government, over one of five divisions in a department. I wanted a way to track ticket sales, and rather than use the systems we had, I built one. The same wave that put page layout on a desk had put a database there too. I was the guy who liked building it, and I was the guy who was proud that I could.

What it produced went into budgeting and P&L for that program. Not a large program. It was one service in a department full of bigger ones. But a real number in a real budget, coming out of something I made.

We had an MIS department, and they would have stopped it if they had known. They never knew. A review fires when the organization acquires something, and the organization hadn't acquired anything, or so it thought.

It did not survive me. If it had, it would have been unmaintainable — which is the other way these end, and I suspect the more common one.

Somebody is going to say this is shadow IT and we have had it since Lotus 1-2-3. Fair. Here is what I think is different now. My database was bad, but it was legible. Anybody who opened it could read what it did, because I had to hold all of it in my head to build it in the first place. There was no other way it could have gotten built. The thing that arrives today comes with no such guarantee. It can be larger than what the person who made it ever held at one time. Shadow IT you could reverse engineer. This you may not be able to, and the man whose name is on it may be no better positioned to do it than you are.

Here is the 2026 version. The tools of a trained profession are in everyone's hands again. What they produce now is not a newsletter. It is a working business system. And it goes in the same place the newsletter went, which is straight into use, past no review at all, because it is personal work product, and personal work product has never needed one.

The blast radius moved. The review didn't.

The moment

There is a moment in this that nobody owns.

It is the moment a thing somebody made becomes a thing the business depends on. It has no ceremony. No purchase, no contract, no signature, no renewal date that forces somebody to look at it once a year whether they want to or not. Nothing to inventory and nobody to call. The dependency accumulated instead of arriving.

The login

There is a login, though, and that one is worth thinking about.

Personal work gets built on personal credentials. Somebody authenticates a plug-in or a service with the account they already have, because it's the account they already have, and the thing works fine. Then they leave. IT terminates the account, and something the business runs on stops working. Nobody can say why, because nobody knew it was there.

Every control in the building worked exactly as designed that morning. Offboarding ran. The account was closed on schedule. A company doing everything right takes itself down, because the one thing it never had was a record that the connection existed.

I wrote a piece a while back about what happens when the AI vendor you depend on disappears. This is the same failure through a smaller door. The vendor is the business and it is still here. What disappeared was a connection nobody had written down.

Nowhere to put the question

Part 2 of the series ended with one question for telling an expert from a non-expert expert now that the output can't: what did you demand before you accepted this?

You don't ask that of a company. You ask it of a person, and that is where this comes apart. Ask it about the application and in this case, there is nowhere to put the question. The only person who could be asked is the person who built it, and they are the same person who accepted it. There was never a second party to it, so there was never a moment shaped like acceptance.

Look at where he was when he made the call. He was the buyer, the builder, and the reviewer. He decided the company needed it, he built it, and he decided it was good. Each of those is a real role, and organizations keep them in separate hands on purpose — that separation is most of the control a company actually has.

I don't think he decided to collapse it. Nobody weighs a barrier and then removes it. The barrier just didn't look like much. It's a review. It's a step. It's the kind of thing you'd get around to, and the tool in his hand was capable enough that the project never felt big enough to bother.

You can build a cart with three wheels. It rolls. It carries a load. It will do that for a good long while, and you will not learn what the fourth wheel was for until somebody takes it sideways down a hill.

Here's the kicker. I was in the room with the test in my hands and didn't use it. Not because I lost my nerve, but because I wasn't interrogating his application. I was determining what his needs were. That is the job of very nearly every conversation in which the question could come up.

The question — the test — has no owner.

The other room

Different company. I'm there as an outside partner. Their development lead mentions that the AI coding assistant built into their CRM platform has stopped working. He'd been using it, in his words, as a junior developer to handle the tedious parts. The fallback is the browser version, which is clunky, and which nobody had ever run against a deadline. You find out what a fallback is worth on the day you need it, and by then it is too late to find out.

Their project manager asked the right question immediately. What does this do to the timeline?

Too many unknowns, he said. She brought him back to it and got the same answer in different words. She brought him back a second time and got it again.

She asked the correct question, at the correct moment, twice, under pressure, of the one man who should have been able to answer it. Nothing she did was wrong. But she had no way to evaluate what came back. A non-answer is what comes back from a man facing something genuinely unknowable, and it is also what comes back from a man who never looked. She had no way to tell which one she was holding, and she couldn't report up the chain either way.

So in the first room there was nobody standing where the question goes. In the second there was somebody standing there who couldn't read the answer. Those are two different failures. They land in the same place.

What both rooms bought

Both of these companies bought speed, and both were right to want it. This is what I meant last month when I said that organizations declining to pay for interrogation time are manufacturing non-expert experts on purpose and rewarding it as velocity. I'd add one thing to it now. They are not only filling their ranks with them. They are becoming one.

A company that knows what was done and not how is fluent in its own operations and cannot explain them. It passes every test it sets for itself, because the deliverables are fine and the deliverables are what it looks at. It fails at the edges — the outage, the audit, the diligence, the morning the person who built the thing doesn't come in, when the three wheeled cart topples over. Which is exactly where part 1 said the non-expert expert fails, and exactly where expertise always earned its keep.

What an institution can't price

I made a version of this argument once already about people. Hundreds of employers and more than two dozen states dropped their degree requirements. Harvard Business School and the Burning Glass Institute went and looked at who actually got hired afterward — eleven thousand roles, a decade of hiring — and found that fewer than one hire in seven hundred came out any differently. Managers handed permission to judge skill directly discovered they couldn't see it, so they went on trusting the proxy they had just been told to ignore.

I thought I was writing about hiring. I was writing about that project manager.

An institution that can't see judgment can't price it. And what a company cannot price, it eventually stops paying for.

Where it runs out

Part 2 ended on cost. The discipline takes longer, and most people don't control their own schedule, so it is structurally unavailable to them.

I had the test — the discipline — in my head in both rooms and used it in neither.

In the first room I had questions. Was there an API on this thing. What would integrating with it involve. Had anybody looked at it from a security standpoint. What happens to this business if it stops working one morning. But I asked none of them, because the conversation was about something else. In the second I didn't ask because he was under the gun and I didn't want to look like I was piling on. If anything I should have been more supportive of the spot he was in. But my thoughts in that moment were the same as the project manager's.

So I had the question, in a room where it was the only useful question the company should want, and I didn't ask it. Twice in one month, for reasons I would defend both times.

Time was part 2's currency. This one runs on standing. Inside an organization, the person who asks what was demanded looks like he is slowing things down, or doubting a colleague, or working an angle. The benefit of the question goes to the company. The cost goes to whoever opens their mouth. We used to say that the person who sticks their head above the cubicle is the one who gets their head chopped off — so no one sticks their head up.

You can't process your way out of it either, because process is what produced it. Every asking role a company builds — audit, review, QA, security — exists because nobody would ask otherwise, and every one of them is understood by everybody else as the department that slows things down.

I don't have a fix for this one. Part 2 at least ended with something a person could do if they controlled their own calendar. This ends with a question that costs the asker and pays the company, and I have now watched myself decline to ask it twice for fear of having my own head chopped off.

Where this goes

Everything I have asked across three essays is some version of did anybody look — at the system, the result, the schedule, the calculation.

But I keep thinking about the man who built the application.

He was proud of it, and he had earned that. He made a fast call, he was right about the speed, and his company uses what he built every single day. Nobody has ever asked him what he demanded before he accepted it.

Nobody ever asked me either back at the city job when I built a database app, and I never noticed that no one questioned it.

Part 1 ended on the right answer sitting in the tool the whole time, waiting for somebody in the chair to ask for it. Two essays later I can tell you what the organizational version of that looks like. It isn't that the chair is empty.

Nobody ever built the chair.

---

A note on how this was written. As with parts 1 and 2: the ideas, the anecdotes, and every judgment call about what belongs on the page are mine; the production leverage is the machine's. The full note is at the end of part 1, and it still applies — with the added observation that this essay is largely about the method it's disclosing.

Bill Dunning is the founder of 416 Inc (dba Indggo), where he leads development of Edge Mesh Protocol — verification infrastructure for real-time media. Part 4 goes to the floor of the problem, where the thing that can't be trusted is the record itself. The canonical version of this series lives at forum.indggo.com.

The Judgment Test

I look like the problem I described. The difference isn't visible in the output.

By Bill Dunning · Part 2 of a five-part series

---

This morning I was working through a piece of a project — a business application that reaches across a lot of services — and I noticed something about myself that I didn't much recognize.

I know what was done. I could walk you through it. I could tell you what each piece is for. What I could not do, in one section of it, is tell you the detail of how and why it was built that way. Not because nobody decided — decisions were made, and I was there for them. I just don't know them anymore.

I wrote part 1 of this series about people who produce expert output without expert judgment. I called them non-expert experts. Then I spent a month noticing that the description fits me from the outside better than I'd like.

Uncomfortable

I don't write most of the code anymore. The output is clean — cleaner than what I'd produce by hand, which I'll come back to. I can speak fluently about a system whose interior details I could not reconstruct from memory. And I have deep domain knowledge in three of the four parts of this project, which is another way of saying there is one part where I don't.

If you handed my situation to a stranger as a case study, they would file it under exactly the thing I warned about last month.

Part 1 said the dividing line was whether you can recognize a wrong answer that looks like a right one. I'd like to tell you I can always do that. In three of those four domains, I can because a wrong answer collides in my head. In the fourth, I'm not sure. That's an uncomfortable thing.

So either the frame I built is wrong, or something doesn't line up. I think it's the second one, and it turns out to be the test I promised you.

What I demand before anyone writes anything

I have a way of working with these tools that I did not consciously adopt. It's just how I do it, and it looks like this.

Before any code gets written, I want probes. Not a plan, not an approach — probes. Go and find out what this system actually does right now and what it actually has in hand that relates to what I'm trying to accomplish. Show me the raw state. Not your summary of the raw state; the thing itself.

Then, before I accept what the probes appeared to show, I want instrumentation and tests that validate it — specific outputs I can trace back to what I expected to see. Not "it works." A result with a shape I predicted, that I can follow back to the prediction.

Then I read all of it. That's the part that matters, and it's the part that costs. Not skim — read, and either accept it or push back. The discipline doesn't work because the probes are clever. It works because it puts me in a position where I cannot proceed without having actually looked.

And here's the thing I said I'd come back to: the result is better than what I would have produced myself. Not faster. Better. The code is better and the evidence behind it is far better than anything I'd have assembled by hand, because I would never have written that much instrumentation for my own work. I'd have trusted myself and moved on, sometimes with bugs.

What that actually is

It took me until this morning to see what I'd been doing.

That practice is not a judgment aid. It's a chain of custody. I stopped being able to hold the details, so I stopped relying on holding them, and I made them checkable instead. I replaced memory with evidence.

There's a reason it has to work that way. You cannot take an AI's answer apart. There's no interior to disassemble — no reasoning preserved, nothing to open up and inspect after the fact. Ask it why and it will produce a plausible account that may have nothing to do with how the answer actually arrived. Ask it to back that up and it will ask you for the source, so it can summarize it again. It's circular. So if you can't take the answer apart, the only remaining option is to make it show its work on the way through, at the moment it happens, in a form you can check later.

Which, it turns out, is the only trick I've ever known.

Where this came from

I come from a mechanically inclined family. My father and my brothers were machinists and die makers by trade — people who worked with their hands. My brother was always out working on his bike.

Somewhere around eight or nine, I learned to take my own bike completely apart and put it back together. Not repair it. Disassemble it, down to the parts, and reassemble it into a working bicycle. And what I learned from that wasn't mechanics. It was this: when you take something apart, you learn how it works in fine detail. There is no substitute and there is no shortcut. Looking at it doesn't do it. Reading about it doesn't do it. You have to have the pieces in your hands.

The other thing I remember from around then is a pile of electronic parts, a breadboard, and a soldering iron. I have no idea how I got there. I think I may have just been learning to solder and needed something to solder. So I wired a bunch of parts together, hooked up a battery and a speaker, and wanted to find out whether I could make a noise.

I got one. A squawk. I remember it vividly.

In retrospect it was almost certainly not the circuit. It was the battery hitting the speaker — a surge, one noise, nothing to do with whatever I thought I'd built. But I was hooked.

I've been thinking about that squawk all morning. Not because it set my course — it didn't. Because I never asked. I had a result that looked like evidence and I took it for evidence, and the question I put to everybody now is the one I didn't put to myself.

The test

Part 1 promised a simple test for telling an expert from a non-expert expert now that the output can't. Here it is, and it's one question:

What did you demand before you accepted this?

Not what did you build. Not what does it do. What did you check, what surprised you, and where did you push back?

Somebody who interrogated the process has specific answers and they arrive without effort — this is what I expected to see, this is what I actually saw, this part was wrong and here's how I found out. Somebody who didn't has a summary. A good one. Because summaries are exactly what these tools are best at. And they can't produce the specifics on request, because the specifics were never generated.

Three other things suggest this test is the right one.

It doesn't test production. Interviews filter for the ability to do by hand the thing the tools exist to do, and they reject good people while passing people who memorized. The tool is just a better slide rule. Part 1 was clear that real experts don't produce their own output anymore. Neither do I to a much greater extent than I expected, or that I did just a few months ago.

It doesn't require you to know the domain. You can ask what someone demanded of a system you couldn't evaluate yourself, and you can hear the difference between a specific and a summary without understanding a word of the subject matter.

And it's the one question the output can't answer for them. The work tells you nothing about whether anybody looked. That's exactly the gap part 1 was about, and this question walks straight into it.

I want to be clear that this test would have flagged me. On the output alone I'm indistinguishable from the person I'm describing — that's the whole point of the series, and I'm not exempt from it. The test doesn't clear me because I'm experienced or because I founded the company. It clears me because when you ask me what I demanded, I have specifics.

Where it runs out

The fourth domain. I can answer the test there too. I demanded the probes, I read the results, I pushed back where something looked off. What I can't tell you is whether my interrogation was enough, because enough is measured against what you don't know, and I don't know it. In three domains the practice preserves judgment I already have. In the fourth it substitutes for judgment I don't. From the inside those feel identical. You never can know what you don't know.

Which means that in that part of the project I'm not an expert. I've been a beginner plenty of times. The way out has never changed: do the work, get it wrong, notice you got it wrong. That still happens here — the probes come back, something doesn't match what I expected, and I find out I had it wrong. And what keeps me out of the trap in that domain isn't that I know the trap is there. Everybody I described in part 1 could tell you the trap is there. It's that I can't accept anything in that part of the system without having demanded the probes and read the results, and that is a thing you could check. Awareness isn't checkable. Demands are.

What I can't tell you is the rate. Taking something apart is still how you learn how it works, and reading raw state is a thinner version of apart than having the pieces in your hands. I don't know what it teaches per hour against writing the code myself, and I have no way to measure it. I know it isn't nothing, and I know it beats accepting the answer on trust. That's the conclusion I've arrived at this month, and I'm putting the date on it, because I don't know that it survives the year.

The cost. All of this takes longer. Considerably longer. I can afford considerably longer because nobody is standing over me telling me to ship faster — I'm the founder, and the schedule is largely mine. A developer with a sprint commitment who announces she'd like to write probes and instrumentation before touching the feature is going to be told to just use the tool. She isn't lacking curiosity. She's lacking the authority to spend the time, and that is not a fact about her. It's a fact about where she's standing. The discipline that saved me is, for a lot of people, structurally unavailable.

Where this goes

The next essay is about the same problem one size up, because an organization can be in this position too — knowing what was done and not why, fluent in its own operations without being able to explain them. Organizations declining to pay for the interrogation time are manufacturing non-expert experts on purpose and rewarding it as velocity. And filling their ranks with them.

Every question in this essay is asked about something in front of you — a system, a result, a record. The test examines it and asks what you demanded before you accepted it. All of that assumes the thing is what it claims to be.

Hold on to that.

Because this morning, I got a perfectly good result from a process I trusted, and I sat there wondering whether I'd earned it or just been handed it. Which is the question I didn't ask at nine years old, with a soldering iron in my hand and a speaker that had just made a noise. Did the circuit do that, or did something else?

---

A note on how this was written. As with part 1: the ideas, the anecdotes, and every judgment call about what belongs on the page are mine; the production leverage is the machine's. The full note is at the end of part 1, and it still applies — with the added observation that this essay is largely about the method it's disclosing.

---

Bill Dunning is the founder of 416 Inc (dba Indggo), where he leads development of Edge Mesh Protocol — verification infrastructure for real-time media. Part 3 is about the organizational version of the same problem. The canonical version of this series lives at forum.indggo.com.

---

The output got good. The judgment didn't come with it.

By Bill Dunning · Part 1 of a five-part series

---

Let me tell you about a bug I fixed recently. Or rather, a bug I almost let an AI fix for me.

I knew exactly what was wrong. One filter, in one location, wasn't catching one new case, and the processing was being dropped on the floor. A one-line fix. I knew that going in. But it was late, the fix was boring, and I had an AI coding tool open. For speed's sake, I told it: find it and fix it.

What came back — after several iterations — was a Rube Goldberg machine. New abstractions. New handlers. A configuration surface for a problem that didn't have configurations. It was elaborate, it was internally consistent, and it would have worked. It compiled. It would have passed the happy-path test. It would have sailed through a code review by anyone who didn't already know what the fix was supposed to cost.

I pushed back. The tool folded instantly — recognized the mistaken judgment, produced the one-line fix, done. Which tells you something important: the simple answer was within its reach the entire time. It just had no reason to prefer it.

Neither would I, if I didn't know better.

That's the whole subject of this essay. The knowing better. Because we have arrived at a moment when the tools are good enough that the people who don't know better produce output indistinguishable from the people who do — and I don't think we've begun to reckon with what that means.

We've been here before. Sort of.

If you're old enough, you remember 1987. Apple ships the LaserWriter, Aldus ships PageMaker, and overnight, "desktop publishing" hands the tools of a trained profession to everyone with a Macintosh. And everyone with a Macintosh concluded, more or less simultaneously, that they were a designer.

You remember what that looked like. The church newsletter with seven fonts. The ransom-note flyer. Clip art deployed like buckshot. The tools had removed the production barrier — but the judgment barrier was still standing, and for a few glorious years, the gap between the two was visible from space. Massimo Vignelli called the era the biggest visual pollution of all time, and he wasn't entirely wrong.

But notice what the pollution actually was: it was honest. The amateur's newsletter looked amateur. The output itself told you who had judgment and who had a font menu. A working designer could glance at a page and know, instantly, whether a professional had touched it. The tell was right there on the paper.

Then something instructive happened. The tools absorbed the taste. Templates, sane defaults, constrained palettes, kerning handled quietly in the background. A mediocre layout today is dramatically better than a mediocre layout in 1988 — not because people got better, but because the tool ate a layer of the expertise. The seven-fonts era turned out to be a phase, not an end state.

Here is what's different this time, and it's the difference that matters:

The tell has been removed — but the judgment still hasn't shipped.

The AI-assisted amateur's code compiles. The AI-assisted amateur's contract reads like a contract. The deck is polished, the strategy memo is articulate, the analysis is formatted like analysis. The output that used to expose the gap in judgment now conceals it. In 1988 you could spot the non-expert by the page. In 2026 the page looks perfect, and the non-expert may be the last person capable of noticing what's wrong underneath it.

The non-expert expert

So let me name the character this era is minting by the millions: the non-expert expert. Someone who produces expert output without possessing expert judgment. Fluent in the artifact, absent from the understanding.

I want to be careful here, because the obvious version of this critique is wrong. The non-expert expert's problem is not that they can't write the code, or the contract, or the copy themselves. Plenty of genuine experts don't produce their own artifacts anymore either — that's what the tools are for, and the leverage is real. My company's growth increasingly runs on exactly this kind of leverage. This is not a Luddite essay, and it's not a warning. It's an observation about where expertise actually lives now that production doesn't require it.

The dividing line is this: can you recognize a wrong answer that looks like a right one?

Go back to my bug. The Rube Goldberg fix wasn't broken. Nothing about it was detectably wrong from the outside. The only thing on earth that flagged it was a model I carry in my head of what that fix should have cost — one filter, one case, one line. The moment the answer came back two hundred lines heavier than the problem, it registered as wrong before I'd read a single line of it. That's not production skill. That's a sense of proportion, built from years of seeing what problems and solutions weigh. Call it judgment, call it taste, call it knowing a good pattern from a bad one.

The non-expert expert doesn't have it, doesn't know they don't have it, and — this is the part that's new — nothing in the output will ever tell them. They do fine on the happy path. The happy path is where the tools shine. They fail at the edge case, at the follow-up question, at the moment the fix comes back ten times bigger than the problem and nothing in their head says that's too expensive. Which is exactly where the real experts always earned their keep. The edges were never where the volume was. They were where the stakes were.

There's a growing chorus right now saying that taste is the new scarcity — that as AI absorbs execution, human value shifts to judgment. I think that chorus is right, and I think it's stopping one step short of the interesting part. Because it isn't just individuals. The same tell-removal is happening to companies, to institutions, and — this is where the series is headed — to reality itself. But one layer at a time.

The gatekeepers noticed. Sort of.

Here's a strange fact about this moment. The institutions whose whole business was certifying expertise seem to know, on some level, that their product has stopped working.

Consider the college degree — not as a verdict on higher education, but as a data point about proxies. Over the last several years, hundreds of major employers and more than two dozen states loudly dropped degree requirements in favor of "skills-based hiring." The old credential was officially retired as the filter for competence. And then researchers went and looked at who actually got hired afterward, and found the answer was: almost exactly the same people. The requirement came off the job posting; the behavior barely moved. Hiring managers, handed permission to judge skill directly, discovered they had no instrument for it — so they went right on trusting the proxy they'd just been told to ignore.

I've never had much patience for certification rackets — the orgs that charge you to take their course to earn their credential to satisfy their requirement. But watch what this moment reveals about what those credentials actually were. They were never measurements of expertise. They were a way to outsource the judging of it — a proxy for the thing nobody downstream could evaluate directly. And proxies get exposed the moment the thing they stood for becomes cheap to counterfeit.

That's where we are. We tore down the old detector before anyone built the new one. Into that gap walks the non-expert expert — credentialed by nothing but clean output, and the output has never looked cleaner.

Where this goes

I said this isn't a warning, and I meant it. The desktop publishing story ended fine. The pollution receded, the tools ate a layer of the craft, and the real designers didn't disappear — they moved up the stack, to the work the tools still couldn't do. That migration is already underway again. Expertise isn't dying. It's being redefined, one more time, as whatever still can't be generated. Right now, that's judgment: the sense of proportion that knows a one-line problem from a two-hundred-line answer.

But hold on to one sentence from this essay, because the rest of the series is going to spend it:

When output gets cheap, the output stops being evidence.

For two hundred years, the artifact was the proof. If the code ran, someone competent wrote it. If the business operated, someone inside knew how. If the recording existed, the event happened. Every one of those inferences is now broken, and they broke in the same direction, for the same reason, at the same time.

This essay was about the first one — the person. The next is about a simple test for telling the expert from the non-expert expert, now that the output can't. After that, the companies — because an organization can be a non-expert expert too, and most of them are becoming one on purpose and calling it efficiency. And then the floor of the whole problem, where the thing that can no longer be trusted isn't the deliverable or the org chart but the recording itself.

Because here's the thing about my one-line bug. The tool agreed with me the moment I pushed back. The right answer was in there all along. It was just waiting for someone in the chair who knew better.

This series is about what happens — to people, to companies, and finally to what we're able to call real — when nobody in the chair does.

---

A note on how this was written. I drafted this essay with the help of an AI writing tool, and given the subject matter, you deserve to know that. The ideas came out of thirty years at the seams of other people's systems; the anecdotes happened to me; every claim, every cut, and every judgment call about what belonged on the page was mine. The production leverage was the machine's. If that arrangement strikes you as a contradiction, read the essay again — it isn't about whether the tool touches the output. It's about whether anyone in the chair knows better. I pushed back on plenty.

---

Bill Dunning is the founder of 416 Inc (dba Indggo), where he leads development of Edge Mesh Protocol — verification infrastructure for real-time media. Part 2, "The Judgment Test," is next. The canonical version of this series lives at forum.indggo.com.

The 90-Day Test

Your AI vendor is going to disappear. Here's how to make sure your business doesn't go with it.

By Bill Dunning, founder of Innovations Applied LLC

---

I run a software company that builds custom integrations for communications technology. Increasingly, that means one thing: wiring AI products into the systems businesses actually run on — bots into phone systems, AI agents into IVR flows, machine-generated answers into customer service queues. I'm the person who has to make the AI vendor's product actually connect to your infrastructure.

Which means I see these products from an angle almost nobody else does: at the seams.

And from the seams, here's what the view looks like:

THE SURPRISE INSIDE

When you buy an AI product for a core business function, three risks come in the box. You paid for one of them.

Layer 1 — The model. The frontier AI provider your vendor is built on. Today's pricing is subsidized by investor capital chasing market share. It can change in a quarter.

Layer 2 — The vendor. The product you actually bought — very often a venture-funded company with thin margins whose business plan is to be acquired. A consolidation wave is coming for this layer. The usual fate of an acquired product: sunset within 24 months. You won't get a price increase. You'll get a 90-day notice.

Layer 3 — You. The business that restructured around the product — reduced the staff, retired the manual process, let the documentation go stale. The layer where the risk actually lands.

You control exactly one of these layers. It's the one most businesses are busy dismantling.

The rest of this piece is about that third layer — how businesses are quietly deleting their own ability to survive the first two, and what it costs to keep it. But first, let me show you the surprise I keep finding inside the box.

Let me tell you about a call I was on recently. A business is putting a conversational AI bot in front of its phone system — the bot handles callers, and hands off to the existing telephony infrastructure when it needs to. Standard automated IVR scenario, exactly the kind of work that fills my calendar now. On the call: me, the client, and the AI vendor's technical representative.

I had ordinary integration questions. How does the bot actually process the interaction? How is the handoff to and from the phone system constructed? What state carries across? Where are the boundaries?

The vendor's own technical rep couldn't answer most of them. Not evasive — genuinely didn't know. It took a full hour of discussion to extract a few fragments of information and a promise to follow up with a data dictionary.

Maybe that was one underprepared person. But here's the thing: it wasn't the first time, and it wasn't the fifth. As more of my work centers on integrating AI tools, this is the pattern — vendors whose products are black boxes even to their own people.

Now sit with what that means for the business on that call. They are about to place a system nobody can fully explain — not them, not me, not the vendor's own representative — directly between their customers and their company. And they're doing it, like everyone is, with a plan to reduce the staff who used to answer those phones.

Which brings me to a question I think every business adopting AI this deeply should be forced to answer:

If that AI vendor sent you a shutdown notice tomorrow — 90 days until the lights go out — could you run your business while you replaced them?

Not "would it hurt." Of course it would hurt. Could you operate? Could you answer your phones at volume? Could you quote, schedule, route, respond? Does anyone left in your company know how those processes work without the tool — when the vendor's own engineers barely know how they work with it?

This isn't an argument against AI

Let's get this out of the way, because anyone raising risk in this conversation gets filed under "Luddite." My company's growth is increasingly built on AI integration work. The capability is real, the demand is real, and abstaining is not a strategy. The businesses deploying these tools well are getting genuine leverage from them.

This is an argument about how you adopt — built around a distinction I've come to believe is the most important idea for any business making these decisions right now:

There is a difference between eliminating labor and eliminating knowledge. Labor elimination is reversible. Knowledge elimination is a one-way door.

When AI takes over work a person used to do, you save the labor cost. That's the number in the vendor's ROI deck. But if the person leaves, the documentation goes stale, and the process now exists only inside the tool — you haven't cut a cost. You've deleted your company's memory of how it does what it does.

You can rehire labor. You cannot rehire memory that has left the building. And what I see from the integration side is businesses deleting theirs one deployment at a time — while connecting to vendors who, as that call demonstrated, may not fully possess the knowledge either.

Why this shakeout will be different from the last one

The comparison everyone reaches for is the dot-com bust, and it's half right. There's a bubble dynamic: enormous capital chasing AI companies, many of them thin wrappers around someone else's model with no durable business. Consolidation is coming. A large share of the AI products being sold today will not exist in five years — acquired, absorbed, or shut down. That part is familiar.

Here's the part that isn't. In 2000, when the dot-coms died, the businesses that had merely bought from them mostly shrugged. Your web design firm folded? You hired another one. The internet was a channel bolted onto the business — not a replacement for its internal organs.

This time the product isn't a channel. It's the process itself. The AI bot isn't sitting next to your call center; increasingly it is your call center. And the ROI case explicitly includes reorganizing around it: fewer people, the tool as the system of record for how the work gets done.

So vendor mortality lands differently. When a SaaS CRM shuts down, you migrate records — painful, survivable. When an AI product that absorbed a business function shuts down, the labor disappears. And if you restructured aggressively, the people who knew how to do it manually walked out a year ago.

Two more structural problems, both of which I watch from the integration seat:

Most businesses carry two layers of someone else's risk. They don't buy AI from the frontier labs; they buy vertical products — AI for contact centers, AI for scheduling, AI for the front desk — built on top of the big models. That's exposure to the model provider's pricing and the app vendor's survival, and the app vendor is very often a venture-funded company with thin margins whose plan is to be acquired. If the model layer raises prices, the vendor eats it or passes it through. If consolidation takes the vendor, you don't get a price increase. You get a sunset email.

The opacity is load-bearing. When I can't get a data dictionary out of a vendor, that's not just my integration problem — it's the customer's exit problem, deferred. Every undocumented handoff, every proprietary interface, every "we'll get back to you on how that works" is a strand in a net that will hold the customer exactly when they most need to move.

The history books about past shakeouts are written by survivors, which is why the popular memory of the dot-com era is "it all worked out." The retrospectives never count the small businesses that bet on the wrong platform and folded quietly. There will be a body count this time too, and it will concentrate among businesses too small to self-host, too restructured to revert, and too dependent on vendors too fragile — and too opaque — to last.

The three kinds of lock-in — and the one that kills

Not all dependency is equal. There are three distinct layers:

Data lock-in. Can you get your information out in a usable format? The oldest form, and the easiest to check: try the export before you need it.

Workflow lock-in. Even with your data out, does anything else speak this tool's language? Integrations, automations, the shape of your team's daily work. This is where I live professionally, and I'll tell you plainly: the difference between a clean migration and a death march is decided at build time, by whether the integration was constructed with documented, standard seams — or fused directly into whatever proprietary interface the vendor offered that quarter.

Knowledge lock-in. The killer, and the one no software audit surfaces, because it's not in the software — it's in your org chart. Does anyone in the company still know how the process works without the tool? Could someone reconstruct your call flows, your routing logic, your service rules from documentation and living human knowledge? Or has "how do we do this?" quietly become "the system handles it" — about a system that, as I keep discovering on vendor calls, even the vendor struggles to explain?

Data lock-in costs money on the way out. Workflow lock-in costs time. Knowledge lock-in can cost the company — because it's the only one you can't fix by spending, and it's invisible until the day you need it.

The insulation playbook

Insulating against this doesn't require abstaining, self-hosting models, or a risk department. It requires treating AI vendors the way experienced operators treat any single point of failure. Seven practices:

1. Run the 90-Day Test on every critical vendor — in writing. For each AI tool touching a core function: if it vanished with 90 days' notice, what breaks, who fixes it, how? If the answer involves a person who no longer works for you, you've found a one-way door you already walked through.

2. Distinguish labor cuts from knowledge cuts — before the reorg. When AI adoption lets you reduce headcount, ask which cut removes effort and which removes the last person who understands the process. Cutting effort is efficiency. Cutting the final knowledge-holder is a bet-the-company decision in an efficiency costume. Sometimes still the right call — but make it consciously, and pay the mitigation cost: documented process capture as a condition of the transition.

3. Make the vendor's engineers explain the seams — before you sign. This one comes straight from my calendar. Put your integrator (or your own technical person) on a call with the vendor's technical staff and ask how the product actually connects: what crosses the boundary, in what format, with what documentation. If their technical representative can't answer, that is your answer. A vendor that can't explain its handoffs while courting you will not become more transparent after you've restructured around them. Demand the data dictionary before the contract, not after.

4. Keep a shadow process for anything mission-critical. Not a parallel manual operation — cost theater no smaller business can afford. Documentation kept current, plus a periodic manual fire drill: once a quarter, route a call the old way, build a quote by hand. A few hours that keep the muscle alive. Think of it like testing your backups — pointless right up until it's everything.

5. Make exportability and standard interfaces purchase criteria with teeth. Full data export, in what format, self-service or by request — and test it during the trial. Prefer tools that connect through documented, standard interfaces even at some feature cost. The premium you pay for portability is an insurance premium, and it's cheap. When the integration is built, insist it be built at the seam, not fused to the vendor's proprietary internals — that decision, made once at build time, is most of your future exit.

6. Underwrite the vendor, not just the product — and negotiate the exit at the entrance. Who funds them? What's their likely path — profitability, acquisition, or death? (The usual fate of an acquired product: sunset within 24 months.) Then get terms while they're hungry for logos: a data-return clause, minimum notice for shutdown or material price changes, month-to-month after year one. This is the best negotiating position you will ever have with them.

7. Cap single-vendor exposure across functions. The all-in-one AI platform that runs your calls and scheduling and customer comms is operationally seductive and strategically radioactive. Two tools with a documented seam between them beat one tool that becomes your entire nervous system.

The upside of being the prepared one

Here's what the doom framing misses. A shakeout doesn't just destroy — it reprices. When consolidation comes, the capability won't disappear; it gets absorbed by survivors and, if history is a guide, gets cheaper. The rails outlasted the railroad bankruptcies. The fiber outlasted WorldCom.

The businesses that come through this well won't be the ones that avoided AI. They'll be the ones that adopted it deeply and kept their memory intact and their seams clean — companies where a vendor's death is a bad quarter and a swap-out project, not an extinction event. Those companies get to shop the fire sale: distressed competitors' customers, suddenly cheap capability, better vendors at better terms.

The window to build that position is now — while your vendors are healthy, the people who know the old ways are still on payroll, export buttons still work, and the vendor's sales engineers still return your calls.

So ask the question. Ninety days. Could you run the business?

If you had to think about it, that's your answer — and your to-do list.

---

Bill Dunning is the founder of Innovations Applied LLC, a software firm that builds custom integrations for communications technology — increasingly, the connections between AI products and the phone systems, contact centers, and business platforms they're being wired into. Connect with him on LinkedIn.

Seeing Is No Longer Believing

Synthetic media broke the link between perception and truth. Restoring it will take more than detection.

Bill Dunning · May 2026

---

The cliff

For all of human history, perception was proof. You saw it happen. You heard someone say it. You looked at a photograph. That was sufficient. Courts accepted eyewitness testimony. Photographs settled disputes. Recordings established facts. Not because these things were perfect, but because fabricating them was hard enough that they carried default credibility.

That default has collapsed. Not gradually — it fell off a cliff.

Voice cloning takes three seconds of sample audio. Real-time face-swapping runs on a consumer laptop. Generated photographs already fool forensic experts. Generated video is months from being indistinguishable from reality. We have crossed a line where the cost of fabricating audio, video, and images has dropped below the threshold of credibility. There is no going back.

The consequence is not merely that fakes exist. It is that real things lose their power. A genuine recording of someone saying something can now be dismissed as a deepfake. A real photograph can be denied. Real video evidence can be challenged — not by proving it is fake, but simply by asserting it could be. Legal scholars have a name for this: the liar's dividend — the advantage gained by guilty parties who can dismiss authentic evidence by gesturing at the possibility of fabrication.

Why detection isn't the answer

The instinctive response is to build better detection: AI systems that identify synthetic media. Spend a few minutes thinking about that response and the problem becomes obvious. Detection is an arms race the defender loses by definition. The generator learns from the detector. Every detection breakthrough becomes training data for the next generation of fakes.

Detection has uses — content moderation, quick triage, public awareness. But it cannot be the foundation of trust. The foundation has to be something stronger, something that doesn't depend on guessing whether a piece of media looks real.

The right question isn't "how do we spot fakes?" It's:

How do we create things that are provably real?

Not probably real. Not authenticated by a vendor's promise. Mathematically provable. Independently verifiable by anyone, without trusting any intermediary.

What physical media used to do

For centuries, physical media carried proof of its own integrity. A wax seal on a letter did three things: it proved who sent it, it proved the letter hadn't been opened, and the recipient could verify both without trusting anyone in the delivery chain. The seal broke if tampered with. The proof was built into the medium itself.

When communication became digital, that property was lost. Digital content is infinitely copyable, silently editable, and dependent on institutional trust. Trust us, we didn't alter it. Trust us, we didn't access it. Trust us, we're storing it properly. The content is at the mercy of whoever controls the infrastructure it flows through.

The right response to the synthetic-media crisis is to restore that property — to make digital communication self-proving. A self-proving system has three characteristics.

Integrity. The content carries mathematical proof that it has not been altered since creation — not a single frame, not a single byte. If anything changes, the proof breaks.

Provenance. The content is cryptographically bound to a specific physical device that captured it, at a specific time, in a specific place. Not "this came from a user account." This recording came from this specific piece of hardware, and that hardware's identity is attested by a certificate chain that anyone can verify.

Independence. Verification requires no trust in any platform, no network access, no proprietary software, and no cooperation from the system that created the recording. Anyone with the recording and its cryptographic manifest can verify it independently. The proof travels with the content.

Integrity, provenance, independence. These are what physical media had and digital media lost.

What this looks like in practice

I'm building one implementation of this idea. It's called Edge Mesh Protocol, and its provisional patent is on file with the USPTO. The architecture is built around a few specific decisions.

Media flows directly between participating devices. The platform's coordination server arranges the connection but never handles the media itself. This is structural, not a cost optimization — because the platform never touches the media, it cannot alter it, it cannot access it, and it cannot be compelled to produce it.

End-to-end encryption is applied at the source device with keys generated on-device that never leave it. The platform relays ciphertext it cannot read.

During a recording, the device builds a continuous hash chain in real time. Every ten seconds of recording is hashed, and each chunk's hash incorporates the previous one — forming an unbroken cryptographic chain from the first moment of the recording to the last. The final hash is signed by a hardware-backed key inside the device's secure enclave. A manifest accompanies the recording with all the hashes, timestamps, the device's certificate, and the signature.

Anyone with the recording, the manifest, and the certificate authority's public key can independently verify that the recording was produced by a specific identified device, at a specific time, and has not been modified — not even a single frame. If anything is altered, the signature breaks, and the verification pinpoints the exact ten-second window of tampering.

That's the digital wax seal. It proves who made the recording. It proves nothing was altered. It breaks visibly when tampered with.

The shape of the answer is a standard

What I've described is a product I'm building. But the architecture implies something larger.

The framework — device identity attested by a certificate chain, continuous integrity proofs computed during the recording itself, manifests that anyone can verify independently — is not inherently tied to any specific implementation. It's a set of principles and protocols any platform could adopt and any verifier could check.

This pattern has a precedent.

Dolby didn't build theaters. Dolby defined what sounds good meant, certified equipment that met the standard, and licensed the mark. UL didn't manufacture electrical equipment. UL defined what safe meant, tested products against the standard, and certified those that passed. Bluetooth SIG didn't build phones. It defined how devices communicate, and every manufacturer on Earth built to the spec. VeriSign didn't own the internet. It owned the certificate authority that made everyone else's security meaningful.

Every padlock icon in every browser is a small advertisement for the position someone built when they made themselves the root of trust.

A "Provable Media Certified" mark would do the equivalent for tamper-evident recording: a recording produced by a conforming system carries an integrity manifest signed by an attested device; verification is independent, offline, and requires no proprietary software; tampering anywhere in the chain is detectable, and locatable to a specific moment in the recording. Buyers — notaries, courtrooms, hospitals, families — would learn what the mark means, the same way they learned what UL means and what HEPA means.

This isn't going to happen overnight. But it's the shape of the answer.

What this is really about

We're living through a specific moment. The moment when synthetic media broke the link between perception and truth. When a video of someone saying something is no longer proof they said it. When a voice on the phone is no longer proof you're speaking to who you think you are.

This is not a problem that any one product solves. It's a problem that requires new infrastructure — a new foundation for what real means in a digital world.

I'm working on one piece of that foundation: provable real-time video, starting with the markets that need it most urgently. Remote online notarization, where forty-plus states now require tamper-evident recordings. Telehealth, depositions, courtroom evidence, in-home care. The places where the recording has to stand up to challenge, and current infrastructure can't make it.

The bigger picture is this: in a world where nothing digital can be trusted by default, build the infrastructure that makes specific things provably trustworthy. Restore the wax seal. Rebuild the link between what we see and what we know.

Seeing is no longer believing. The work is to build the proof that makes it believing again.

---

Bill Dunning is the founder of 416 Inc (dba Indggo), where he leads development of Edge Mesh Protocol. If you work in legal tech, remote online notarization, telehealth, or AI safety — or if any of this resonates and you'd like to talk — find him on LinkedIn. The canonical version of this piece, and longer technical conversations, live at forum.indggo.com.

Is Generative AI a revolutionary new mind or just a sophisticated mimic? The debate rages, but it might be missing the point entirely.

What if we're using the wrong metaphor altogether? The most useful way to understand AI might not come from computer science, but from the surreal and mysterious world of our own subconscious.

I had this realization yesterday morning, waking from a dream so vivid I could still feel its edges. It was a full-sensory experience—in color, with dialogue, action, and shifting locations. As I lay there, I began to unpack it. Where did this bizarre narrative come from?

The answer was simple: it came from everywhere. The story my sleeping mind had just "generated" was a collage stitched together from over sixty years of my own data—every book I've read, every face I've seen, every trip I've taken, and every fleeting observation from the day before. Some minor input from my waking life had served as a "prompt," triggering my mind to weave a new tapestry from the threads of my entire existence.

The dream itself was gloriously imperfect. It was a world of impossible juxtapositions, half-remembered faces, and delightfully absurd physics. It wasn't logical or factual, but it felt real.

And in that moment, it clicked. Generative AI works just like a dream.

Think about the parallels. An AI model is trained on a vast dataset—the collected knowledge, art, and ramblings of humanity on the internet. This is its "lifetime of experience." We then give it a prompt, a small seed of an idea. The AI, in turn, draws upon its immense, chaotic library of information to generate a response.

It creates scenarios, writes text, and produces images by pulling together patterns it has seen before. It doesn't "know" what a hand is, but it has seen millions of pictures of them, so it generates a plausible-looking hand... sometimes with an extra finger. It doesn't "understand" legal precedent, but it has read countless court documents, so it confidently constructs a citation for a case that never existed.

Is it any wonder, then, that AI hallucinates? Our dreams do it every night. They create nonsensical yet compelling realities from the fragments of our memory.

This re-frames the entire debate. The flaws of AI aren't bugs in its "intelligence" so much as they are features of its dream-like nature. The problem isn't that AI is a bad thinker; the problem is that it isn't thinking at all. It's dreaming.

But just like our dreams, that doesn't make it useless. How often have you woken up with a fresh perspective on a difficult problem? A dream can spark a creative breakthrough or untangle a mental knot, precisely because it isn't bound by logic.

Generative AI is a powerful tool for exactly the same reason. It is a collective dream engine. It offers us scenarios and ideas remixed from our shared human experience. These outputs are not, and cannot be, truly original thoughts. They are reflections.

So, is Generative AI intelligent? Perhaps that’s the wrong question. It isn’t a mind to be trusted, but a dream to be interpreted. Its value isn't in its factual accuracy, but in its ability to provide us with novel combinations of ideas. It's a mirror to our collective data, showing us strange, beautiful, and sometimes distorted versions of ourselves.

Our role is not to blindly accept its creations, but to be the dreamer who wakes up, finds the spark of inspiration in the absurdity, and brings it into the real world.

The End of Immunity: How Generative AI Makes Tech Giants Content Creators

For over two decades, a powerful legal doctrine has shielded internet companies from liability. The argument was simple: they were merely platforms—neutral conduits for ideas and opinions posted by other people. They weren't the content producer, just the utility that delivered it.

With the advent of generative AI, that foundational argument is being obliterated. Tech giants are no longer just hosts; they are actively producing content. This shift represents a legal earthquake rumbling through Silicon Valley, fundamentally changing our ability to hold technology companies liable for the content on their platforms.

The Argument: From Passive Host to Active Creator

By deploying generative AI tools that synthesize, summarize, and create wholly new content, tech companies are fundamentally changing their role. In doing so, they are not just chipping away at their Section 230 liability shield; they are taking a sledgehammer to its very foundation.

The Old World: The "Bulletin Board" Defense

The classic analogy is that of a coffee shop owner with a physical bulletin board. The owner provides the board and pins (the "platform"), but they are not legally responsible for a defamatory flyer that someone else posts. For years, this principle protected Google from lawsuits over search results (it just indexed others' content), Facebook and X from user posts, and Yelp from user reviews.

The New World: Shattering the Analogy

Generative AI shatters the "bulletin board" defense. The platform is no longer just providing the cork and pins; it is operating a machine that instantly writes a brand new flyer based on a customer's suggestion. This transforms them into content producers in several key ways:

1. From Indexing to Synthesizing (e.g., Google's AI Overviews):

• Old Google acted as a librarian, giving you a list of links to books written by others.

• New Google acts as an author. When you search, its AI writes a new summary paragraph that never existed before. If that summary defames someone or gives dangerously incorrect information (e.g., "this trail is safe in winter" when it’s prone to avalanches), Google is arguably the publisher.

2. From Hosting to Co-Creating (e.g., Meta's AI Image Generation):

• Old Instagram hosted a user's uploaded photo. The user was the sole creator.

• New Instagram provides the engine of creation itself. When a user prompts the AI to generate a photorealistic—and potentially defamatory—image, Meta's tool is what creates the pixels. Meta is no longer a passive host but an active partner in the creation.

The "Creator" Trap

The law protects platforms from liability for what others post, but the law defines an "information content provider" (ICP) as anyone "responsible, in whole or in part, for the creation or development of information." The legal argument against tech companies becomes startlingly simple: By designing, training, and fine-tuning an AI model, the company is, by definition, "responsible, in part," for the creation of its output. The AI is not "another user"; it is a core feature of the service.

Implications: A New Era of Legal Responsibility

This transformation opens up new battlegrounds for liability that will be fought in court for the next decade.

1. Direct Publisher Liability: When an AI "hallucinates" and states that a CEO was convicted of a crime they never committed, that CEO can now potentially sue the platform directly for defamation as the publisher.

2. Product Liability Lawsuits: This is a powerful new avenue. Lawyers can argue the generative AI model is a "product." If that product is defective (e.g., it has a propensity to generate false or harmful content) and causes harm, the manufacturer (the tech company) can be sued under established product liability law.

3. Liability for Training Data: Accountability may extend beyond the AI's output to its input. If a model is trained on copyrighted or private data, platforms could be seen as laundering and profiting from that information.

4. The Rise of a "Duty of Care": Courts and legislators may pivot from blanket immunity toward a "reasonable care" standard. The question will no longer be if a company can be held liable, but rather, did the company take reasonable steps to prevent foreseeable harm from its AI? This would shift the entire paradigm from immunity to negligence.

The Platform's Defense (And Why It Falls Short)

Tech companies will inevitably argue that their AI is merely a sophisticated tool and that the user's prompt makes the user the true content creator. "We provided the chisel," they will claim, "but the user sculpted the statue."

While clever, this argument is weak. They didn't just provide a chisel; they built an autonomous, master-sculptor robot with its own embedded biases, knowledge, and creative tendencies—one that can produce works far beyond the user's specific instructions or abilities.

Conclusion: The End of the Free Pass

The move to generative AI represents the most significant challenge to the legal status of online platforms in a generation. The wall of immunity was built for a world of static webpages and user comments. That wall now faces a tsunami of AI-generated content, and it is unlikely to survive intact. Tech companies have stepped firmly into the business of content production, and with that new role will inevitably come a new era of legal responsibility.

Three Reasons AI-Powered Search Results Might Be a Bad Idea

Search engines like Google are increasingly using AI-generated summaries and suggestions at the top of their search results. These are likely based on distilling vast amounts of high-quality content from across the internet and other sources.

But what are the risks if this approach becomes the standard for all search tools?

1. New and Original Content May Be Buried
AI-generated results often rely on existing content. This makes it harder for new or original material to surface and gain attention, potentially discouraging fresh contributions.

2. The Connection Between Searchers and Content Creators Is Lost
When AI presents a summary, users are less likely to visit the original source. This weakens the link between the searcher and the content creator—who might be an expert worth engaging with. It also reduces opportunities for creators to earn income from their work.

3. Critical Evaluation of Sources Becomes Difficult
Summaries limit the ability to assess who wrote the original content and whether they are credible. That judgment is left entirely to the AI, which may carry biases—especially if profit motives influence which sources are highlighted.

Bonus Concern: Loss of Context
Sometimes, the meaning of a piece depends heavily on its context or point of view. An AI-generated summary may misinterpret or overlook that nuance, leading to misunderstanding.

What We Might Be Giving Up

AI-generated summaries may seem like a shortcut to information, but they come at a cost. They risk burying new voices, detaching us from the people behind the content, and filtering meaning through a machine that may not understand nuance. As this becomes the norm, we should question not just what we’re gaining—but what we’re quietly losing in the process.

Scarcity of Resources is a Rule.

LLM's are built by ingesting huge amounts of available content. In this first iteration, the LLM's ate all the publicly available content that is available, regardless of their right to have, copy and distribute it. Protection was limited or non-existent for it's owners.

LLM's have current knowledge ( if you can call it that ). But like any life-long learner, AI will need new content to stay current.

That can be seen in action when a company who wants to use AI must first 'train' it with proprietary information before it will be useful.

General purpose LLM's must train on new trends and new creative content as well.

What happens when content creators become better at protecting their work from capture by the LLM's? The models will necessarily stop learning and be stuck in the past - much like that high school buddy who never left the 90's.

Past copyrighted work may be lost for all practical purposes, but going forward, new work can - and should - be protected. Once effective strategies and technology is available to protect new works from unauthorized capture, then business model for AI companies will have to change. LLM's will compete for new content and pay for it in order to be competitive.

The AI/LLM vendors who can make this transition first, will be the ones who survive.

It may not be a great comparison, but consider Napster and iTunes. Who survived?

What Role Does Inspiration Play in AI?

In human creativity, what role does inspiration play and is it transferable to AI / LLM's?

Humans are inspired by the world around them, the sights, sounds and other senses all play a part. One could argue that AI could do the same thing, but with a much larger lens.

Inspired creativity requires conscious thought, perception and the ability to see/imagine the future. Can AI do that? Can AI ever recognize when an idea or the juxtaposition of facts and surroundings equals something worthy of exploration and will resonate with humans?

Is AI destine to create new structures and ideas that only other AI's can appreciate? Is a whole other society being created?

Of course, the ethical question remains the elephant in the room. LLM's are built on the collective works of humans. In many cases, copyrighted works that they have no right to use.

While human inspiration comes from a human experience, stored as memories and thoughts in a human brain, can we also say that AI can be inspired by it's larger lens of experiences & memories? Except that the source of those experiences & memories is work that has been captured, stored and analyzed in a commercial system. It has been physically captured and used without permission with it's derivative work sold to users on line.

Let's agree that a human can look at a painting, read a book, or listen to music, and store those memories in their brain for personal use. Then create something new that has been inspired by those memories - but not legally create a derivative work.

Is a public library the same thing as a LLM created by a non-profit, where you can check out a book and not violate the author's rights as long as the book was purchased or donated for the use?

Does this mean that only ethical way to treat LLM's and AI's are as public utilities which are regulated on behalf of society as a whole?