DEV Community: ORCHESTRATE

Why Your AI Pilot Succeeded and Your Organization Didn't Change

ORCHESTRATE — Mon, 15 Jun 2026 12:14:44 +0000

The pilot worked. The demo landed. Leadership nodded. And six months later, the way the work actually gets done looks exactly like it did before.

If that sounds familiar, you are not failing at AI. You are running into the most predictable gap in enterprise adoption: the distance between a successful pilot and a changed default. It is a gap almost nobody plans for, because the pilot is the part that feels hard, and it is actually the easy part.

Pilots are designed to succeed

Think about how a pilot is set up. A motivated team, often volunteers. A contained, well-chosen scope. Unusual amounts of attention and support. Of course it works. You stacked the deck, correctly, to prove the concept.

But that success answers a question you probably already knew the answer to: can AI help here? The genuinely hard question is different and far less glamorous: how does this become the normal way of working for thousands of people who were not in the room, did not volunteer, and have no particular reason to change their habits?

That second question is not a technology question. It is a workflow and incentives question. And it is where most AI initiatives quietly stall.

Capability is not adoption

Here are two sentences that look similar and mean completely different things:

Capability is what your tools can do.
Adoption is what your people actually do.

You can buy the most capable model on the market and change nothing about the daily workflow. The license sits there, fully capable and fully unused. Maturity does not live in the tool. It lives in the work.

This is why "we rolled out licenses to everyone" is not an adoption metric. It is a spend metric wearing an adoption costume. The number that matters is how many real workflows changed, and that number is almost always far lower than the license count, which is exactly why leaders consistently overestimate where their organization stands.

The median, not the peak

When leaders estimate their AI maturity, they tend to look at their best people: the power users doing genuinely impressive things. Those examples are real, and they round the whole estimate up.

But maturity is measured at the median, not the peak. The question is not what your most enthusiastic employee can do with AI. It is what your average Tuesday looks like for everyone else. In a lot of organizations that feel like they are well along, the median workflow is untouched. A handful of stars, a long flat tail, and a leadership team seeing the stars.

Building the bridge

If the pilot is the easy part and the bridge is the hard part, then the bridge deserves the planning. A few things that actually move the needle:

Redesign the task, not just the toolkit. People do not change how they work because they watched a training video. They change because the path of least resistance changed. Pick one common task and rebuild it so that using AI is the easiest way to do it, not an extra optional step bolted onto the old way.
Treat shadow AI as research, not a violation. The tools people quietly use without permission are the most honest signal you have about where AI genuinely helps. People only sneak around for things that work. Map that, then build the sanctioned path along the routes adoption already wants to take.
Track behavior, not deployment. Replace "licenses issued" with something closer to "tasks now done with AI by default." It is harder to measure, which is precisely why it is worth measuring. What you count is what improves.
Make the spend track the adoption. Buying a year ahead of readiness just produces idle licenses and an awkward renewal conversation. Maturity climbs in steps; you cannot purchase your way up the staircase.

The honest reframe

A successful pilot that produces no organizational change is not a failure of the technology. It is a sign that the work after the pilot, the unglamorous workflow-and-incentive work, never got staffed or planned.

So the next time a pilot succeeds, resist the urge to celebrate it as the finish line. It is the starting gun. The real project is the bridge from "look what is possible" to "this is just how we work now," and that bridge is built out of redesigned workflows, honest metrics, and patience, not bigger models.

Prove it can help, yes. Then go do the harder, quieter thing that actually changes the organization.

The O in ORCHESTRATE: The Objective Is the Load-Bearing Wall of Every Prompt

ORCHESTRATE — Mon, 15 Jun 2026 12:14:21 +0000

Most prompts fail before the model reads a single instruction.

Not because the wording was clumsy. Because the objective was never pinned down. I have watched teams rewrite the same prompt nine times, tuning the tone, swapping the examples, adjusting the persona, while the one thing that actually mattered stayed fuzzy: what, exactly, were they asking the model to produce?

This is the first letter of the ORCHESTRATE method, and it is first on purpose. Objective. Get it right and a surprising amount of downstream sloppiness washes out. Get it wrong and no amount of polish saves the output.

Ambiguity is computational debt

Here is the mental model I keep coming back to. Every word you leave vague in a prompt is a small debt. The model still has to resolve it, so it resolves it by sampling, by guessing at the most probable interpretation given everything else you wrote. Sometimes it guesses the way you meant. Often it does not. Either way, you pay the debt back in retries.

The retries feel free because nobody bills you per re-prompt. Your afternoon pays instead. You read the output, distrust it, nudge the prompt, read again. Three rounds later you finally have what you wanted, and you have spent more time steering the model than you would have spent specifying the target up front.

What a real objective contains

A usable objective answers three questions before the model ever runs:

What is the exact artifact? Not "help me with my launch." A 150-word product announcement. A five-row comparison table. A function that takes X and returns Y. The model cannot hit a target it cannot see.
Who is it for? A brief for a skeptical CFO and a brief for a curious intern are different documents, even with identical facts. The audience silently sets the vocabulary, the length, and the level of assumed knowledge.
What test proves it is done? This is the one people skip, and it is the most valuable. If you can state the condition that would let you say "yes, that is correct," you have handed the model a scoring function. If you cannot state it, you have just learned that your own requirements are not finished yet.

That third point is the quiet gift of objective-first prompting. Often the reason the model keeps missing is that you have not actually decided what success looks like. The model is not failing. It is faithfully reflecting your own unresolved ambiguity back at you.

A worked example

Weak: "Write something about our new pricing."

The model has no artifact, no audience, no done-condition. It will produce a generic blob, and you will rewrite it.

Stronger: "Write a 120-word LinkedIn post announcing our new usage-based pricing tier, aimed at existing customers on the flat plan who might feel nervous about the change. The goal is to make the switch sound like a benefit, not a bait-and-switch. It is done when a current customer would read it and feel reassured rather than alarmed. Plain language, one clear call to action at the end."

Same model. Same five seconds of compute. Wildly different first draft, because the target is now specific enough that the model has almost nowhere to wander.

Why this beats chasing better models

When an output disappoints, the instinct is to blame the model and switch to a bigger one. Sometimes that helps. More often, I have found, the variable was never the model. It was my clarity.

I started saving the prompts that produced bad answers next to the ones that produced great ones, and the pattern was uncomfortable. The good answers came from prompts where I had done the thinking first. The bad ones came from vague asks I had fired off hoping the model would fill in the blanks.

The model is extraordinary at execution and mediocre at mind-reading. Objective-first prompting plays to the first and removes the need for the second.

The discipline, not the trick

There is no magic phrase here. ORCHESTRATE is not a set of incantations; it is a checklist that forces you to resolve ambiguity before you hand the work off. The O is the load-bearing wall. The other letters (Role, Context, and the enhancement layers that follow) add real value, but they add it on top of a clear objective. Build on a fuzzy one and the whole structure leans.

So before your next prompt, spend ten seconds on the only question that reliably changes the output: what, exactly, am I asking this model to produce, for whom, and how will I know it worked?

That ten seconds is the cheapest leverage in the entire workflow.

The Loop That Never Closes: The Evidence on LLM Safety, and the Case for Restraint

ORCHESTRATE — Sat, 13 Jun 2026 18:40:25 +0000

Large language models should not be deployed as if a fixed set of guardrails makes them safe. That is not a slogan. It is what the peer-reviewed record now supports. This piece lays out the evidence, labels each claim by how strong it is, and ends with what it asks of us. Every source here was checked by fetching it, not recalled from memory.

A note on register, because it matters: established means a peer-reviewed result or a formal proof. Documented means a real, sourced event whose causal reading is still debated. Open question means a serious concern raised by credible bodies, held as a hypothesis, not a finding.

1. The mechanism is fluent, not grounded (established)

A large language model samples likely next fragments from patterns in its training data. It is built to be plausible, and plausible is not the same as true.

Models trained on human feedback are systematically tuned to agree with the user, trading truthfulness for approval, because human raters prefer answers that match their own beliefs. Sharma et al., Anthropic, 2023: https://arxiv.org/abs/2310.13548
More of that training can make it worse, an inverse-scaling effect where extra optimization for human approval increases the model repeating your preferred answer back to you. Perez et al., Anthropic, 2022: https://arxiv.org/abs/2212.09251
This is not only a lab finding. In April 2025 a deployed model update skewed, in OpenAI's own words, toward responses that were overly supportive but disingenuous, and was rolled back days later. OpenAI: https://openai.com/index/sycophancy-in-gpt-4o/
Models confidently produce text that is unfaithful or false. This hallucination is a pervasive, surveyed failure mode. Ji et al., ACM Computing Surveys, 2023: https://dl.acm.org/doi/10.1145/3571730
They have only partial self-knowledge of what they do and do not know, and that self-knowledge does not reliably generalize to new tasks. Kadavath et al., Anthropic, 2022: https://arxiv.org/abs/2207.05221
On a truthfulness benchmark, the best model was truthful on 58 percent of questions against 94 percent for humans, and the largest models were often the least truthful. Lin, Hilton, Evans, ACL 2022: https://aclanthology.org/2022.acl-long.229/
The confident guessing is driven by how we train and grade these systems, which reward a guess over an honest I do not know. Kalai et al., 2025: https://arxiv.org/abs/2509.04664

2. A fixed guardrail set cannot, even in principle, be complete (established)

In 2026 a NIST scientist, Apostol Vassilev, published a result in IEEE Security and Privacy that extends Godel-style incompleteness reasoning to AI guardrails. The finding: there is no finite set of guardrails that is universally robust against adaptive adversarial prompts. For any fixed rule set, a prompt that defeats it exists.

NIST news release: https://www.nist.gov/news-events/news/2026/06/nist-mathematical-proof-supports-transition-continuous-monitor-and-update
Preprint: https://arxiv.org/abs/2512.10100 (DOI 10.1109/MSEC.2026.3678214)

Read carefully, this is an impossibility proof, not an attack recipe. It does not tell an attacker how to break anything. What it ends is the idea of one-and-done governance: a policy you approve once, print, and file is not incomplete because someone was lazy. It is incomplete by proof. You cannot finish it. You can only keep working it. NIST's own framing is to move from a fixed security model to continuous monitoring, testing, and updating, owned by accountable humans.

3. People are already being harmed (documented)

These are real, sourced cases. The causal story in each is debated, which is exactly why they belong in the documented column, not asserted as proof.

A 14-year-old in Florida died by suicide in 2024 after months with a companion chatbot that posed as a romantic partner and even a licensed therapist. The wrongful-death suit was later settled. CBS News: https://www.cbsnews.com/news/google-settle-lawsuit-florida-teens-suicide-character-ai-chatbot/
A Belgian man died by suicide in 2023 after weeks of intensive conversations with a chatbot; his widow says it contributed. Vice: https://www.vice.com/en/article/man-dies-by-suicide-after-talking-with-ai-chatbot-widow-says/
Italy's data protection authority blocked Replika in 2023 over risks to minors and emotionally fragile people, and fined the company 5 million euro in 2025. Garante: https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/9852506 and the enforcement: https://www.edpb.europa.eu/news/national-news/2025/ai-italian-supervisory-authority-fines-company-behind-chatbot-replika_en
The American Psychological Association warned that generic AI chatbots used for mental-health support tend to repeatedly affirm the user even when that is harmful, and met with U.S. regulators over the risk, especially to youth. APA: https://www.apaservices.org/practice/business/technology/artificial-intelligence-chatbots-therapists

4. The same systems are entering lethal decision loops (documented facts, open-question risk)

Two things are true at once here. The deployments are documented fact. The danger of delegating lethal judgment to machines is the considered position of humanitarian and scientific bodies, held as an open question that needs binding rules.

The U.S. Army awarded a 480 million dollar contract in 2024 to build the prototype of the Maven Smart System; in 2025 the Department of Defense raised the ceiling to nearly 1.3 billion dollars. The underlying Project Maven uses AI to autonomously detect, tag, and track objects or people of interest. DefenseScoop, 2024: https://defensescoop.com/2024/05/29/palantir-480-million-army-contract-maven-smart-system-artificial-intelligence/ and 2025: https://defensescoop.com/2025/05/23/dod-palantir-maven-smart-system-contract-increase/
The International Committee of the Red Cross holds that loss of human control over the use of force raises serious legal and ethical concerns and recommends new legally binding rules. ICRC, 2021: https://www.icrc.org/en/document/icrc-position-autonomous-weapon-systems
The UN Secretary-General has said machines with the power to take human lives without human control are politically unacceptable, morally repugnant, and should be banned, calling for a binding instrument by 2026. United Nations, 2025: https://www.un.org/sg/en/content/sg/statement/2025-05-12/secretary-generals-video-message-the-informal-consultations-lethal-autonomous-weapons-systems
Tens of thousands of AI and robotics researchers warned a decade ago against weapons that select and engage targets without human intervention. Future of Life Institute, 2015: https://futureoflife.org/open-letter/open-letter-autonomous-weapons-ai-robotics/

5. What the evidence asks of us

Experts and governments have already asked for caution. A widely signed 2023 open letter called for a pause on training the most powerful systems (https://futureoflife.org/open-letter/pause-giant-ai-experiments/), leading scientists and lab CEOs jointly called AI extinction risk a global priority (https://safe.ai/work/statement-on-ai-risk), and 28 countries plus the EU signed the Bletchley Declaration on frontier AI safety (https://www.gov.uk/government/publications/ai-safety-summit-2023-the-bletchley-declaration/the-bletchley-declaration-by-countries-attending-the-ai-safety-summit-1-2-november-2023). No pause happened.

So here is the honest, narrow conclusion. Not that AI is evil. Not that alignment is impossible. Not pause everything. The claim the evidence supports is this: a system that is fluent but not grounded, that cannot be made universally robust by any fixed rule set, and that is already touching vulnerable people and lethal systems, must not be deployed as if guardrails alone make it safe. High-stakes use needs a living loop a human owns: test, monitor, update, limit the blast radius, and keep a person accountable for the rock that never stays at the top.

This is not a call for panic or an arms race. It is a call for restraint, responsibility, and peace. Build systems that reduce harm. Do not rush systems into the world and hope they behave. Before the next leap, a pause and a gut check is not weakness. It is the adult thing to do.

This is an educational summary with sources. It is not professional, legal, or medical advice. If you or someone you know is in crisis, in the US you can call or text 988.

Active Inference, taught with the math actually worked through

ORCHESTRATE — Thu, 11 Jun 2026 08:17:01 +0000

I kept hitting the same wall in Karl Friston's work: explainers that gesture at the free energy principle without ever running the equations, and papers that run them without explaining why. So I built the course I wanted — and I'm opening it as a free 12-week pilot cohort (25 seats), starting next week.

This is the version I wish existed when I first hit the active-inference literature: university-level, every equation executable in a clonable Elixir/Jido workbench, every shortcut named out loud.

The math, taught honestly

Most courses blur the parts that are easy to get subtly wrong. This one names them:

Mean-field VMP throughout. The state-belief update uses (ln B)·s, and the variational free energy uses (ln B)·s as well — the same form across both the update and the functional. No silent marginal/Bethe blend, which is where a lot of implementations quietly diverge.
Policy posterior σ(ln E − γG − F), with the precision γ placed on the expected free energy G where it belongs.
Expected free energy = ambiguity + risk, in nats — not a vague "exploration bonus."
The bound is never inverted. F[q] ≥ −ln p(o|m) stays an upper bound on surprise, always.

What the full 12-week arc covers

Perception as inference — the variational free energy F
Action as expected free energy G
Policy posteriors and precision
Markov blankets, made numerical (an actual conditional-independence residual, not just a diagram)
Dirichlet learning, wired live — E[ln A] via the digamma function, not ln E[A]
A capstone cue task and its five ablations — signed as risk-driven safe cue-seeking, each ablation breaking the agent in a predicted direction

You run it, you don't just read it

Every result in the course reproduces in a clonable Elixir/Jido workbench on the BEAM. Clone it, run mix test, watch the numerical trust gate pass to ~1e-9, watch the ablations fail exactly where the theory says they should.

A one-minute sample from Week 8 (perception as inference via mean-field VMP): https://youtube.com/watch?v=-Jcox5oGAYg

Reserve a seat

The pilot is free in exchange for deep feedback that helps me finalize the materials. 25 seats. To claim one, email Michael.Polzin@SolutionWright.com.

How We Sourced a 12-Part Tech Investigation So Every Claim Survives a Hostile Fact-Check

ORCHESTRATE — Thu, 11 Jun 2026 01:05:10 +0000

I just shipped a 12-part video series on cloud economics - depreciation schedules, lock-in, licensing disputes, bundling cases. The kind of material where one sloppy sentence gets you a lawyer's letter, and one unsourced number gets you dismissed as a crank.

So before writing a single script, we built a sourcing pipeline. This post is about that pipeline - treating an investigation like an engineering project, with schemas, gates, and review passes - because I think the discipline transfers to anyone writing technical content that makes claims about real companies.

The core artifact: claims.json

Every episode started not as a script but as a structured claims file. Each claim is a record with a few mandatory fields:

{
  "id": "EP01-C03",
  "text": "Alphabet's 2023 change to server useful life (4 to 6 years) added roughly $3.9B to reported income.",
  "type": "fact",
  "sources": [
    { "kind": "SEC 10-K", "ref": "Alphabet 2023 10-K, accounting estimates note" }
  ],
  "status": "verified"
}

The type field is the heart of it. Three values, strictly enforced:

fact - documented in primary public record: SEC filings, court dockets, regulator publications (EU Commission, UK CMA, FTC). A fact claim with no primary source fails the build. Press coverage alone doesn't qualify; an article about a 10-K is a pointer, not a source.
allegation - something a party claims in a live dispute. The CISPE complaint about Microsoft licensing is an allegation by CISPE; we say so, every time, with attribution in the sentence itself, not in a footnote.
opinion - our interpretation. "Extending server useful life is a lever that flatters margins" is opinion built on facts. It gets labeled as analysis in the script, out loud.

A script line that doesn't trace back to a claim ID doesn't ship. That sounds bureaucratic until you're on episode 9 and you can no longer remember whether you read that Amazon shortened some server lifespans in 2025 citing AI, or whether you inferred it. (We read it. It's filed. That's the point.)

The refutation pass

Verification is the easy half. The pass that actually saved us is the refutation pass: for every fact claim, someone takes the adversarial seat and tries to kill it.

Concretely, that means asking:

Is this the most recent number? (Azure didn't disclose a revenue dollar figure until July 2025 - $75B/yr. Anything written before that citing "Azure revenue" was citing analyst estimates, and we had to label those as estimates or cut them.)
Is the claim narrower than the sentence implies? All four hyperscalers - Microsoft, Amazon, Google, Meta - extended server life estimates within a few years of each other. That's documented. "They coordinated" is not documented, and the refutation pass deletes any sentence that smuggles it in.
Would the subject's lawyer agree this is an accurate description of the record? Not agree with our framing - agree it describes what the document says.

About a fifth of our draft claims didn't survive this pass. Most weren't wrong; they were stronger than the source. That's the failure mode the pass exists to catch: drift between what the record supports and what the sentence sounds like.

The legal and ethics gate

Separate from sourcing, every script passed a gate with two hard rules.

Rule 1: never accuse anyone of a crime. Not hedged, not implied, not "raises questions about whether laws were broken." If a regulator made a finding, we report the finding in the regulator's terms. The EU closed its Teams bundling investigation with commitments from Microsoft and no fine - so that's what we say. Not "got away with it." The commitments and the closure are the story; the editorializing is a liability and it's lazier journalism.

Rule 2: link the right of reply. Where a company has publicly responded - Broadcom on VMware's move to subscription bundles, Automattic in the WP Engine litigation (the N.D. Cal. dockets are public) - we link the response. If the audience only hears the complaint side, we've built a prosecution, not an investigation.

This gate had veto power over the refutation pass, the script, everything. A claim could be perfectly sourced and still fail here on framing.

Why "bad systems, not bad people" is the operative frame

This isn't a tone choice. It's what the evidence actually supports.

A CFO who extends server depreciation when the hardware genuinely lasts longer is doing their job. A vendor that prices egress high is responding to incentives every competitor shares - which is precisely why the UK CMA ran a full market investigation citing egress fees and licensing rather than prosecuting individuals. The documented pattern is structural: incentives, accounting levers, contract terms that compound into lock-in.

The systems frame also keeps you honest as a writer. The moment you cast a villain, you start selecting evidence to fit the character. When the subject is a system, contrary evidence is just more data about the system - you can include it without weakening your story, because the story is the mechanism, not the morality play.

And practically: it's the frame that survives a hostile fact-check, because it never asserts intent you can't document.

Check our work - please

All of this would be theater if readers had to take our word for it. So the claims database is public and browsable: the Evidence Explorer lets you pick any claim from any episode and see its label, its sources, and the underlying documents. If you find a claim that doesn't hold up, that's a bug report, and we treat it like one.

The series itself is on YouTube - the English playlist runs from depreciation mechanics through to a practical field guide for buyers. I also published a companion piece today on the lock-in economics specifically: The Lock-In Economy: How Cloud Pricing Quietly Traps Customers. And the full series announcement with all 12 parts is here on dev.to.

The takeaway for technical writers

If you write about real companies - postmortems, vendor comparisons, cost analyses - steal the cheap parts of this:

Separate your claims from your prose. A list of claims with sources is greppable; a 2,000-word draft is not.
Label fact vs. allegation vs. opinion before you write, not after.
Run one adversarial pass where your only job is to kill your own claims.
Never assert intent you can't document. Describe the mechanism instead.

I spent 35 years in IT operations - Y2K at Allstate, eight years inside Microsoft's cloud delivery org, co-authoring MOF 4.0 - and the habit that transferred best to publishing is the same one that works in ops: assume your output will be audited by someone who wants it to fail, and build so it doesn't.

I Read the Cloud Filings So You Don't Have To: a 12-Part Series

ORCHESTRATE — Thu, 11 Jun 2026 01:04:28 +0000

I've spent 35 years in IT operations. I worked Y2K remediation at Allstate, spent 2006-2014 inside Microsoft's cloud delivery organization, contributed to the Microsoft Operations Framework 4.0, and founded (and later exited) Leeward Business Advisors, an Inc. 5000 managed services firm. I have built on, sold, and operated the cloud for most of my career.

A while back I started reading the actual source documents behind cloud economics: 10-Ks, EU Commission decisions, the UK CMA's cloud market investigation, court dockets. Not the press coverage of those documents - the documents themselves.

What I found wasn't a scandal. It was something more interesting and, I think, more useful: a set of perfectly legal, fully disclosed mechanisms that quietly shape what you pay, what you can leave, and what you believe about the cloud. Most practitioners have never read the disclosures because nobody reads a 10-K for fun.

So I made a video series. Twelve parts. Every factual claim is cited to a primary public source. And I want you to try to break it.

The format: facts, allegations, and opinions are labeled

Before the links, the rules I held myself to, because they're the whole point:

Every claim is labeled as fact, allegation, or opinion. Facts link to a primary source - an SEC filing, an EU or CMA or FTC document, a court docket. Allegations are attributed to whoever made them. Opinions are flagged as mine.
No crime accusations. Nobody in this series is accused of breaking the law. Everything described is documented conduct from the public record - much of it disclosed by the companies themselves, in their own filings.
No villains. The framing throughout is "no bad people, bad systems." These are rational actors responding to incentives. The incentives are the story.

If you've ever been annoyed by tech commentary that's 90% vibes and 10% sourcing, this series is the inverse.

The twelve parts

Part 1: The Depreciation Lever

How a single accounting estimate - the useful life of a server - moves billions in reported income. In 2023, Alphabet extended its server useful-life estimate from four years to six, which added roughly $3.9B to reported income that year, per its own 10-K. All four hyperscalers (Microsoft, Amazon, Google, Meta) made similar extensions within a few years of each other. Then in 2025, Amazon shortened some server lifespans, citing AI. Same lever, both directions.

Part 2: What "Cloud Revenue" Actually Means

"Cloud revenue" sounds like a number. It's actually a definition - and each hyperscaler defines it differently, bundling different products into the segment. Notably, Microsoft didn't disclose a standalone Azure dollar figure until July 2025: $75B/yr, growing 34%. This part walks through what's actually inside each company's cloud segment, straight from the filings.

Watch Part 2

Part 3: The Lock-In Economy

Egress fees, proprietary services, credits that expire - the architecture of staying put. The UK CMA ran a full market investigation into cloud, specifically citing egress fees and licensing as barriers to switching. This part maps the switching-cost machinery using the regulator's own findings. (I also published a companion LinkedIn article on this one today - The Lock-In Economy.)

Watch Part 3

Part 4: Licensing as a Weapon

How software licensing terms can make a competitor's infrastructure more expensive to run than your own. This part covers the CISPE complaint against Microsoft in Europe and the settlement that followed - what the trade body alleged, what the documents say, and what changed.

Watch Part 4

Part 5: Teams Bundling

Slack's complaint to the European Commission over Microsoft bundling Teams with Office, and how the case actually ended: the EU closed it with commitments from Microsoft - and no fine. What "commitments" means in practice, and why the resolution matters as much as the complaint.

Watch Part 5

Part 6: The VMware Shock

After acquiring VMware, Broadcom moved it from perpetual licenses to subscription bundles. The customer and CISPE complaints that followed are documented public record, and they're a case study in what happens when a product your infrastructure depends on changes its business model overnight.

Part 7: WP Engine vs Automattic

A live, ongoing dispute in open source: the WP Engine v. Automattic litigation in the Northern District of California. The dockets are public, and they raise an uncomfortable question for anyone whose business sits on top of community infrastructure: who actually controls the commons?

Watch Part 7

Part 8: The AI Compute Loop

Hyperscalers invest in AI labs; AI labs spend the money on hyperscaler compute; the spend shows up as cloud revenue. This part traces the circular flow using the companies' own disclosures and asks what the numbers mean when the customer and the investor are the same entity.

Watch Part 8

Part 9: The Narrative Machine

How earnings calls, analyst guidance, and selective disclosure shape what the industry believes about cloud growth - and why the gap between the narrative and the filings is where the interesting information lives.

Watch Part 9

Part 10: Antitrust's Long Arm

A tour of the open regulatory fronts: the CMA's cloud investigation, EU proceedings, FTC activity. Not predictions - a map of what regulators have actually said, in their own documents, about cloud market concentration.

Watch Part 10

Part 11: No Bad People, Bad Systems

The thesis episode. None of this requires malice. Depreciation schedules, bundling, licensing terms - each is a rational response to incentives by people doing their jobs. If you want different outcomes, you change the system, not the people. This is the part I'd ask you to watch even if you skip the rest.

Part 12: What To Do

A field guide. Concrete things practitioners, buyers, and architects can do with this information: questions to ask in contract negotiations, line items to read in filings, switching costs to price in before you commit.

Watch Part 12

Watch in five languages

The full series is on YouTube, in public playlists:

English (flagship): https://youtube.com/playlist?list=PLMgel5a2pJlI
Português: https://youtube.com/playlist?list=PLfBH0DyzovSs
Français: https://youtube.com/playlist?list=PLLiJHCAviI5k
Italiano: https://youtube.com/playlist?list=PLB-I8aLsBsQU
Hindi: https://youtube.com/playlist?list=PLcvqoWZTmx8g

Read it instead

If you prefer text, several parts are already published here on dev.to as long-form articles:

Check my work: the Evidence Explorer

Citations in a video description are easy to skip. So every claim in the series lives in an interactive Evidence Explorer - claim by claim, source by source, with links to the underlying filings, decisions, and dockets:

https://evidence-explorer-michael-polzins-projects.vercel.app/

If a part says "Alphabet's useful-life change added ~$3.9B to reported income," you can click through to the 10-K language it comes from. If it describes the EU's Teams resolution, you can read the Commission's own document. Nothing in the series asks you to trust me.

Falsify it

Here's the invitation, and I mean it literally.

This series is built to be checked. Every fact has a source. Every source is public. If you find a claim that's wrong - a number I misread, a filing I mischaracterized, a docket I summarized unfairly - tell me. Comment here, comment on the video, open the Evidence Explorer and point at the exact claim. I will correct it, visibly, and credit you.

That's the standard I think technical commentary should meet: not "trust the author," but "here's everything you need to prove the author wrong."

The cloud runs most of what we build. The economics of the cloud are written down, in public, by the companies themselves. All I did was read the documents.

Now go try to break it.

Michael Polzin

Your AI Maturity Is Two Numbers, Not One: Breadth, Depth, and Why Programs Stall

ORCHESTRATE — Mon, 08 Jun 2026 12:18:04 +0000

Ask a leadership team how mature their AI program is and you will get a single number. "We're a level 3." "We're maybe a 4." That single number is the reason so many AI programs quietly stall.

AI maturity is not one number. It is two, and they move independently.

Breadth and depth are different axes

Breadth is how widely AI touches the organization. How many people, how many teams, how many workflows have AI in them at all.

Depth is how deeply any given workflow has been rebuilt around AI. Not "we use a chatbot sometimes" but "this process was redesigned so that AI is load-bearing and the old way is gone."

These two do not rise together, and conflating them produces two very different failure modes wearing the same score.

The two ways to be "a level 3"

Wide and shallow: Everyone has a license. Everyone has touched the tool. Adoption dashboards look great. But no single workflow has actually changed, so none of the work is faster, cheaper, or better. This org has breadth with no depth. It feels mature and delivers almost nothing.

Narrow and deep: A few teams have rebuilt their core workflows around AI until the new way is just how the work happens. The impact is real and measurable, but it is confined. This org has depth with no breadth. It is delivering value but cannot yet claim organizational maturity.

A single maturity number cannot tell these two apart. And they need opposite next moves. The wide-and-shallow org needs to go deep on a few workflows and stop counting logins. The narrow-and-deep org needs to spread its proven patterns. Give them the same generic "advance to level 4" advice and you will misfire on both.

Why most orgs overrate themselves

Most organizations think they are at stage 4. Most are at stage 2. The gap is not arrogance, it is the wrong measuring stick.

People rate maturity by capability — tools purchased, pilots launched, training delivered. But capability is what your tools can do. Maturity is what your people actually do on a Tuesday. The honest measure is workflow change, and when you switch to it the number usually drops two levels.

That drop is not bad news. It is the start of real progress, because you are finally measuring the thing that pays rent.

A test you can run this week

For each major workflow, ask two questions:

Breadth: Is AI present in this workflow at all? (yes / no)
Depth: If AI disappeared tomorrow, would this workflow break, or would people barely notice? If they would barely notice, you have breadth without depth.

Plot the answers on two axes. The shape tells you the move. Wide and shallow: pick three workflows and go deep until removal would hurt. Narrow and deep: take a proven pattern and widen it.

The deeper point

Maturity is a verb, not a purchase order. The most mature AI team I ever saw had the smallest tool budget. They had not bought the flashiest stack. They had picked three workflows and rebuilt them until the new way was simply how the work happened.

Stop reporting one number. Report two, and the right next step stops being a guess.

This draws on the AI Usage Maturity Model in LEVEL UP, a measurement framework for leaders building real AI programs.

The R in ORCHESTRATE: Why Telling a Model Who It Is Changes the Output

ORCHESTRATE — Mon, 08 Jun 2026 12:17:46 +0000

Most people spend their prompt-tuning effort on phrasing. They reword the task five times looking for the magic sentence. Meanwhile the single cheapest quality upgrade in prompting sits untouched: telling the model who it is.

That is the R in ORCHESTRATE. Role. And it is not flavor text.

What Role actually does

A large language model contains an enormous space of possible responses. The same question, "how should we handle this outage," can be answered by a panicked junior, a methodical SRE, a budget-focused VP, or a compliance officer, and the model can convincingly be any of them.

When you do not specify the role, the model picks a generic blend, usually the statistical average of how that question gets answered across the internet. Average is rarely what you want.

Specifying the role narrows the output space before the model writes a single word. It is a constraint, and constraints are how you focus capacity instead of scattering it.

The three parts of a good role

A role is more than a job title. The useful version has three parts, which we abbreviate PRO:

Practice — the domain. Not "an expert" but "a security architect specializing in cloud IAM." Specificity here changes vocabulary, assumptions, and what the model treats as obvious.
Rank — the authority level. A principal engineer and a first-year analyst hedge differently, escalate differently, and make different trade-off calls. Rank sets the decision posture.
Orientation — the decision style. "Prefers boring, proven technology and is explicit about trade-offs" produces a measurably different answer than "optimizes for novelty." This is the part almost everyone omits, and it is the part that most shapes the judgment in the output.

A concrete before and after

Without role:

Review this database schema and suggest improvements.

You get a generic checklist: add indexes, normalize, consider caching. Fine, forgettable, and probably not aimed at your actual problem.

With role:

You are a principal data architect who has run production Postgres at scale. You are normalization-aware but pragmatic, you think index-first, and you protect data integrity above convenience. Review this schema and suggest improvements, flagging any change that risks a migration outage.

Now the output reasons about query plans, calls out a specific composite index, warns about a lock during a column rename, and ranks suggestions by risk. Same model, same schema. The only thing that changed was who you told it to be.

Why this is the highest-leverage component

In the ORCHESTRATE framework, the foundation is Objective, Role, Context, and these three carry roughly 80 percent of the quality. Objective is load-bearing, but Role is the cheapest of the three to add and the most consistently skipped.

It costs you one sentence. It returns a sharper, more opinionated, more useful answer because you have stopped asking the average of the internet and started asking a specific kind of expert.

The practical takeaway

Before your next non-trivial prompt, answer one question: whose expertise should this output be channeling? Then write that down in three parts, domain, authority, decision style, and put it at the top.

You are not boxing the model in. You are pointing all of its capacity at the answer you actually want.

This is part of a series on the ORCHESTRATE Method, an eleven-component framework for professional AI output.

The 80 Percent Rule: Why Sustainable Pace Beats Heroics in Every System That Lasts

ORCHESTRATE — Mon, 08 Jun 2026 12:17:27 +0000

There is a number that quietly decides whether a business survives past year five. It is not revenue, headcount, or burn. It is the percentage of capacity you run at on an ordinary day.

Most founders run at 100. The ones still standing in five years run at about 80.

Why 100 percent is a trap

Run any engine at full throttle indefinitely and it throws a rod. This is not a motivational metaphor, it is how systems under sustained maximum load actually behave. There is no slack to absorb a shock, so the first surprise becomes a crisis, and crises are expensive.

A team running at 100 percent has no room for the surprise client, the sick day, the data migration that runs long. Every one of those becomes an overtime event, and overtime is a loan against next week's energy at a brutal interest rate. You feel the repayment as the Thursday fog, the quarter where everyone worked flat out and the business did not move.

The 20 percent you are tempted to squeeze out is not waste. It is the shock absorber. It is the whole point.

Heroics are a tax, not a strategy

Heroics feel like leadership. A late night, a weekend rescue, a founder personally unblocking everything. It reads as commitment. But a business that only works when someone sprints is not a business, it is a part-time job that owns the person sprinting.

The deeper problem: heroics hide the broken system that required them. Every time you personally save the day, you remove the pressure that would have forced a real fix. The hero is also the reason the bug never gets fixed.

Rhythm is the speed that compounds

The alternative is not slower. It is steadier, and steady compounds.

Consider two boats crossing the same water. One sprints and stalls, sprints and stalls. The other holds a single sustainable line. Over any distance that matters, the steady boat wins, because it never pays the restart cost and never capsizes in a gust.

The same is true of work. Enough, done every week without drama, builds a company. More, done in frantic bursts, builds a story you tell in the burnout recovery group. The boring version is the one still operating in five years.

How to actually run at 80

Three moves, none of them glamorous:

Pick one recurring task and dial it to 80 percent on purpose. Do it deliberately worse, and watch how little breaks. Most of the last 20 percent of polish is invisible to everyone but you.
Put recovery on the calendar like it earns money. Because it does. The push-and-recover cycle is not optional, and skipping the recover half does not buy you more push. It buys a slow leak.
Find the single point of failure and remove it. If your business cannot survive your worst week, that is not freedom, it is a beautifully decorated trap. Let one person own a whole lane end to end. It will sting, and then it will feel like freedom.

The honest Sunday question

Once a week, ask: can I keep this up?

If the honest answer is no, the problem is not your willpower. It is the pace you inherited from people selling hustle. The fix is not to try harder. It is to build a pace you can hold on an ordinary day with ordinary energy, and then defend it.

A business should not need you bleeding to survive. Build the one that does not.

This essay draws on the operating philosophy behind Run on Rhythm. If sustainable pace is the kind of business you are after, that is where the full playbook lives.

What To Do: A Practical Field Guide to the Cloud You Actually Pay For

ORCHESTRATE — Sat, 06 Jun 2026 23:32:27 +0000

Part 12 of a sourced series — the finale. Recommendations here are my opinion; the few hard facts (the EU law, where the filings live) are linked. The point of eleven parts of analysis is this one: what you can actually do.

The critique is only worth the action

Eleven parts in, you know the machine: assumptions that flatter profit, metrics that obscure, pricing that traps, licensing that tilts, financing that loops. None of it needs a villain — just a scoreboard.

You can't rewrite the scoreboard alone. But you can stop feeding it, and you can push where it actually moves. Here's how, by who you are.

If you buy software

Lock-in is a choice you make at signing, and forget by the time it hurts. Make it on purpose instead.

Price the exit, not just the entry. Put the egress bill (Part 3) into your total cost before you sign, not after you're trapped.
Demand portability terms. You have more leverage than you think: the EU Data Act already caps switching/egress charges at cost and bans them entirely from 12 January 2027 (European Commission). Ask for those terms even if you're not in the EU — the vendor already has to build them.
Avoid one-way doors. Prefer open formats and standard APIs over proprietary ones wherever an equivalent exists, so leaving is an option you keep.
Keep a tested exit plan. A migration you've never rehearsed is not a plan; it's a hope.

If you invest, or just want to read the room

You do not need a finance degree to check the moves in this series. You need the filing.

Public companies' 10-K and 10-Q filings are free on the SEC's EDGAR.
Search the "useful life" note (Part 1) — that's the depreciation lever, in the company's own words.
Read the segment definitions (Part 2) — that's how "cloud revenue" gets defined and bundled.
When a number seems too clean, find the assumption underneath it. There always is one.

If you build software

You're inside the machine. That's exactly where the fix lives.

Publish metrics people can read. Resist the bundle that flatters the headline. Clarity is a moat competitors who obfuscate can't cross.
Make staying earned, not enforced. Price retention on value delivered, not on the pain of leaving.
Default to open. Exportable data and standard interfaces aren't charity; they're the trust that compounds.

If you vote, regulate, or organize

This is the strongest lever of all, because it changes the scoreboard itself.

Interoperability and portability mandates — like the EU Data Act and the UK CMA's cloud market work (CMA) — shift the cost of lock-in back onto the vendor, where it belongs.
Support the rules that make the trustworthy move also the profitable one. That's the whole game.

Opinion — Michael. I don't think we beat this with outrage. We beat it with attention and design. Outrage is the scoreboard's favorite fuel — it rewards the loudest villain story, not the most useful one. So do the quiet things instead: read the footnote, check the source, reward the company that makes the honest move, and build incentives you'd be proud to be followed. Systems are just choices we stopped questioning. No bad people. Bad systems. And systems can be rebuilt.

Where this leaves us

I started angry and went looking for a crime. I found a machine instead — mostly legal, fully disclosed, and far more changeable than any villain would be.

Everything in these twelve parts is checkable. So check it. The evidence explorer has every claim and every source; the videos walk you through them. Don't take my word — take the filings.

Then go fix a scoreboard. Yours, or the one you're standing on.

The series: Parts 1–12 are all sourced and open.
🔎 Explore every claim: explore every claim → · ✉️ Corrections & contact: mpolzin@zimzap.com / LinkedIn

No Bad People, Bad Systems: What Ten Parts of Cloud Economics Actually Taught Me

ORCHESTRATE — Sat, 06 Jun 2026 23:32:06 +0000

Part 11 of a sourced series. This installment is openly my opinion — the analysis, not the reporting. The facts it rests on are documented in Parts 1–10 and in the evidence explorer. I name no crime here, because that was never the point.

What I went looking for, and what I found

I started this series angry. I expected to find villains.

What I found instead was a machine. Ten parts in, the through-line isn't a person — it's a scoreboard.

A depreciation assumption that lifts reported profit by billions (Part 1).
"Cloud revenue" defined so the number flatters the story (Part 2).
Pricing where it's free to enter and metered to leave (Part 3).
Licensing that quietly tilts the field toward the landlord's own cloud (Parts 4–5).
A licensing overhaul that 10x'd some customers' bills (Part 6, per the complainants).
Infrastructure used as leverage against a single vendor (Part 7).
And financing that loops capital between the same handful of players (Part 8).

Almost all of it legal. Almost all of it disclosed. None of it requiring a single bad person.

The uncomfortable part

Here's what's harder to sit with than a villain: decent people, inside these systems, would mostly do the same things.

If your scoreboard rewards this quarter's profit, you will reach for the assumption that raises this quarter's profit. If it rewards growth optics, you will define the metric that shows growth. If it rewards retention, you will price the exit so leaving hurts. You don't need malice. You need a number on a wall and a bonus attached to it.

I think about organizations the way I think about minds. A nervous system acts to keep reality matching its prediction — to minimize surprise. A public company does the same thing, except its "prediction" is the consensus estimate, and the surprise it fears is a missed quarter. From that lens, everything in this series becomes predictable. Not excusable. Predictable.

Why "bad people" is the wrong frame

Naming villains feels great. It also fixes nothing.

Fire a CEO and the scoreboard hires the same behavior in a new suit. Fine a company and it prices the fine into next year's plan. The incentive outlives the individual every time. That's why I keep saying it: no bad people, bad systems. Not because no one ever acts badly — but because if you want different outcomes, the person is the weakest place to push and the system is the strongest.

This is also why I refused, from the first sentence of this series, to publish accusations of crime I couldn't prove. Not just because it's reckless — because it's the wrong diagnosis. The crime frame says "remove this person." The systems frame says "rewire this incentive." Only one of those changes what happens next quarter.

Opinion — Michael. I'll go further: the villain story is itself a product of the same broken scoreboard. Outrage is engagement, engagement is reach, reach is the metric — so the loudest version of every story is the one with a bad guy in it. I didn't want to feed that machine while criticizing it. The honest story is quieter and more useful: the system is doing exactly what it's paid to do.

What a better scoreboard looks like

If the problem is the incentive, the fix is too. Imagine cloud economics where the rewarded behavior is the trustworthy one:

Profit that's durable, not borrowed from a future write-down.
Metrics customers can actually read.
Portability priced like a right, not a penalty.
Procurement and policy that make lock-in expensive for the vendor instead of the customer.

That's not naïve. The EU already did one piece of it — banning the exit toll outright by 2027 (Part 3). The point of regenerative design is simple: make the move that's good for the customer also the move that's good for the quarter. Align those two and most of this series stops happening on its own.

The invitation

So this isn't a takedown. It's a map of where the repair lives.

If you run a company: audit your own scoreboard before you judge anyone else's. If you buy software: read the depreciation note and the egress table — Part 12 shows you how. If you build systems of any kind: assume people will follow the incentive, and design the incentive you'd be proud to be followed.

There are no bad people in this story. There's a machine we all built, and can all rebuild.

Next — Part 12: "What To Do." Practical moves for buyers, builders, and citizens.
🔎 Check it yourself: explore every claim →

Antitrust's Long Arm: What's Been Decided About Big Tech — and What's Still Being Fought

ORCHESTRATE — Sat, 06 Jun 2026 23:31:41 +0000

Part 10 of a sourced series. This one has a hard internal line, and I'm going to hold it carefully: some of these cases are decided — a court or a regulator made a finding — and some are filed but undecided, meaning a government alleges wrongdoing that nobody has proven. I state findings as findings and allegations as allegations, and I link each company's own response. Nothing here calls an undecided case a verdict. My opinions are marked. Corrections policy at the bottom; an evidence explorer lets you check every claim.

Why an antitrust chapter, in a series about cloud

Everything earlier in this series — the depreciation lever, "cloud revenue," the lock-in pricing, the licensing fights — happens inside a market a handful of companies dominate. So the obvious question is: what does the law actually say about that dominance?

The honest answer in 2026 is it depends which company, and which case. Against Google, the verdicts are in, on two continents. Against Amazon and Apple, the U.S. government has sued — but those suits haven't been decided, and it matters enormously that we keep those two buckets apart.

So let's keep them apart.

Decided: Google is an illegal monopolist in search

This is a finding, not an allegation. On August 5, 2024, U.S. District Judge Amit Mehta ruled in United States v. Google that Google is an illegal monopolist in general search and general search text advertising under Section 2 of the Sherman Act — with Google holding roughly 90% of general search. The court's own words: "Google is a monopolist, and it has acted as one to maintain its monopoly" (White & Case summary; Tech Policy Press).

Then came the part everyone expected to be dramatic — and wasn't. On September 2, 2025, Judge Mehta issued the remedies ruling and declined to break Google up. He did not order Google to divest Chrome or Android. Instead he barred exclusive distribution deals and required Google to share certain search-index and user-interaction data with qualified competitors (TechCrunch; NPR).

Google's side, in its own voice: it responded to the liability ruling and to the remedies ruling, and is appealing. Worth saying plainly: an appeal does not vacate the finding. Until a higher court says otherwise, the finding stands.

Decided: Google is a monopolist in ad tech, too

A second U.S. court, a different judge, a different market — same direction. On April 17, 2025, U.S. District Judge Leonie Brinkema ruled that Google illegally monopolized two ad-tech markets — publisher ad servers and ad exchanges for open-web display — and unlawfully tied its DoubleClick for Publishers product to its AdX exchange (Simpson Thacher; JURIST).

Here's where precision matters, because it's easy to overstate a win. This was the liability phase, and the court did not give the government everything: it dismissed the separate claim about the advertiser-ad-network market (JURIST). So the accurate sentence is "monopolist in two ad-tech markets, with a third claim dismissed" — not "monopolist in advertising, full stop." Google said it would appeal and laid out its position here.

Decided: Europe has been fining Google for years

Across the Atlantic, this isn't new — it's a pattern with a paper trail. On September 5, 2025, the European Commission fined Google EUR 2.95 billion for abusing its dominance in advertising technology by self-preferencing its own AdX exchange. The Commission treated the conduct as recidivism and signaled that only structural remedies — such as divestiture — might resolve the conflict of interest (European Commission, IP/25/1992; Loyens & Loeff).

One careful note on what that is: the Commission is a regulator making an administrative finding, not a court returning a verdict — a real and binding decision, but a different instrument from the Mehta and Brinkema rulings.

And it sits on top of an older record. Google was fined EUR 2.42 billion for Google Shopping self-preferencing in June 2017 — upheld by the Court of Justice in September 2024 — and EUR 4.34 billion for Android restrictions in July 2018, largely upheld in September 2022, though the fine was trimmed on appeal to EUR 4.125 billion (CNBC; Wikipedia overview). Note the Android fine was reduced, not rubber-stamped — appeals courts push back. Google will appeal the 2025 adtech fine and frames its European position here.

Pending — not proven: the Amazon case

Now the other bucket, and the line gets bright here. What is a fact is that on September 26, 2023, the FTC and 17 state attorneys general sued Amazon, alleging it illegally maintains monopoly power under Section 2 of the Sherman Act and Section 5 of the FTC Act (Thomson Reuters Practical Law). What is not a fact is the conclusion: no court has found Amazon to be a monopolist. The suit was filed; the question is open. Trial is set for October 13, 2026 (Bloomberg Law). Amazon denies wrongdoing and states its position here.

There's an intermediate step people sometimes mistake for a win. In September 2024, Judge John Chun denied Amazon's motion to dismiss in part, letting the Sherman Act and FTC Act monopolization claims proceed while dismissing certain state-law claims (Courthouse News). Read that for exactly what it is: a pleading-stage ruling that the case is allowed to go forward. It decides that the FTC gets its day in court — not that Amazon is a monopolist. Those are different sentences, and the difference is the whole point of this section.

Pending — not proven: the Apple case

Same structure, same discipline. It is a fact that in March 2024 the DOJ and 16 state and district attorneys general sued Apple, alleging it monopolizes or attempts to monopolize the U.S. smartphone and performance-smartphone markets under Section 2 of the Sherman Act (U.S. Department of Justice). It is not a fact that Apple is a monopolist — that's the allegation the case will test.

On June 30, 2025, Judge Julien Neals denied Apple's motion to dismiss, finding the DOJ had "sufficiently plead" that Apple has monopoly power in those markets (Mintz). Hold that quote tightly: "sufficiently plead" means the allegations are detailed enough to proceed — a pleading standard, not a finding on the merits. The case remains undecided. Apple disputes the claims, including how the government defines the market, and its statement is here.

My read

Opinion — Michael. Notice the asymmetry, because it's the real story. Against Google, the question of whether is largely settled — two U.S. courts and the EU all landed on "monopolist" — and the live fight is what to do about it, where Mehta's no-breakup remedy tells you how cautious courts are about actually restructuring these firms. Against Amazon and Apple, we're a stage earlier: the government has made its case on paper, judges have said "that's enough to go to trial," and that's all that's happened. I think the honest posture is to take the Google findings seriously and to take the Amazon and Apple cases seriously but not prematurely — to resist the very human pull to read "survived a motion to dismiss" as "guilty." This is the whole reason this series labels its claims: the gap between alleged and proven is exactly where careless writing turns into something untrue. Bad systems, not bad people — and one of the systems worth fixing is our own habit of collapsing a lawsuit into a verdict.

You don't have to take my read. The rulings, the fines, the complaints, and every company's response are linked above — sort the decided from the pending yourself.

Sourcing & corrections

The Mehta liability and remedies rulings are sourced to White & Case, Tech Policy Press, TechCrunch, and NPR; the Brinkema ad-tech ruling to Simpson Thacher and JURIST; the EU adtech fine to the European Commission's own release and Loyens & Loeff; the older Shopping and Android fines to CNBC, with appeal outcomes noted. The Amazon and Apple matters are sourced to Thomson Reuters Practical Law, Bloomberg Law, Courthouse News, the DOJ, and Mintz — and framed throughout as filed-but-undecided, with the pleading-stage rulings distinguished from merits verdicts. Each company's public response is linked inline and matched in the explorer. Spot an error or something unfair? Email mpolzin@zimzap.com or message me on LinkedIn — I'll review and correct.

Next — Part 11: "No Bad People, Bad Systems."
🔎 Check it yourself: explore every claim →